On Sunday, November 30, 2003, at 12:09:43 PM, Steve Howell wrote:

> 1) Circle and Ellipse both have a method called
> getDefininingCoordinatesAndLength.
> 2) Circle would delegate out to getCenterAndRadius.
> 3) Ellipse would delegate out to getFociAndMajorAxisLength.

So this method would return a single point and radius in the one case, and
two points and one length in the other case?

What kind of object would this getDefininingCoordinatesAndLength method be
returning, and how would one use it?

> If this kind of refactoring seems to pose an unsolvable paradox to
> object purists, then maybe there is something wrong with object purism. :)

Ahem.

Ron Jeffries
www.XProgramming.com
I must create a system, or be enslaved by another man's;
I will not reason and compare; my business is to create. --William Blake

----- Original Message -----
From: "robertdw26"
<robert.watkins.at.suncorp.com.au@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, November 30, 2003 6:25 AM
Subject: Re: [XP] Circle/Ellipse dilemma


> --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
> > The fact is, I'm having a lot of difficulty figuring out what the
> > dilemma is. An ellipse has two foci and a semi-major axis. A
> > circle has a center and a radius. So if I make circle a subclass
> > of ellipse, and I ask for an ellipse, I can get a circle.
> >
> > So? As long as I override the
> > getFoci and getSemiMajorAxis methods to return the center
> > and the radius, it will work, and the overrides themselves make
> > the mathematically correct statement about the relationship
> > between the two figures.
>
> The "problem" is when you have an Ellipse that you can do this to:
>   setFoci(somePoint, someOtherPoint);
>
> and you substitute in a Circle. All of a sudden, it breaks. This is a
> violation of the LSP design principle.

As another interesting variation on this theme, if someone
actually does this, then I can possibly write the Circle
class with an override to setFoci that looks like this:

     def setFoci(self, focusOne, focusTwo):
         if focusOne != focusTwo:
             self.__class__ = Ellipse
             self.setFoci(focusOne, focusTwo)
         else:
             # code appropriate to a circle

This is, of course, Python. I don't think you can
redefine the class of an instance in midflight...

John Roth
>
> Unless, of course, the contract for Ellipse says that some
> implementations may impose restrictions, in which case it just meant
> you had a poorly coded client.
>
> Robert.

This really has nothing to do with XP.

From: "Keith Ray" <keithray.at.mac.com@...>
Sent: Sunday, November 30, 2003 12:36 PM
Subject: Re: [XP] Circle/Ellipse dilemma


> This really has nothing to do with XP.

Well, start a new thread. I'm sure there are topics we
haven't discussed to death recently, but none of them
are things I'm currently dealing with at the moment.

John Roth

Keith Ray wrote:

> This really has nothing to do with XP.

Actually, I think the whole Circle/Ellipse dilemma is a strong argument
*for* XP - or at least the YAGNI/Emergent Design part of it.

We don't currently know of a good way to model the relationship between
Circles and Ellipses in a way that works for *all* problem domains. This
could easily cause analysis paralysis in a BDUF environment. In an XP
environment, on the other hand, only that which is actually needed will
be coded, and the rest can be left to the theoreticians and comp.object
partisans. If they come up with a nice, elegant, general solution, we
can apply it; until then, we'll deliver business value.

Works for me...

--
Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
The opinions expressed herein are at best coincidentally related to
those of any past, present or future employer.

On Sunday, November 30, 2003, at 11:15  AM, Edmund Schweppe wrote:

> Keith Ray wrote:
>
>> This really has nothing to do with XP.
>
> Actually, I think the whole Circle/Ellipse dilemma is a strong argument
> *for* XP - or at least the YAGNI/Emergent Design part of it.

Well, then start with a Customer's story, acceptance test, TDD, and so
on. Is this Circle/Ellipse thing meant for CAD / Drawing program, or
what?

--
C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>

