Newbie question re: circle and ellipse
Author 
Message 
Roger L. Cauvi #1 / 26

Newbie question re: circle and ellipse
[snip] Quote: > As I have come to understand it, the objection to the "Circle is a Type > of Ellipse" inheritence stems from circle having more limited > functionality, ie (eccentricity == 1) than an ellipse. > Would it therefore be permissible to derive ellipse from circle?
From a common sense point of view, it is not appropriate to derive Ellipse from Circle, because in general ellipses are not circles. From a pragmatic point of view, deriving Ellipse from Circle entails that ellipses must support all of the operations on circles, including the GetRadius operation. An ellipse, however, does not have a radius (at least not in the same sense that a circle does). Therefore, it is not appropriate to derive Ellipse from Circle. The most flexible, extensible solution to the "Is a Circle an Ellipse?" dilemma is to divide ellipses into two classes, an Ellipse abstract base class and a StretchableEllipse concrete derived class. The Ellipse class does not support "stretchability", i.e. modification of an ellipse's eccentricity, but the StretchableEllipse does. Since the Ellipse base class no longer promises to support "stretchability", the Circle class can now appropriately be derived from it. Ellipse / \ / \ StretchableEllipse Circle This model has the following advantages over other possible hierarchies: 1. It preserves strong typing, allowing staticallytyped languages to enforce correct behavior. For example, attempts to modify the aspect ratio of a circle will fail at compile time rather than at run time. 2. It allows for polymorphic calls on all kinds of ellipses, including circles. For example, any operation which will in general work on an ellipse will also work on a circle. 3. It models ellipses and circles in a manner that is faithful to their strict geometric definitions. The geometric definition of an ellipse says nothing about the possibility of changing its eccentricity. Ellipses which are "stretchable" are important, but they are extensions of the geometric definition.  Roger L. Cauvin
Technologist ObjectSpace

Wed, 18 Jun 1902 08:00:00 GMT 


Nick Leato #2 / 26

Newbie question re: circle and ellipse
Quote:
> [snip] > > As I have come to understand it, the objection to the "Circle is a Type > > of Ellipse" inheritence stems from circle having more limited > > functionality, ie (eccentricity == 1) than an ellipse. > > Would it therefore be permissible to derive ellipse from circle? > From a common sense point of view, it is not appropriate to derive Ellipse > from Circle, because in general ellipses are not circles. From a pragmatic > point of view, deriving Ellipse from Circle entails that ellipses must support > all of the operations on circles, including the GetRadius operation. An > ellipse, however, does not have a radius (at least not in the same sense that > a circle does). Therefore, it is not appropriate to derive Ellipse from > Circle. > The most flexible, extensible solution to the "Is a Circle an Ellipse?" > dilemma is to divide ellipses into two classes, an Ellipse abstract base class > and a StretchableEllipse concrete derived class. The Ellipse class does not > support "stretchability", i.e. modification of an ellipse's eccentricity, but > the StretchableEllipse does. Since the Ellipse base class no longer promises > to support "stretchability", the Circle class can now appropriately be derived > from it. > Ellipse > / \ > / \ > StretchableEllipse Circle > This model has the following advantages over other possible hierarchies: > 1. It preserves strong typing, allowing staticallytyped languages to enforce > correct behavior. For example, attempts to modify the aspect ratio of a > circle will fail at compile time rather than at run time. > 2. It allows for polymorphic calls on all kinds of ellipses, including > circles. For example, any operation which will in general work on an ellipse > will also work on a circle. > 3. It models ellipses and circles in a manner that is faithful to their > strict geometric definitions. The geometric definition of an ellipse says > nothing about the possibility of changing its eccentricity. Ellipses which > are "stretchable" are important, but they are extensions of the geometric > definition.
ALthough I agree with splitting the classes, there is a more natural split. Circles and Elipses are all types of conics. A conic class makes a very natural abstraction. Then circle inherits conic, ellipse inherits conics. You can now provide features in circle and ellipse that convert between the two.  Nick

Wed, 18 Jun 1902 08:00:00 GMT 


#3 / 26

Newbie question re: circle and ellipse

Wed, 18 Jun 1902 08:00:00 GMT 


