Re: Design question
John wrote:
....
Then I started thinking about things like, "what's the difference
between a domestic dog and a wolf". Well for one thing, wolves hunt in
packs. Domestic dogs do not. So, in my very limited thinking, the Dog
class may have an instance variable (what dogs know about) called
huntInPacks which is a boolean. And each subclass of Dog, when it
constructs a Dog, will pass in a true or false depending on what type of
dog it is. But all dogs belong to the Canine family so I could have an
instance variable called Family which is attached to the dog class and
is final String family="canine" or something like that.
....
Using class hierarchy to model real-world hierarchy appears attractive,
but often breaks down when you get to the details. Many real-world
structures are not, in fact, simple fixed hierarchies.
For example, it is tempting to think of "employee", "customer", and
"supplier" as subclasses of "person", and then treat "manager" and
"non-manager" as subclasses of "employee".
In practice, after a few promotions, hirings, firings , purchases of
goods from a former employee, etc. this breaks down. A "person" that has
one or more "role" objects is much more robust. Some of those "role"
objects will also work as attributes of "business". A supplier may be a
person or a business. A business cannot be an employee.
In the same way, wolves, foxhounds, feral dogs, lionesses, and
killer whales typically hunt in packs. Other animals, far more closely
related to one of these than they all are to each other, do not hunt in
packs. Indeed, zoo and pet animals typically don't hunt in packs,
regardless of species.
However, I think there is a deeper problem with your current effort. The
best design and development strategies I know are very closely focused
on the purpose of the design. Do you have an application that you think
needs this design?
Patricia