Prev: Java Video Tutorial
Next: Getting raw data of an object in memory
From: Arne Vajhøj on 26 Jun 2010 13:09
On 26-06-2010 12:21, Martin Gregorie wrote:
> On Sat, 26 Jun 2010 11:53:23 -0400, Arne Vajhøj wrote:
>> I would even say that #3 is sometimes practical, but it is not good OOP.
> Then the geometric drawing example that's often seen in teach-yourself
> Java and C++ books where Point is defines as a concrete base class and
> then extended extended to form Circle, Ellipse, Rectangle, Triangle, ....
> classes shouldn't really be used because its bad OOP?

I assume that you mean Figure and not Point as base class.

Yes - I don't think Figure should be concrete.

And in general those figure examples often lead to problems like
the wellknown Rectangle versus Square problem.

> However, I don't think Bird is a particularly good example simply because
> almost all case I can think of where I'd might be interested in using it
> would compare birds across species in ways that would require the same
> attributes in all instances, so extensions simply wouldn't arise,
> particularly if the attributes flightless, aquaticSpecies and (possibly)
> diver were used.

A lot depends on the context.

Arne
From: Arved Sandstrom on 26 Jun 2010 14:07
Arne Vajhøj wrote:
> On 26-06-2010 10:59, Arved Sandstrom wrote:
>> Eric Sosman wrote:
>>> On 6/26/2010 9:40 AM, Patricia Shanahan wrote:
>> [ SNIP ]
>>
>>>> Sometimes I have enough information to classify the bird by species,
>>>> sometimes by general type - I can tell the difference between a duck
>>>> and
>>>> a vulture, without necessarily knowing the exact species - and
>>>> sometimes
>>>> just by "bird" plus description.
>>>
>>> It seems to me that the choice of taxonomy is driven not by the
>>> nature of the things "out there" in the world, but by their nature
>>> in the program's model of the world. One program may find it useful
>>> to distinguish between Thrush and Swallow. Another may need to go
>>> further and distinguish Goose from Gander. Still another may just
>>> use Bird, with a single parameter describing how much damage it does
>>> when sucked into an aircraft engine. The features chosen for modeling
>>> have more to do with the nature of the model than with the true nature
>>> (whatever *that* is) of the thing modeled.
>>
>> This is all true. But I'll wager that rarely - maybe even very rarely -
>> do you really benefit from trying to capture any of those distinguishing
>> features in an inheritance tree. Not just for this Bird example but for
>> a whole bunch of other examples.
>>
>> My main point would be that a real-world taxonomy is not often modelled
>> best with a programming taxonomy implemented with traditional
>> inheritance. For a variety of reasons.
>
> I don't think anyone is arguing against the two cases:
> 1) just having a Bird class
> 2) having an abstract Bird class and concrete subclasses
> I think the argument is against having:
> 3) instances of Bird and instances of subclasses of Bird in the
> same app
>
> I would even say that #3 is sometimes practical, but it is not
> good OOP.
>
> Arne

Agreed. In this particular case, let's say where sometimes you only know
it's a bird without too much extra information, sometimes you're
positive it's a duck, and sometimes you know for a fact it's a male
hooded merganser, and you're interested in recording all observed birds
with as much information as is possible, I'd stick with #1.

My wider argument, made in the post you answered and also in another, is
that I'd rarely consider in this or other situations going with #2
unless the inheritance tree was only one level deep. But even more often
I'd stick with interfaces and composition/aggregation to achieve what I
want.

AHS

--
Any code of your own that you haven't looked at for six or more months
might as well have been written by someone else.
-- Eagleson's Law
From: Lew on 28 Jun 2010 08:20
Arne Vajhøj wrote:
>> And in general those figure examples often lead to problems like the
>> wellknown Rectangle versus Square problem.

ClassCastException wrote:
> A problem that goes away when you make the durn things immutable.

Not really, but it does go away when you make the classes final.

--
Lew
From: Arne Vajhøj on 28 Jun 2010 16:55
On 28-06-2010 16:43, Tom Anderson wrote:
> On Mon, 28 Jun 2010, Lew wrote:
>> Tom Anderson wrote:
>>> And of course, it goes without saying that:
>>>
>>> Hand.getBird().equals(Collections.asList(Bush.getBird(),
>>> Bush.getBird()))
>>
>> That works as a pun, but as Java code would fail to yield 'true' under
>> conformant implementations of 'equals()'.
>
> I forgot to mention that Bird implements List<Bird>. Weird, but there
> you go.

Very weird!

Arne

From: Eric Sosman on 28 Jun 2010 17:35
On 6/28/2010 4:42 PM, Tom Anderson wrote:
> On Fri, 25 Jun 2010, Eric Sosman wrote:
>
>> On 6/25/2010 6:55 PM, Arne Vajh?j wrote:
>>> On 25-06-2010 04:07, Simon Brooke wrote:
>>>> [...]
>>>> Are you saying that class Bird ought not to be instantiable?
>>>
>>> Yes.
>>>
>>> There are no bird instances in the real world. They are all
>>> instances of some type of bird.
>>
>> That way lies madness. There are no Parrot instances in
>> the real world, only Polly and Snoofles and FeatheredBastard and
>> so on.
>
> Why aren't those instances of Parrot?

I was trying to follow Arne Vajh�j's position "There are no bird
instances in the real world. They are all instances of some type of
bird" to an absurd consequence, thereby casting doubt on it. By
"that way lies madness," I meant that refusal to generalize dooms
every model but one to failure. (The one exception exists, but is
rather difficult to comprehend; centuries of debate have not fully
explained the Programmer's purposes, nor even proved his sanity.)
Eventually, every practical model must consider N distinct entities
and say "These are all Parrots" or "These are all Birds" or "These
are all CarbonBasedLifeForms." The much-discussed "real world" is
not subject to this built-in crudification of detail -- but the MDRW
doesn't have "classes" at all, merely individuals. ("Individual what?"
is a question I'd prefer to leave to the philosophers; as a computer
person, I can see to it that they'll starve.)

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Java Video Tutorial
Next: Getting raw data of an object in memory