On 2003.11.30, Ron Jeffries <ronjeffries@...> wrote:
> > Whether you look at a circle as a conic section, a cartesian
> > relationship, a geometric construction, etc., it's still always a
> > special case of an ellipse.
>
> Then why does it not work well to subclass Circle from Ellipse?
> (And why does it not work well to subclass Ellipse from Circle either?

Because the languages being used don't typically enjoy variable length
argument lists.  Also, "polymorphism" doesn't mean "this object changes
its class from one to another based on its properties or attributes" and
that's weak.

Suppose we had a programming language where one could define the
ClosedCurve class with a method addFocus(ClosedCurveFocus focus) ... if
you only add one focus (which might include the corresponding radius for
that focus), then that object would be a ClosedCurve *AND* a Circle, and
tests for object.class == ClosedCurve and object.class == Circle would
both evaluate to true.  (Coincidentally, object.class == Ellipse would
also be true.)  However, if you called object.addFocus(focus) with a
different focus, object.class == Circle would be false (while the other
two tests would remain true).

What's nice is that for all the different "classes" where the #class ==
comparison is true, the methods associated to those classes would be
"available" to the caller or user of the object.  Methods would come and
go as the properties of the object changes.  This is what I think as
useful "polymorphism" -- the object changes shape to reflect its
properties or attributes.  This is also where I think multiple
inheritance makes a lot of sense ... maybe the only way it makes a lot
of sense ...

I'm sure this probably violates plenty of OO principles ... but I'm
lucky in that I'm too dumb to know what they are, so I don't feel guilty
about violating any of them.  :-)

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

On 2003.11.30, Ron Jeffries <ronjeffries@...> wrote:
> On Sunday, November 30, 2003, at 9:08:56 AM, Dossy wrote:
>
> > On 2003.11.30, Ron Jeffries <ronjeffries@...> wrote:
> >> 2. Inheritance in programming is, to me, not as "religious" or formal
> >> an issue as it seems to be to some folks.
>
> > Or, perhaps, that reality contains a very large set of "exceptions" to
> > general rules and that "principles" in the programming domain suggest
> > that we shouldn't be modeling things as a general rule coupled with a
> > set of exceptions?
>
> I don't understand what you're getting at here ...

The point is that if I drew a circle and an ellipse for my 3.75 year old
daughter, and asked her, "Are these two things like each other?" I bet
she'd say, "Yes."  (I'll have to experiment later when she wakes up from
her nap.)

There's something intuitively similar between circles and ellipses.  In
general, they probably share lots of traits in common -- the "general
rule" that describes closed curves defined by foci and radii.  However,
the reason we, as software engineers using object oriented languages,
have difficulty modeling this stems from the differences between circles
and ellipses -- the exceptions to this general rule.

Perhaps the current object-oriented paradigm is not flexible enough to
properly model everything correctly or safely.  *OR*, we just kludge
things and say "not everything NEEDS to be modelled in a way that's
intuitive" and move on and solve the real problems at hand ...

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

On 2003.11.30, yahoogroups@... <yahoogroups@...> wrote:
> ----- Original Message -----
> From: "robertdw26"
> <robert.watkins.at.suncorp.com.au@...>
> >
> > The "problem" is when you have an Ellipse that you can do this to:
> >   setFoci(somePoint, someOtherPoint);
> >
> > and you substitute in a Circle. All of a sudden, it breaks. This is a
> > violation of the LSP design principle.
>
> As another interesting variation on this theme, if someone
> actually does this, then I can possibly write the Circle
> class with an override to setFoci that looks like this:
>
>     def setFoci(self, focusOne, focusTwo):
>         if focusOne != focusTwo:
>             self.__class__ = Ellipse
>             self.setFoci(focusOne, focusTwo)
>         else:
>             # code appropriate to a circle
>
> This is, of course, Python. I don't think you can
> redefine the class of an instance in midflight...

Python doesn't allow you to define two methods with different
signatures, does it?  i.e.:

     def setFoci(self, focus):
         # this is a circle

     def setFoci(self, focusOne, focusTwo):
         # this is an ellipse

