From: Martin Gregorie on
On Sat, 26 Jun 2010 21:14:29 +0000, 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.
>
> 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.
>
>>> 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.
>
Is my first example (the flight performance measurements database) a case
for using the Bird object with factories, such as a RacingPigeon factory
or a HerringGull factory, rather than subclasses?


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: ClassCastException on
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.
From: Andreas Leitgeb on
ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
> On Fri, 25 Jun 2010 09:28:16 +0000, Andreas Leitgeb wrote:
>> Simon Brooke <stillyet+nntp(a)googlemail.com> wrote:
>>> [Bird, Penguin extends Bird - should Bird be abstract?]
>> Actually, you won't ever find a real instance of Bird in nature that
>> isn't really of some more specific class. Be it Hawk, Craw, Ostrich,
>> Turkey, Chicken, ...
> Misspellings like that really stick in my crow... :-)
:-}

PS: the whole discussion of whether a class-hierarchy based on
natural species makes sense is besides the original point.
The rule of thumb would be: If you see a need for an exact
class-check to get your .equals() correct, then you're
better off making non-leaf classes abstract.

From: Lew on
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()'.

You'd need evaluation functions that return comparable values for a
bird in the hand vs. a collection of birds in the bush:


hand.eval( hand.getBird() ).equals( bush.eval( bush.getBirds().sublist( 0,
2 )))

or an extrinsic 'Evaluator' instance, 'evaluator' with method
'eval( Evaluable, Collection<Bird> )', where 'Hand' and 'Bush' both
implemant 'Evaluable':

evaluator.eval( hand,
Collections.asList( { hand.getBird() } )).equals( evaluator.eval( bush,
bush.getBirds().sublist( 0, 2 ) ))

--
Lew
From: Tom Anderson on
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?

tom

--
Fitter, Happier, More Productive.