zo.. #4 / 26

Newbie question re: circle and ellipse
Quote: >ALthough I agree with splitting the classes, there is a more natural >split. Circles and Elipses are all types of conics. A conic class makes >a very natural abstraction. Then circle inherits conic, ellipse inherits >conics. You can now provide features in circle and ellipse that convert >between the two.
If I may interject, I have been toying with the notion that mathematics is too frequently called upon to provide simple problems for programmers to practice their skills on. I hypothesize that among problem domains that object oriented designers need to tackle, almost none of them are very much like mathematics. Think about banking transactions, air traffic control systems, GUIs, web servers, games. Do any of them, from the point of view of OOAD, yield to the same techniques of abstraction that mathematics yields to? I think not. I think mathematics is itself a highly specialized and carefully defined set of abstractions, which do not admit to further abstraction via OOAD. Hence, I think that examples or arguments about methodology which draws its problems from the world of mathematics is suspect  techniques which succeed or fail against math problems may fail or succeed against games, web servers, GUIs, ATC systems, et cetera. I would be happy to hear responses from more experienced object oriented designers. Zooko

Wed, 18 Jun 1902 08:00:00 GMT 


Alf P. Steinbac #5 / 26

Newbie question re: circle and ellipse
Quote:
> Think about banking transactions, air traffic control systems, > GUIs, web servers, games. Do any of them, from the point of > view of OOAD, yield to the same techniques of abstraction that > mathematics yields to? > I think not. I think mathematics is itself a highly > specialized and carefully defined set of abstractions, which > do not admit to further abstraction via OOAD. > Hence, I think that examples or arguments about methodology > which draws its problems from the world of mathematics is > suspect  techniques which succeed or fail against math > problems may fail or succeed against games, web servers, GUIs, > ATC systems, et cetera.
OO(P/D/A) simply does not support the concept of generalization used in everyday language and in mathematics. This is one reason why OO is *hard*  it conflicts with the way we usually think.  Alf  [Reply address intentionally foiled, but workable for humans.]

Wed, 18 Jun 1902 08:00:00 GMT 


El #6 / 26

Newbie question re: circle and ellipse
: > Think about banking transactions, air traffic control systems, : > GUIs, web servers, games. Do any of them, from the point of : > view of OOAD, yield to the same techniques of abstraction that : > mathematics yields to? : > : > I think not. I think mathematics is itself a highly : > specialized and carefully defined set of abstractions, which : > do not admit to further abstraction via OOAD. : > : > Hence, I think that examples or arguments about methodology : > which draws its problems from the world of mathematics is : > suspect  techniques which succeed or fail against math : > problems may fail or succeed against games, web servers, GUIs, : > ATC systems, et cetera. : OO(P/D/A) simply does not support the concept of generalization : used in everyday language and in mathematics. This is one reason : why OO is *hard*  it conflicts with the way we usually think. "Joe hand me a chair"; class Chair class WoodChair : public Chair "I'm going to the show" class Show class ComdyShow : public Show What is the problem? Elliott :  Alf : :  : [Reply address intentionally foiled, but workable for humans.]  "The domain object model is the foundation of OOD." "We should seek out proven optimal practices and use them." See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

Wed, 18 Jun 1902 08:00:00 GMT 


Gavin Tabo #7 / 26

Newbie question re: circle and ellipse
Quote:
> >ALthough I agree with splitting the classes, there is a more natural > >split. Circles and Elipses are all types of conics. A conic class makes > >a very natural abstraction. Then circle inherits conic, ellipse inherits > >conics. You can now provide features in circle and ellipse that convert > >between the two. > If I may interject, I have been toying with the notion that > mathematics is too frequently called upon to provide simple > problems for programmers to practice their skills on. > I hypothesize that among problem domains that object oriented > designers need to tackle, almost none of them are very much > like mathematics. > Think about banking transactions, air traffic control systems, > GUIs, web servers, games. Do any of them, from the point of > view of OOAD, yield to the same techniques of abstraction that > mathematics yields to? > I think not. I think mathematics is itself a highly > specialized and carefully defined set of abstractions, which > do not admit to further abstraction via OOAD.
Why would you want to `further abstract' a mathematical problem? Mathematics is about abstractions : within mathematics there are lots of entities (vectors, tensors, etc.) which are obviously `objects' in the OOP sense. OOP enables you to reflect this in the structure of the code. This makes it quite a good area to learn about the methodology : there are obvious ways of tackling the problem  maybe other examples should also be included in order to test programmers against problems that are less obviously objectbased. But if your problem is really not objectbased, why are you forcing it to fit the OOP paradigm? Gavin Quote: > Hence, I think that examples or arguments about methodology > which draws its problems from the world of mathematics is > suspect  techniques which succeed or fail against math > problems may fail or succeed against games, web servers, GUIs, > ATC systems, et cetera. > I would be happy to hear responses from more experienced > object oriented designers. > Zooko

