Talk:Circle–ellipse problem

message: The solutions currently posted in the article do not include the following: use more than one class of circles.
· Define the class Ellipse as superclass of two classes for circle as follows.
· Define the class EssentialCircle (or just Circle) as subclass of Ellipse. Use it when its parameters can never be changed in such a way that the objects of this class would cease to comply with the requisites of representing circles.
· Define the class AccidentalCircle as subclass of Ellipse. Use it when a change of parameters might make the object a non-circle. That is: the object is created as an ellipse, of class Ellipse; the object is also an object of class AccidentalCircle only if its parameters allow it to be a circle (for example, equal axes). For instance, interrogate the object through Ellipse method(s) to learn whether AccidentalCircle methods can be used on it. Alternatively, create the object as an AccidentalCircle but provide a method to interrogate whether it continues to be a circle before using other circle methods.
What do you think of this?
Note: I cannot give any references to this solution because it just occurred to me.
Kurt Artindagi (talk) 10:48, 7 April 2014 (UTC)
replies: text: Perhaps using ConicalSection as a superclass is much simpler? Methods and properties (like radius and stretchX()) not shared by subclasses should stay exclusive to those subclasses. Klassica 20:04, 25 November 2015 (UTC)
thread_title:  An easy solution 

message: I propose that class Ellipse() exists as it ought to be with radiusXsize and radiusYsize. To make a class Circle(), we extend Ellipse(), however do a simple override to radiuses i.e. when Circle() is invoked and a radius size defined, it is applied to both directions (X and Y), thus:
* Ellipse() is a parent
* Ellipse() integrity is not questioned
* Circle() can be a child
* Circle() has one extra property (inherited from Ellipse())
Lovescream (talk) 13:31, 7 April 2018 (UTC)
thread_title:  Even easier 

message: In 'Possible solutions -> The "IS"-Test' is stated, that a circle IS not an ellipse. Mathematically this is not correct at all and there is no other criterion (named 'IS' specifically as opposed to 'is') given. Can somebody correct this (or me)?
Antsan (talk) 20:41, 14 April 2011 (UTC)
thread_title:  Circle is an ellipse indeed 

message: PJTraill 06:06, 23 January 2007 (UTC)
thread_title:  An anti-pattern? 

message: The example of why it is a bad idea to make an elipse an extension of a circle gives the example that an ellipse cannot provide a radius method. An ellipse DOES have a radius or rather a continuum of radii parameterised over angle from an arbritrary reference point. Providing this parameter to a circle will give the same radius throughout the continuum. In the same way it is also possible to rotate a circle, it just doesn't affect anything. Therefore a better example is needed whereby an elipse cannot simply extend a circle.
----
The crux of the problem was hinted to at the end of the article. The concept of a subclass is that it is intended to extend the parent class, but a circle is a restriction, rather than an extension. It reveals an ambiguity in language: When we say "A is a B...", it can mean two things: A is an extension of B, or A is a restricted form of B. Possibly we can create a programming concept of restricted inheritance. (This may have been touched on in the article.)
67.101.59.207 (talk) 19:55, 8 November 2012 (UTC)
thread_title:  Radius 

message: In the "Challenge the premise of the problem" section, it is suggested that perhaps Circle should not be a subclass of Ellipse, because it restricts the implied freedom of an ellipse, whereas the same problem would not arise if Monkey was a subclass of Animal. That idea seems to side-step one of the major problems communicated by the article (perhaps not explicitly enough), namely that a Circle could be altered (as an ellipse) to contradict its own labelling as a circle, and thereby, implicitly could be made to contradict some aspect of its implied identity. It's a philosophical idea that could equally be applied to the Monkey-Animal relationship. As a hypothetical example, if all animals are composed of cells, and those cells are mutable, e.g. by altering their DNA, then (in theory) all animals could be changed in this way. Since a monkey is an animal, then all of its cells could (in theory) be changed so that it now appears and functions exactly like a duck. Therefore, the Monkey is no longer a monkey, but it is still an animal. This is the same kind of semantic problem arising with circles being changed (according to their inherited allowance) into something that contradicts their own label. Of course, that ties in with the other ideas of mutable types, e.g. when a Circle becomes a non-Circle by virtue of being a mutable Ellipse.  — Preceding unsigned comment added by 129.67.47.59 (talk) 11:45, 9 January 2014 (UTC)
thread_title:  Challenge the premise of the problem - Monkey is an Animal 