Last one wins, right?  This is why I think having the method be
addFocus(focus) keeps things sane:  if you call it twice with
two different foci, the object should "morph" into an Ellipse.
Otherwise, with one foci it should be BOTH a Circle AND an
Ellipse at the same time.

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

On 2003.11.30, Keith Ray <keithray@...> wrote:
> This really has nothing to do with XP.

Suppose you had to implement something in your project and you were
OneTeam all in OneBigRoom and the problem was similar in nature to the
Circle/Ellipse dilemma.  How would you determine what
TheSimplestThingThatCouldPossiblyWork is?  How do you appease the
OO-fanatics on the team with your design?  Suppose you broke out the
index cards for a quick CRC session -- would the Circle card overlap the
Ellipse card, vice versa, or sit in an different relationship entirely?

Or, do we put on the big SumoSuits and FoamPaddedSwords and do it the
old fashioned way?  "Two man enter, one man leave" -- that's the one who
gets to decide the design?  In gnarly situations such as the
Circle/Ellipse dilemma, there are times when you can't reach consensus
as to how to best solve the problem.  Do we just arbitrarily pick one
(lesser of two evils, or the one we've never tried before, or some other
strategy for choosing)?  Is there inherent risk in this arbitrary choice
in design?  Or, by having all this debate, are we doing too much
DesignUpFront?

Answer as many questions as you feel compelled to in order to make this
discussion relevant to XP for you.  :-)

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

On Sunday, November 30, 2003, at 12:13:59 PM, Steve Howell wrote:

> Ron Jeffries wrote:

>>I pose it because I think you'll learn more from working on the problem
>>than from speculating about what mathematicians and OO people may or may
>>not be understanding.
>>
>>
> I agree. I was trying to figure out why you were starting the
> speculation in the first place. ;)

> You said: "Mathematicians usually don't consider as much behavior as OO..."

> That statement can actually lead us in an interesting direction, but I
> wanted a specific example.

> Do you have one?

Sure. When considering circles and ellipses, a mathematician, even though
"knowing" that a circle is an ellipse, doesn't feel obligated to have the
same "method" work in both, such as setMinorAxis() or moveFoci() or
setLineThickness() or colorInside().

This last is an interesting one. Coloring inside a conic section (or, much
worse, inside a general polygon, is a very tricky algorithm, for which the
math guys have given us very little help.

They're different disciplines and they think about different things. It's
all good -- just different.

Ron Jeffries
www.XProgramming.com
Get over it.  -- The Eagles

Ron Jeffries wrote:

>Sure. When considering circles and ellipses, a mathematician, even though
>"knowing" that a circle is an ellipse, doesn't feel obligated to have the
>same "method" work in both, such as setMinorAxis() or moveFoci() or
>setLineThickness() or colorInside().
>
>
Sure, mathematicians allow themselves to be pragmatic. I think should
software developers should allow themselves the same luxury.

>This last is an interesting one. Coloring inside a conic section (or, much
>worse, inside a general polygon, is a very tricky algorithm, for which the
>math guys have given us very little help.
>
>
Heh. Maybe the math is just beyond what most software developers are
willing to study. :)

It sounds somewhat related to tiling problems, which I know
mathematicians have studied in absurd depth.

>They're different disciplines and they think about different things. It's
>all good -- just different.
>
>
I agree. In this particular example, though, mathematicians are our
domain experts.

Ron Jeffries wrote:

>On Sunday, November 30, 2003, at 12:09:43 PM, Steve Howell wrote:
>
>
>
>>1) Circle and Ellipse both have a method called
>>getDefininingCoordinatesAndLength.
>>2) Circle would delegate out to getCenterAndRadius.
>>3) Ellipse would delegate out to getFociAndMajorAxisLength.
>>
>>
>
>So this method would return a single point and radius in the one case, and
>two points and one length in the other case?
>
>What kind of object would this getDefininingCoordinatesAndLength method be
>returning, and how would one use it?
>