http://monet.me.ic.ac.uk/people/gavin/gavin.html

Wed, 18 Jun 1902 08:00:00 GMT 


Roger L. Cauvi #8 / 26

Newbie question re: circle and ellipse
[snip] Quote: > OO(P/D/A) simply does not support the concept of generalization > used in everyday language and in mathematics. This is one reason > why OO is *hard*  it conflicts with the way we usually think.
Objectoriented design does not conflict with everyday language if some attention is paid to providing abstract, minimal interfaces. The circle/ellipse hierarchy I outlined illustrates this fact. As soon as the designer realizes that the concept of an ellipse does not necessary include "stretchability", and moves it from the Ellipse class to the StretchableEllipse class, the apparent conflict with mathematical language disappears. More important, the model becomes more extensible and convenient to use in a polymorphic manner. The same sort of design pattern applied to the circle/ellipse hierarchy can be used to reconcile many other apparent OO conflicts with everyday language.  Roger L. Cauvin
Technologist ObjectSpace

Wed, 18 Jun 1902 08:00:00 GMT 


El #9 / 26

Newbie question re: circle and ellipse
: : > Think about banking transactions, air traffic control systems, : : > GUIs, web servers, games. Do any of them, from the point of : : > view of OOAD, yield to the same techniques of abstraction that : : > mathematics yields to? : : > I think not. I think mathematics is itself a highly : : > specialized and carefully defined set of abstractions, which : : > do not admit to further abstraction via OOAD. The point of OO is not to "further abstract", though that often occurs. The point of OO is to simulate the domain as is, or to simulate it along with new abstractions, which then become part of the domain. Both provide information or information processing to users. : : > Hence, I think that examples or arguments about methodology : : > which draws its problems from the world of mathematics is : : > suspect  techniques which succeed or fail against math : : > problems may fail or succeed against games, web servers, GUIs, : : > ATC systems, et cetera. : : OO(P/D/A) simply does not support the concept of generalization : : used in everyday language and in mathematics. This is one reason : : why OO is *hard*  it conflicts with the way we usually think. I guess OOADP would be super *hard* if you don't think it supports the concept of generalization used in the everyday language and in mathematics. What do you think OO modellers mean when we use the word "abstraction"? We mean generalization of domain entities and when present, utility entities. : "Joe hand me a chair"; : class Chair : class WoodChair : public Chair : : "I'm going to the show" : class Show : class ComdyShow : public Show : : What is the problem? Elliott  "The domain object model is the foundation of OOD." "We should seek out proven optimal practices and use them." See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

Wed, 18 Jun 1902 08:00:00 GMT 


Roger L. Cauvi #10 / 26

Newbie question re: circle and ellipse
[snip] Quote: > If I may interject, I have been toying with the notion that > mathematics is too frequently called upon to provide simple > problems for programmers to practice their skills on.
The modeling of shape classes is frequently used because the domain is understood by most people. Granted, such concepts as circle and ellipse have welldefined meanings among geometricians. However, that in no way diminishes their illustrative power. Indeed, problems similar to the "Is a circle an ellipse?" problem crop up in every domain, whether or not the concepts in the domain are rigorously defined.  Roger L. Cauvin
Technologist ObjectSpace

Wed, 18 Jun 1902 08:00:00 GMT 


Ron Porte #11 / 26

