Jeffrey Eib, Sr. writes:
| A better question would be...How would you handle a true many-to-many
| relationship, such as the one between orders and products? Each order
| may have from one to many products, and each product may be in
| multiple orders.
|
| In the SQL world, this would be handled with the link tables you
| mentioned. Up until your answer, I'd have thought that a link
| class would also be needed for this kind of relationship.
To get at a list of Products for an Order you need to iterate the Lines of
the Order and return a list of the Products referenced; this is not an
implicit relationship and the only way I could think of fitting in would be
to add a GetProducts(Order) method on an OrderBook class, but that doesn't
really fit there either
I think you would have a reporting class to satisfy this side of the
relationship.
As to getting a list of Orders for a given Product, possibly an OrderHistory
class would have a GetOrders(Product) method.
Once again, I am inclined to say that this is a reporting requirement rather
than an implicit property of either side of the relationship.
<pontificating mode>
Maybe that is the key to what I have been trying to get at when I have
criticised inappropriate properties in classes...
Too often we seem to try to shoehorn properties into classes that are not
really part of a class's behaviour but are, instead, a reporting
requirement.
Think about it... How many Report classes appear in OO analysis? I would
venture to guess, not enough. My feelings are that we have bemoaned the lack
of a decent querying mechanism for OO systems and altered our design
strategy to provide reports as part of our business object classes.
I am not saying that BOs are simply data containers; they should have
validation, relationships, integrity enforcement and internal logic. It's
just that I feel that we have often forgotten that there are Actor Classes
in real world systems that are independent of any classes that may be
persistable; a Report is a prime example of a class that is all logic and no
persistence.
Maybe, because we too readily use terms like Order List rather than Order
Book, and Invoice List instead of Sales Ledger, that we tend to forget the
external actors that used to manage the pieces of paper before computers
were invented.
If I wanted a report on how many widgets we have sold to Bloggs and Co, then
I would have asked the Order Dept to produce that list; I wouldn't care how
they went about producing that list, as long as the resulting list was
complete and correct.
This is encapsulation, which is what OO is meant to be about. I have long
been a proponent of 'Manager' classes and it is discussions like this one
that reinforce my views that there are many classes that never get designed
because we assign inappropriate behaviour to, what would be in the real
world, inanimate objects.
Procedural programming would separate out data from processes, so you would
end up with global data and standalone procedures. OO was meant to bring
those two together into an encapsulated relationship. We don't have a
problem sorting out classes for data; those end up being 'one class for each
table'. What has caused us too many problems has been where to put the
logic; and our attitude seems to have been 'we have classes for data, let's
put all the logic in those'.
RDBMSs gave us stored procedures which were related to but separate from the
data they manipulated. Sure, some of that logic should have been put into
the tables (if that were possible) but there would still be many stored
procedures that did not belong in any one particular table.
Can a sheet of paper with 'Invoice' on the top really get up off the desk
and construct a report of all the items whose stock codes are held in it?
No, this used to take an Actor (human being). It is these Actor classes that
we need to consider as well as the 'things' that make up the system.
The best OO systems I have seen are those which emulate the real world
closely, without abstracting into a computerese paradigm caused by our lack
of familiarity with pre-IT working practices.
</pontificating mode>
Joanna
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