It could return an EllipseDefinition object, or its subclass, a
CircleDefinition object.

Or maybe you have an abstract method called
getShapeByPromptingForDefiningPointsAndLength, which returns an Ellipse,
or its subclass, a Circle.

And you might abbreviate that method to get().

I haven't really been given any requirements here, so this is all
speculative. There weren't any requirements to motivate the need for a
setFocus() method in the first place, so the whole disussion may have
just been a tedious illustration of what happens when we BDUF. :)

----- Original Message -----
From: "Dossy" <dossy.at.panoptic.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, November 30, 2003 4:16 PM
Subject: Re: [XP] Circle/Ellipse dilemma


> On 2003.11.30, yahoogroups@... <yahoogroups@...> wrote:
> > ----- Original Message -----
> > From: "robertdw26"
> > <robert.watkins.at.suncorp.com.au@...>
> > >
> > > The "problem" is when you have an Ellipse that you can do this to:
> > >   setFoci(somePoint, someOtherPoint);
> > >
> > > and you substitute in a Circle. All of a sudden, it breaks. This is a
> > > violation of the LSP design principle.
> >
> > As another interesting variation on this theme, if someone
> > actually does this, then I can possibly write the Circle
> > class with an override to setFoci that looks like this:
> >
> >     def setFoci(self, focusOne, focusTwo):
> >         if focusOne != focusTwo:
> >             self.__class__ = Ellipse
> >             self.setFoci(focusOne, focusTwo)
> >         else:
> >             # code appropriate to a circle
> >
> > This is, of course, Python. I don't think you can
> > redefine the class of an instance in midflight...
>
> Python doesn't allow you to define two methods with different
> signatures, does it?  i.e.:
>
>     def setFoci(self, focus):
>         # this is a circle
>
>     def setFoci(self, focusOne, focusTwo):
>         # this is an ellipse
>
> Last one wins, right?  This is why I think having the method be
> addFocus(focus) keeps things sane:  if you call it twice with
> two different foci, the object should "morph" into an Ellipse.
> Otherwise, with one foci it should be BOTH a Circle AND an
> Ellipse at the same time.

You do it this way...

     def SetFoci(self, focusOne, focusTwo = None):

Of course, there are significant limitations when the
signatures are *too* different. Then you have to do
other things to get the same effect as multi-methods.
There are packages to do just that.

When you can reassign the base class on the fly,
you can essentially pick the methods you want the
instance to respond to.

John Roth



>
> -- Dossy
>

----- Original Message -----
From: "Dossy" <dossy.at.panoptic.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, November 30, 2003 4:20 PM
Subject: Re: [XP] Circle/Ellipse dilemma


> On 2003.11.30, Keith Ray <keithray@...> wrote:
> > This really has nothing to do with XP.
>
> Suppose you had to implement something in your project and you were
> OneTeam all in OneBigRoom and the problem was similar in nature to the
> Circle/Ellipse dilemma.  How would you determine what
> TheSimplestThingThatCouldPossiblyWork is?  How do you appease the
> OO-fanatics on the team with your design?  Suppose you broke out the
> index cards for a quick CRC session -- would the Circle card overlap the
> Ellipse card, vice versa, or sit in an different relationship entirely?
>
> Or, do we put on the big SumoSuits and FoamPaddedSwords and do it the
> old fashioned way?  "Two man enter, one man leave" -- that's the one who
> gets to decide the design?  In gnarly situations such as the
> Circle/Ellipse dilemma, there are times when you can't reach consensus
> as to how to best solve the problem.  Do we just arbitrarily pick one
> (lesser of two evils, or the one we've never tried before, or some other
> strategy for choosing)?  Is there inherent risk in this arbitrary choice
> in design?  Or, by having all this debate, are we doing too much
> DesignUpFront?
>
> Answer as many questions as you feel compelled to in order to make this
> discussion relevant to XP for you.  :-)

