Newbie question re: circle and ellipse
Author Message
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 statically-typed 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
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 statically-typed 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
Newbie question re: circle and ellipse

Wed, 18 Jun 1902 08:00:00 GMT
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

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
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

> 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

--

Wed, 18 Jun 1902 08:00:00 GMT
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
: >
: > 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
:
: --

--
"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
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

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 object-based. But if your problem is
really not object-based, why are you forcing it to fit

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
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.

Object-oriented 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
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

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
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
well-defined 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
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 on-screen
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 multi-dimensional 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 pre-defined '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

> 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
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

> 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
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
>well-defined 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 "is-a" 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 "is-a" 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 "is-a" 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
Newbie question re: circle and ellipse

Quote:

>     Actually, most trouble in interconnected objects comes not from
> the "is-a" 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

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 anti-Java 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
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.

------------------------------------
Dean Roddey
Sr. Software Engineer
Taligent, Inc

Wed, 18 Jun 1902 08:00:00 GMT
Newbie question re: circle and ellipse

Quote:

>>     Actually, most trouble in interconnected objects comes not from
>> the "is-a" 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 anti-Java 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 non-ownership is not the problem - MUTABLE
STATE is the problem.

Quote:

You bet!
--
First DataBank

This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.

Wed, 18 Jun 1902 08:00:00 GMT

 Page 1 of 2 [ 26 post ] Go to page: [1] [2]

Relevant Pages