Newbie question re: circle and ellipse
As an programming instructor, I found that as soon as my employer stipulated that I remove all mathematical examples from my curriculum, the class went to heck. Maybe at the university level every programming student has demonstrated a proper grasp of topics mathematical, but in the educational field in which I worked ({*filter*} vocational and retraining), there were no such guarantees. I'll be the first to admit that graduates of our programme were a far cry from what most of us on this list would call a programmer, but many of them found employment that eventually led to junior programming positions and I know that some of them can now program circles around me. Back to the point: without math, how does one programmatically control the size and position (both relative and absolute) of the various onscreen objects (buttons, windows, text boxes, etc.), especially when allowing for resolution independence? Without math, how does one manage iterations (loops of various types) and arrays, especially multidimensional ones? And so on... I love good examples from a variety of domains, but we're all in big trouble if some basic math and geometry goes over the head of a programmer. BTW: I was unable to make the case for putting the math back in my curriculum, so don't assume that the junior programmer you're interviewing can figure out how to put the window in the center of the screen in the absence of a predefined 'setPositionCentre'. Ron Porter
Quote:
> >ALthough I agree with splitting the classes, there is a more natural > >split. Circles and Elipses are all types of conics. A conic class makes > >a very natural abstraction. Then circle inherits conic, ellipse inherits > >conics. You can now provide features in circle and ellipse that convert > >between the two. > If I may interject, I have been toying with the notion that > mathematics is too frequently called upon to provide simple > problems for programmers to practice their skills on. > I hypothesize that among problem domains that object oriented > designers need to tackle, almost none of them are very much > like mathematics. > Think about banking transactions, air traffic control systems, > GUIs, web servers, games. Do any of them, from the point of > view of OOAD, yield to the same techniques of abstraction that > mathematics yields to? > I think not. I think mathematics is itself a highly > specialized and carefully defined set of abstractions, which > do not admit to further abstraction via OOAD. > Hence, I think that examples or arguments about methodology > which draws its problems from the world of mathematics is > suspect  techniques which succeed or fail against math > problems may fail or succeed against games, web servers, GUIs, > ATC systems, et cetera. > I would be happy to hear responses from more experienced > object oriented designers. > Zooko

Wed, 18 Jun 1902 08:00:00 GMT 


Nick Leato #12 / 26

Newbie question re: circle and ellipse
Quote:
> >ALthough I agree with splitting the classes, there is a more natural > >split. Circles and Elipses are all types of conics. A conic class makes > >a very natural abstraction. Then circle inherits conic, ellipse inherits > >conics. You can now provide features in circle and ellipse that convert > >between the two. > If I may interject, I have been toying with the notion that > mathematics is too frequently called upon to provide simple > problems for programmers to practice their skills on. > I hypothesize that among problem domains that object oriented > designers need to tackle, almost none of them are very much > like mathematics. > Think about banking transactions, air traffic control systems, > GUIs, web servers, games. Do any of them, from the point of > view of OOAD, yield to the same techniques of abstraction that > mathematics yields to? > I think not. I think mathematics is itself a highly > specialized and carefully defined set of abstractions, which > do not admit to further abstraction via OOAD. > Hence, I think that examples or arguments about methodology > which draws its problems from the world of mathematics is > suspect  techniques which succeed or fail against math > problems may fail or succeed against games, web servers, GUIs, > ATC systems, et cetera. > I would be happy to hear responses from more experienced > object oriented designers.
Ouch! Bit below the belt ;)  Nick

Wed, 18 Jun 1902 08:00:00 GMT 


John Nag #13 / 26

Newbie question re: circle and ellipse
Quote:
>The modeling of shape classes is frequently used because the domain is >understood by most people. Granted, such concepts as circle and ellipse have >welldefined meanings among geometricians. However, that in no way diminishes >their illustrative power. Indeed, problems similar to the "Is a circle an >ellipse?" problem crop up in every domain, whether or not the concepts in the >domain are rigorously defined.
The AI field struggled with this problem for years, trying to describe the world with "isa" relations. A good essay on the subject is Drew McDermott's "Artificial Intelligence meets Natural Stupidity". Some problems fit this model well, and some don't. Graphical user interfaces are the most notable example of a problem that doesn't fit the "isa" model well. But after a decade of struggling, big changes to C++, and Java, GUIs have been hammered into the object model with reasonable success. Actually, most trouble in interconnected objects comes not from the "isa" relation, but the "owns" relation. The question of who owns whom dominates C++ programming. Java uses garbage collection to get out from under that problem, and it seems to be a win. John Nagle