To build on Keith Ray's comment: we don't have any requirements
for the program this is a part of. If we did, I bet there wouldn't be
that much discussion about how to implement it.

John Roth
>
> -- Dossy
>

----- Original Message -----
From: "Steve Howell" <showell.at.zipcon.net@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, November 30, 2003 5:07 PM
Subject: Re: [XP] Circle/Ellipse dilemma


> Ron Jeffries wrote:
>
> >On Sunday, November 30, 2003, at 12:09:43 PM, Steve Howell wrote:
> >
> >
> >
> >>1) Circle and Ellipse both have a method called
> >>getDefininingCoordinatesAndLength.
> >>2) Circle would delegate out to getCenterAndRadius.
> >>3) Ellipse would delegate out to getFociAndMajorAxisLength.
> >>
> >>
> >
> >So this method would return a single point and radius in the one case,
and
> >two points and one length in the other case?
> >
> >What kind of object would this getDefininingCoordinatesAndLength method
be
> >returning, and how would one use it?
> >
>
> It could return an EllipseDefinition object, or its subclass, a
> CircleDefinition object.
>
> Or maybe you have an abstract method called
> getShapeByPromptingForDefiningPointsAndLength, which returns an Ellipse,
> or its subclass, a Circle.
>
> And you might abbreviate that method to get().
>
> I haven't really been given any requirements here, so this is all
> speculative. There weren't any requirements to motivate the need for a
> setFocus() method in the first place, so the whole disussion may have
> just been a tedious illustration of what happens when we BDUF. :)

Well, maybe. Let's assume we've got a drawing program where
you can pull various parts of figures around with the mouse and see
where that leads us...

Of course, that won't lead us to attempting to slide a circle
in where the program wants an ellipse, will it?

John Roth
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

>>If you think about it, it's quite a stretch to presume that a data structure
>>that represents a circle, and another data structure that represents an
>>ellipse should be strongly related.  It is true that circles and ellipses
>>are related.  But why should that relationship extend to the data structures
>>that represent them?
>>
SH> If mathematicians can define circles and ellipses in such a way that the
SH> relationship between them is clear, then shouldn't software developers
SH> be able to do that as well?

SH> Isn't code just an algebra of sorts?

SH> Do software developers find less value in isomorphisms than mathematicians?

There is mathematics which desribes good inheritance relationships.
If you want to check it out, take a look at the papers on Behavioral
Subtyping by Barbara Liskov and Jeannette Wing.


Michael Feathers
www.objectmentor.com

RJ> Yes. And this is the essence of the Circle/Ellipse "problem". There seems
RJ> to be no order of inheritance that makes all the contracts one might like
RJ> to have work. I'm not deeply troubled by this for two reasons:

RJ> 1. Mathematics usually doesn't consider as many behaviors as OO, so they
RJ> are getting off easy saying that a circle is a special kind of ellipse or
RJ> that both are conic sections, or whatever they choose.

RJ> 2. Inheritance in programming is, to me, not as "religious" or formal an
RJ> issue as it seems to be to some folks. Probably I'm missing something, or
RJ> maybe I just don't work on hard enough problems. (Or maybe all problems are
RJ> simple when you have a brain the size of a planet. No, that couldn't be it,
RJ> I'm too stupid sometimes.)

It's all just backwards-compatible versioning.  If you look at
subclassing a class as making a new "version" of the class, it pays to
make sure that it works with the code that used it before.


Michael Feathers
www.objectmentor.com

yjc> Inheritance presupposes a particular kind of substitutability. If your
yjc> application doesn't allow for that kind of substitutability, then you can't
yjc> use inheritance. I suspect one of the "roots" of the "dilemma" is that
yjc> inheritance simply isn't a completely adequate model for what we
yjc> intuitively think of as an "is-a" relationship, no matter how neat it
yjc> looks on a UML diagram. In fact, I've seen a fair number of references
yjc> recently that are attempting to downplay inheritance in the OO model
yjc> as just not being that universally useful a facility.