message: There is a problem with the example of the person and prisoner. It states "a prisoner is not free to move an arbitrary distance in any direction, yet the contract of the Person class states that a Person can." But no person is ever free to move any distance in any direction; we are all restricted in our movement. We are restricted by walls, fences, hedges, roads, the private property of others, rivers, mountains, oceans, political borders, gravity, planets, stars etc. So I consider it a bad example; if the contract of a person says that it can move freely in any direction, that contract is bad in the first place. And that makes the whole prisoner example invalid, because a prisoner is just a person that is (temporarily) more restricted than most other persons are. There is no such thing as a FreePerson that can move freely in any direction; there are only RestrictedPersons with a varying set of restrictions. And in that case a Prisoner can easily inherit from RestrictedPerson, as a Prisoner only has an extra, specific physical restriction in the set of restrictions; a very narrow one for sure, but not really categorically different from any other restriction.
Maybe Person and Prisoner can be kept, but the methods changed into something that really is categorically different between a Person in general and a Prisoner. 
If I had a good idea for a better, more realistic and valid alternative, I would simply replace the example. But right now I don't have that idea. I just wanted to point to and describe the problem, which is the first step to solving it. Maybe someone else can come up with a good solution. --Jhertel (talk) 01:16, 13 October 2016 (UTC)
thread_title:  Person vs. prisoner 

message: Hello fellow Wikipedians,
I have just modified  on Circle-ellipse problem. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf to http://www.objectmentor.com/resources/articles/lsp.pdf
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 03:58, 25 November 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified one external link on Circle-ellipse problem. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20110719101727/http://www.informatik.uni-augsburg.de/de/lehrstuehle/dbis/db/publications/all_db_publications/1996_koe_kie_isotas96/1996_kow_koe_kie_isotas96.pdf to http://www.informatik.uni-augsburg.de/de/lehrstuehle/dbis/db/publications/all_db_publications/1996_koe_kie_isotas96/1996_kow_koe_kie_isotas96.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 02:14, 8 August 2017 (UTC)
thread_title:  External links modified 

message: All circles are ellipses. All ellipses are circles, if their x and y dimensions are the same. Which one is the parent, which one is the child
in a single-inheritance hierarchy? ...
...
The entire premise is a contrived (on purpose) academic exercise to try and illustrate to computer science students that, correctly used, OOP should model externally visible behavior, not *literal* set-relationships. It says right in the liked source:
 "A square might be a rectangle, but a Square object is definitely not a Rectangle object. Why? Because the behavior of a Square object is not consistent with the behavior of a Rectangle object. Behaviorally, a Square is not a Rectangle! And it is behavior that software is really all about."
Unfortunately, unless I'm mistaken, the article and much of the talk page goes on at great length and seems to have taken the problem seriously. It goes down some particularly contrived rabbit holes, offering some questionable-at-best solutions.
 "code written in an object-oriented language that models shapes will frequently choose to make class Circle a subclass of class Ellipse, i.e. inheriting from it."
None that I've wrote ever did. We model the externally visible behavior not the literal real-world set-relationships.
In the given example, using OOP these would be implemented as siblings - thus avoiding the entire problem - because that's the whole point. They behave differently, thus they are different types. That's what a type is in programming. A type is a behavior. It behaves as an int, it behaves as a float, it behaves as a Circle, it behaves as an Ellipse, it behaves as a Whatever.
In almost any OOP language, I can explicitly typecast these into one another following whatever behavior is required to be visible to 
external users. I can even write comparison operators if I need to compare them in some way - all entirely using OOP and it works quite well. 
To use this purposefully contrived example problem as a serious argument against OOP, (as the article implies) is a fundamental misunderstanding of how to apply the OOP paradigm and is contrary to the paper it references.
C++, Java and Python programmers cleanly implement Circles and Ellipses using OOP every day. 65.121.126.226 (talk) 22:13, 20 September 2022 (UTC)
thread_title:  This article probably needs reworked