[squeak-dev] conceptual help please

Hans-Martin Mosner hmm at heeg.de
Wed Sep 12 06:17:44 UTC 2012


Am 12.09.2012 03:02, schrieb Joseph J Alotta:
> I am a newcomer to ST development and this is my first real-world project. 
>
> I work for an investment advisor, so the brokerage firm lets us download a set of files each day.
>
> The files contain data about clients and accounts.
>
>
> I think it would be like this:
>
> A (1) Family has (2) Clients who have (3) Accounts each having (4) Folios which contain (5) Securities.
>
> Should I implement this directly in a class hierarchy, even though each class is very different from the parent class?
Chris already noted that these don't seem to imply a class hierarchy, and I'd fully agree with that.
Class hierarchies are applicable when you have is-kind-of relationships and the instances of the different classes can
be used mostly interchangeably but have sufficiently different behavior that does not stem from just attribute differences.
For example, it would be nonsense to define RedCar as a sublass or Car, as the color is just an attribute.
A good example of a valid class hierarchy is the Number hierarchy, where Smalltalk has different kinds of numbers which
can all be used in arithmetic calculations but have different domains and representations. Other examples within Squeak
are Collection and Morph, each having a broad and deep class hierarchy.

One case where class hierarchies make sense in an investment context is in the modeling of the different financial products.
They can be used interchangeably as parts of a customer's folio, but they have very diverse behavior. Think of shares,
options, mutual funds etc.

If you design a model for your data, don't consider only hierarchy (is-kind-of) and composition (has) relationships.
Often there are cases where you think you got an is-kind-of relation where in fact a has-role relation would be better.
For example, if you have a class Person and make the class Customer a subclass of Person because each customer is a
person, you're confusing inheritance with roles. Better would be to have Person (with subclasses NaturalPerson,
Corporation, ...) and PersonRole with subclasses Customer, Employee, Vendor, ...
Then a person could be both a customer and an employee (unless your business forbids selling to employees, of course :-) .)

Cheers,
Hans-Martin


More information about the Squeak-dev mailing list