Wed, 18 Jun 1902 08:00:00 GMT 


Dean Rodde #14 / 26

Newbie question re: circle and ellipse
Quote:
> Actually, most trouble in interconnected objects comes not from > the "isa" relation, but the "owns" relation. The question of who > owns whom dominates C++ programming. Java uses garbage collection to > get out from under that problem, and it seems to be a win.
I kind of hate to open this can of worms again but... GC does not get you out from under the burden of who 'owns' an object, it gets you out of the burden who 'cleans up' an object (which is no one.) The issue of who 'owns' an object is a design issue and GC does nothing to help you with that. The fact that I 'give' an object to some other entity, means that the recipient should have control total over it in many cases. If I fail to remember this and give it to some other entity also and/or continue to manipulate it, this is a design flaw that can cause wierdness every bit as bad as in C++ where an object is destroyed while someone else is looking at it. The fact that GC lets me not worry about when it actually gets destroyed is a totally separate issue. So basically, the problem is that, Java just like C++, does not allow the developer to encode the semantics of object adoption and orphaning in the language itself. Therefore, only documentation and convention insure that the wrong thing does not get done. This is one of the reasons for my antiJava stance. I want the replacement to C++ to deal with fundamental issues of this sort. And, as has been discussed, many types of objects MUST be destroyed at a particular time because of their semantics. Thus, Java has an inconsistent cleanup mechanism which is very easy to accidentally misuse and thus cause problems just as bad as any that C++ has. Java loses the whole notion of 'janitor' objects which make C++ in many ways so safe an convenient (in its own way, which is obviuosly different from Java's so don't start arguing about that please.) Stack based objects, particularly stack based janitorial type objects, are a powerful tool for imposing language scope upon any number of phenomena. This is something that Java gave up when it adopted a pure GC architecture. Ok, so lets have another two weeks of meaningless arguments about this, whaddya say? :)  Dean Roddey Sr. Software Engineer Taligent, Inc

Wed, 18 Jun 1902 08:00:00 GMT 


Frank A. Adria #15 / 26

Newbie question re: circle and ellipse
Quote:
>> Actually, most trouble in interconnected objects comes not from >> the "isa" relation, but the "owns" relation. The question of who >> owns whom dominates C++ programming. Java uses garbage collection to >> get out from under that problem, and it seems to be a win. >The fact that I 'give' an object to some other entity, means that the >recipient should have control total over it in many cases. If I fail to >remember this and give it to some other entity also and/or continue to >manipulate it, this is a design flaw that can cause wierdness every bit >as bad as in C++ where an object is destroyed while someone else is >looking at it. The fact that GC lets me not worry about when it actually >gets destroyed is a totally separate issue. >So basically, the problem is that, Java just like C++, does not allow >the developer to encode the semantics of object adoption and orphaning >in the language itself. Therefore, only documentation and convention >insure that the wrong thing does not get done. This is one of the >reasons for my antiJava stance. I want the replacement to C++ to deal >with fundamental issues of this sort.
Well, if no one refers to the same thing, the issue is moot. Which is why linear languages (see Henry Baker's papers on the issue) can reason about references and know when to delete objects without the overhead of GC systems. Also, if one has a pure functional language, you can insure that objects don't have multiple references (just copy the referred objects on function call). Multiple references ARE a {*filter*} (most of the space problems I had in a Smalltalk system came from not releasing dependants and GC didn't help with that). In short, ownership and/or nonownership is not the problem  MUTABLE STATE is the problem. Quote: >Ok, so lets have another two weeks of meaningless arguments about this, >whaddya say? :)
You bet!  Frank A. Adrian First DataBank
This message does not necessarily reflect those of my employer, its parent company, or any of the cosubsidiaries of the parent company.

Wed, 18 Jun 1902 08:00:00 GMT 


Page 1 of 2

[ 26 post ] 

Go to page:
[1]
[2] 