When I teach people, I call it "behaves-as" rather than "is-a" and tell
them why.  There are an incredible number of examples of "is-a" that
either cause trouble or are downright silly, so the examples are not
hard to find.

When I'm pressed for a very public example, I show them
Collections.unmodifiableList in the JDK.


Michael Feathers
www.objectmentor.com

"Behaves-as" sounds like it could include
private inheritance - which is usually not
really a proper inheritance relationship,
but rather only (in hope) a convenient
implementation.  Or worse.

I don't think this is what you mean, but
can you comment?


Michael Feathers wrote:
> yjc> Inheritance presupposes a particular kind of substitutability. If your
> yjc> application doesn't allow for that kind of substitutability, then you
can't
> yjc> use inheritance. I suspect one of the "roots" of the "dilemma" is that
> yjc> inheritance simply isn't a completely adequate model for what we
> yjc> intuitively think of as an "is-a" relationship, no matter how neat it
> yjc> looks on a UML diagram. In fact, I've seen a fair number of references
> yjc> recently that are attempting to downplay inheritance in the OO model
> yjc> as just not being that universally useful a facility.
>
> When I teach people, I call it "behaves-as" rather than "is-a" and tell
> them why.  There are an incredible number of examples of "is-a" that
> either cause trouble or are downright silly, so the examples are not
> hard to find.
>
> When I'm pressed for a very public example, I show them
> Collections.unmodifiableList in the JDK.
>
>
> Michael Feathers
> www.objectmentor.com
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

----- Original Message -----
From: "Michael Feathers"
<mfeathers.at.mindspring.com@...>
To: "yahoogroups@..."
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, November 30, 2003 5:45 PM
Subject: Re[2]: [XP] Circle/Ellipse dilemma


>
> yjc> Inheritance presupposes a particular kind of substitutability. If
your
> yjc> application doesn't allow for that kind of substitutability, then you
can't
> yjc> use inheritance. I suspect one of the "roots" of the "dilemma" is
that
> yjc> inheritance simply isn't a completely adequate model for what we
> yjc> intuitively think of as an "is-a" relationship, no matter how neat it
> yjc> looks on a UML diagram. In fact, I've seen a fair number of
references
> yjc> recently that are attempting to downplay inheritance in the OO model
> yjc> as just not being that universally useful a facility.
>
> When I teach people, I call it "behaves-as" rather than "is-a" and tell
> them why.  There are an incredible number of examples of "is-a" that
> either cause trouble or are downright silly, so the examples are not
> hard to find.

Interesting thought! Thank you.

John Roth
>
> Michael Feathers
> www.objectmentor.com
>

ALB> Michael Feathers wrote:
>> yjc> Inheritance presupposes a particular kind of substitutability. If your
>> yjc> application doesn't allow for that kind of substitutability, then you
can't
>> yjc> use inheritance. I suspect one of the "roots" of the "dilemma" is that
>> yjc> inheritance simply isn't a completely adequate model for what we
>> yjc> intuitively think of as an "is-a" relationship, no matter how neat it
>> yjc> looks on a UML diagram. In fact, I've seen a fair number of references
>> yjc> recently that are attempting to downplay inheritance in the OO model
>> yjc> as just not being that universally useful a facility.
>>
>> When I teach people, I call it "behaves-as" rather than "is-a" and tell
>> them why.  There are an incredible number of examples of "is-a" that
>> either cause trouble or are downright silly, so the examples are not
>> hard to find.
>>
>> When I'm pressed for a very public example, I show them
>> Collections.unmodifiableList in the JDK.
>>
ALB> "Behaves-as" sounds like it could include
ALB> private inheritance - which is usually not
ALB> really a proper inheritance relationship,
ALB> but rather only (in hope) a convenient
ALB> implementation.  Or worse.

