Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
- Subject: Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
- From: Ian Joyner <email@hidden>
- Date: Wed, 15 Feb 2006 10:09:39 +1100
On 14/02/2006, at 4:03 PM, Arturo Pérez wrote:
On Feb 13, 2006, at 6:10 PM, Ian Joyner wrote:
On 14/02/2006, at 2:32 AM, Arturo Perez wrote:
Well, I think each has a (sorry for pun) different role.
Inheritance is really about identifying common properties and
putting them in one place – thus about decomposition first, with
inheritance being the way to put it back together. While you can
put things back together with composition, inheritance offers a
higher level of abstraction which replaces lower-level language
mechanisms such as #include and import (although hybrid languages
still rely on such code maintenance facilities).
That may be. I think most ppl use inheritance incorrectly because
of the way that it is taught. Most view it as a form of taxonomy
(Mammals->Ursa->Grizzly or Numbers->Real->Integers) when oftentimes
the abstractions required in our profession are not so neatly
categorized.
Right. Taxonomy is certainly a way to figure out common features, but
the usual single inheritance forces you into a single restrictive
taxonomy. When coding you can factor out common features a number of
ways which leads to multiple taxonomies, so you could have taxonomies
based on number of legs, flying vs non-flying, swimming vs. land-
based. This leads to designs with nice small classes that handle
single aspects of behaviour (often adjectival), but unfortunately, it
is frowned upon by the theoretical inheritance people who go the
taxonomical route. Java's single inheritance is exactly that, the
theoretical taxonomy-based inheritance. (Mind you you've got to
admire the way they forced the theoretical way on everyone, but
making Java trendy.) Multiple inheritance is sort of given the nod in
interfaces, but you can't put any default code in there, every
inheriting class must implement all the interface – thank goodness
for delegates in WO, a good way around the limitation.
I prefer the code, practical view of inheritance, where you can build
up powerful classes by mixing in small abstractions. This gives you a
lot of utility code. Alas when you mention multiple inheritance most
people want to avoid it like the plague because they have seen it in C
++, the ultimate obfuscating language.
You are right though that inheritance expresses fixed state vs
changeable state, so that is a consideration in whether to use it
or not and to avoid inappropriate use.
What is "Head First Design Patterns"? Is it a book or paper?
Although I'm a bit dubious about "Patterns" because it was
something done for 20-30 years (algorithms and data structures)
before someone invented the term pattern as if it were something
new ;-( ;-). Maybe it's better that the all-to-frequently
patternless and unstructured kind of programming we too often see.
Head First Design Patterns is a book, one of a series by the Head
First ppl. I like it because it has funny cartoons :-).
Hmm, I must get it!
The Gang Of Four book is too dry, boring and not relevant to most
developers.
True, and I find there are a lot of people who treat it
reverentially, like some kind of holy text. Don't think I read much
more than the first chapter – nothing seemed particularly new, but I
don't want to seem unfair.
Personally, I don't like treating patterns as manna from heaven but
they have their uses. My feeling is that most developers use
patterns as a crutches. Now, sometimes one needs crutches but when
one spends all of one's energy limping about then something is wrong.
True, sometimes it is good to fall back on a known when you have
writers block, even if just for the exercise.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden