Prev: Java Video Tutorial
Next: Getting raw data of an object in memory
From: Arne Vajhøj on 28 Jun 2010 21:36
On 28-06-2010 05:29, ClassCastException wrote:
> On Sat, 26 Jun 2010 13:09:25 -0400, Arne Vajhøj wrote:
>> And in general those figure examples often lead to problems like the
>> wellknown Rectangle versus Square problem.
>
> A problem that goes away when you make the durn things immutable.

Not completely.

Methods that return a new modified instance would still have
some weird behavior.

Arne

From: Arne Vajhøj on 28 Jun 2010 21:37
On 28-06-2010 08:20, Lew wrote:
> 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.

If you make both Rectangle and Square final then yes.

But ...

Arne

From: Peter Duniho on 28 Jun 2010 22:09
Arne Vajhøj wrote:
> On 28-06-2010 05:29, ClassCastException wrote:
>> On Sat, 26 Jun 2010 13:09:25 -0400, Arne Vajhøj wrote:
>>> And in general those figure examples often lead to problems like the
>>> wellknown Rectangle versus Square problem.
>>
>> A problem that goes away when you make the durn things immutable.
>
> Not completely.
>
> Methods that return a new modified instance would still have
> some weird behavior.

Depends on the signature of the method and its precise behavior.

It's debatable whether one really needs methods in the type that return
modified versions of the original. But assuming one does, the method
could easily enforce Rectangles and Squares, either by throwing
exceptions if misused (which is actually possible even with mutable
types, though would involve more work), or by providing methods that
always return the right kind of type (Square if the new dimensions are
equal, Rectangle otherwise).

There's no reason for weird behavior to exist. Just don't implement
weird behavior. :)

Pete
From: Arne Vajhøj on 28 Jun 2010 22:16
On 28-06-2010 22:09, Peter Duniho wrote:
> Arne Vajhøj wrote:
>> On 28-06-2010 05:29, ClassCastException wrote:
>>> On Sat, 26 Jun 2010 13:09:25 -0400, Arne Vajhøj wrote:
>>>> And in general those figure examples often lead to problems like the
>>>> wellknown Rectangle versus Square problem.
>>>
>>> A problem that goes away when you make the durn things immutable.
>>
>> Not completely.
>>
>> Methods that return a new modified instance would still have
>> some weird behavior.
>
> Depends on the signature of the method and its precise behavior.
>
> It's debatable whether one really needs methods in the type that return
> modified versions of the original. But assuming one does,

It is rather common to have such. The Java API itself has some
important ones.

> the method
> could easily enforce Rectangles and Squares, either by throwing
> exceptions if misused (which is actually possible even with mutable
> types, though would involve more work), or by providing methods that
> always return the right kind of type (Square if the new dimensions are
> equal, Rectangle otherwise).

What should the formal return type be?

The sub class can return the super class but not the
other way around.

> There's no reason for weird behavior to exist. Just don't implement
> weird behavior. :)

Difficult to avoid if the classes should have rich functionality.

Arne
From: Arne Vajhøj on 28 Jun 2010 22:37
On 26-06-2010 17:14, Martin Gregorie wrote:
> On Sat, 26 Jun 2010 13:09:25 -0400, Arne Vajhøj wrote:
>
>> 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.
>>
> Unfortunately not:
>
> "Data Abstraction and Object-Oriented Programming in C++" by Gorlen,Orlow
> and Plexico uses Point as components within Line and Circle classes
> though without explicit inheritance: I don't read C++ well enough to
> understand much more than this, but I think there's no inheritance and no
> abstract base class.

Many geometric figures would contain points as members (corners,
center etc.) - that is not quite the same as extending.

> However, Ivor Horton's "Beginning Java" does better: I misremembered what
> it said. It uses a utility Point class but bases its shapes on an
> abstract Element base class which only has a colour attribute.

I assume that is something like my Figure class.

>>> 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.
>>
> True enough, though a Bird with as species attribute would be very useful
> since it could be used for anything from building an experimental results
> database for a study of avian flight performance to building a cladistic
> species descent tree. Doing either would be harder if Bird was merely an
> abstract base class.

Oh yes.

But often the discussion about class hierarchy becomes a lot
easier when you have a specific context. Often the domain
logic / business rules / whatever they are called make it
rather obvious what to do.

Arne

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Java Video Tutorial
Next: Getting raw data of an object in memory