ALB> I don't think this is what you mean, but
ALB> can you comment?

True, it does sound like private inheritance in C++.  IIRC, at least
one author has described private inheritance that way.  But, when
I talk about inheritance, I explain that it is a relationship in
which programs should still work correctly when subclasses are
substituted for superclasses.  In other words, the subclass should
behave-as the superclass would in contexts where the superclass is
used.

Michael Feathers
www.objectmentor.com

SH> But you could be more pragmatic.  If the getFoci and setFoci methods
SH> seem to be crufting up the Circle class too much, then you might
SH> consider this refactoring:

SH> 1) Circle and Ellipse both have a method called
SH> getDefininingCoordinatesAndLength.
SH> 2) Circle would delegate out to getCenterAndRadius.
SH> 3) Ellipse would delegate out to getFociAndMajorAxisLength.

SH> If this kind of refactoring seems to pose an unsolvable paradox to
SH> object purists, then maybe there is something wrong with object purism. :)

When pragmatists are asked for the answer to the Circle/Eclipse
dilemma they say "it depends."  What does it depend upon?  The
behavior needed by the classes.

As the old saying goes:
"an object is what an object does."


Michael Feathers
www.objectmentor.com

yjc> As another interesting variation on this theme, if someone
yjc> actually does this, then I can possibly write the Circle
yjc> class with an override to setFoci that looks like this:

yjc>     def setFoci(self, focusOne, focusTwo):
yjc>         if focusOne != focusTwo:
yjc>             self.__class__ = Ellipse
yjc>             self.setFoci(focusOne, focusTwo)
yjc>         else:
yjc>             # code appropriate to a circle

yjc> This is, of course, Python. I don't think you can
yjc> redefine the class of an instance in midflight...


Seems like Circle wouldn't be a good name for that class any more.


Michael Feathers
www.objectmentor.com

KR> This really has nothing to do with XP.

Here's food for thought.. if you have a class hierarchy where you
have only one definition for each method (no overrides) you
dramatically reduce your chances of an LSP violation.  See why?

I guess having more than one definition for a method is a kind of
duplication, eh?


Michael Feathers
www.objectmentor.com

D> On 2003.11.30, Keith Ray <keithray@...> wrote:
>> This really has nothing to do with XP.

D> Suppose you had to implement something in your project and you were
D> OneTeam all in OneBigRoom and the problem was similar in nature to the
D> Circle/Ellipse dilemma.  How would you determine what
D> TheSimplestThingThatCouldPossiblyWork is?  How do you appease the
D> OO-fanatics on the team with your design?  Suppose you broke out the
D> index cards for a quick CRC session -- would the Circle card overlap the
D> Ellipse card, vice versa, or sit in an different relationship entirely?

Write both classes and pull the duplication up into a superclass.
I suspect that if the code you end up with in a superclass all was
originally duplicate code in subclasses and you avoid nulling out
behavior via overrides and mucking with protected data, you end
up with LSP compliant code emergently.


Michael Feathers
www.objectmentor.com

Anne & Larry Brunelle wrote:
> "Behaves-as" sounds like it could include
> private inheritance - which is usually not
> really a proper inheritance relationship,
> but rather only (in hope) a convenient
> implementation.  Or worse.

Inheritance is overrated... and, in any case, is only a convenient
implementation for propagating behaviour.

Consider the view of a client external to the class. They don't really care
about behavioural inheritance. They care about types, and type inheritance.
How the types are implemented under the cover is usually irrelevant to the
client. Even type inheritance is only a handy trick to enforce that if Type
Child is implemented, then you can treat it as a Type Parent as well.

"Behaves-as" is about all the client really cares about. "Can I take this
Circle and treat it like an Ellipse?" is the question at hand. And the
answer is, yes, you can, for the most part. And, if the Ellipse contract is
coded carefully, you can treat it as an Ellipse all the time.

Consider the Collections.unmodifiableList() that Michael Feathers brought
up. Strictly speaking, a client of a List class that tries to modify the
contents and _doesn't_ check for the UnsupportedOperationException is a poor
client. Sure, you can't substitute an unmodifiable List for a normal List in
such a client, but whose fault is that?

If you can break the mental connection between the type inheritance and the
behaviour inheritance, you'll (probably) end up being a better OO
programmer. :)

Robert.

--
               "Software is too expensive to build cheaply"
Robert Watkins                        J2EE Application System Specialist
http://robertdw.blogspot.com         Web & Integration Services, Suncorp
robertdw@...                  robert.watkins@...


--------------------------------------------------------------------------------\
---

The contents of this message are the views of the Author and do not necessarily
reflect the views of SUNCORP METWAY LTD  ABN 66 010 831 722.

The content of this e-mail, including attachments is a confidential
communication between the Suncorp Metway Group and the intended addressee. Any
unauthorised use of the contents is expressly prohibited. If you have received
this e-mail in error please contact the sender immediately and then delete the
message and any attachment(s).

http://www.suncorp.com.au

WR> Anne & Larry Brunelle wrote:
>> "Behaves-as" sounds like it could include
>> private inheritance - which is usually not
>> really a proper inheritance relationship,
>> but rather only (in hope) a convenient
>> implementation.  Or worse.

WR> Inheritance is overrated... and, in any case, is only a convenient
WR> implementation for propagating behaviour.

It seems like the industry did swing back hard against inheritance.
In the middle 90s, the swing went away from inheritance.  Microsoft
had their own internal inheritance debacles which ended up with an
object model that didn't have implementation inheritance (COM), and
the GOF Design Patterns book pretty much recommended against it,
showing that delegation was more flexible.  I suspect the move
towards "components" had something to do with it also.

But frankly, I use inheritance now more than I ever have.  There are a
couple of reasons:

1) It is easy to subclass and add behavior to make a test pass.  When
you've done that, you can use the tests to safely move to another
mechanism whenever you decide to.  No need to start that way.

2) Inheritance is a great mechanism for replacing code.  If you have a
legacy class that depends on something weird that it shouldn't depend
on in a test, you can subclass and replace that code to get the class
under test.

3) Superclasses are a great place to move algorithmic duplication. For
an example, imagine what JUnit would look like if the TestCase
runBare() method wasn't a template method.


Michael Feathers
www.objectmentor.com

Michael Feathers wrote:
> But frankly, I use inheritance now more than I ever have.  There are a
> couple of reasons:

I use inheritance a lot myself; it's very useful, for all of the reasons you
describe. However, I just remind myself that the type inheritance is more
important than the behaviour inheritance, and if subclassing becomes a pain,
then I don't use it. In many ways, I view superclasses as a way of removing
duplication more so than as a way of inheriting behaviour.

(Type inheritance (interfaces, in Java) also provide an excellent mechanism
for replacing code...)

Robert.

--
               "Software is too expensive to build cheaply"
Robert Watkins                        J2EE Application System Specialist
http://robertdw.blogspot.com         Web & Integration Services, Suncorp
robertdw@...                  robert.watkins@...


--------------------------------------------------------------------------------\
---

The contents of this message are the views of the Author and do not necessarily
reflect the views of SUNCORP METWAY LTD  ABN 66 010 831 722.

The content of this e-mail, including attachments is a confidential
communication between the Suncorp Metway Group and the intended addressee. Any
unauthorised use of the contents is expressly prohibited. If you have received
this e-mail in error please contact the sender immediately and then delete the
message and any attachment(s).

http://www.suncorp.com.au

Michael Feathers wrote:

> KR> This really has nothing to do with XP.
>
> Here's food for thought.. if you have a class hierarchy where you
> have only one definition for each method (no overrides) you
> dramatically reduce your chances of an LSP violation.  See why?
>
> I guess having more than one definition for a method is a kind of
> duplication, eh?

Yes, but it blows the Decorator pattern out of the water.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand