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: Tue, 14 Feb 2006 10:10:27 +1100
On 14/02/2006, at 2:32 AM, Arturo Perez wrote:
Ian Joyner wrote:
On 13/02/2006, at 4:09 PM, David Avendasora wrote:
I and a new OO programmer and I *really* appreciate everyone's
advice on OO design!
In this case, these three part types have some very specific
differences. It is not one part that changes. My application is
being built to manage the manufacturing in a bakery.
- Raw parts are sugar, flour, oil, etc. and are usually procured
from outside vendors.
- Intermediate parts are things like dough, toasted coconut and
such where an intermediate part has a Bill of Materials and
requires work within the manufacturing line to have produced.
- Finished parts things like like cookie, bar, etc. and are parts
made up of any number of Raw and/or Intermediate parts. Since
they are sold to customers they also have to have additional
attributes like UPC code, customer specific attributes.
Does this still sound like something that would work better as an
implementation of the Status Pattern, or should I stick with
Inheritance?
OK, that clarifies it and I think your inheritance design is
probably fine. Do these three kinds of things have features in
common? Data values (either attributes or typed functions) and
procedures (untyped (void) functions). What I do think you'll have
is for the intermediate and final parts, as 'has-a' relationship
'ingredients'. Make sure you don't mix up the is-a (inheritance)
with has-a (component-of) relationships. Otherwise inheritance is
fine.
Ian
Right, and I think, generally speaking and as discussed in Head
First Design Patterns, one should favor composition over
inheritance. Inheritance can lock you into design choices since no
common language allows modification of inheritance hierarchies at
runtime.
So, I would design Finished as a container for Ingredients and
Ingredients as containers for RawMaterials. Using Ian's language
Finished has-A Ingredient etc.
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).
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.
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