Hi Bill,
I'm in a silly mood so you get a silly example. ;-)
A man is buying Chinese food for himself, his wife and his daughter. Each
person wants it from a different shop.
He walks into the first and orders. The server disappears and reappears
later with the food in industry standard boxes. Our man does the same in the
other two shops and goes home.
In the first shop, the chef gets fresh raw ingredients, prepares them and
cooks them up in freshly made sauces. In the second shop, pre-prepared
ingredients are put together with sauces bought in from a bulk supplier. In
the third shop, complete meals (actually prepared by the first shop) are taken
out of the freezer and reheated.
That's encapsulation. Same ordering, same/similar menu, same packaging.
Totally different production. That's what encapsulation is hiding - the method
by which an object serves up its content.
The man goes home with his three meals and ponders on how he can walk into
each shop, speak to a Chinese person in English (though they write the order
in Chinese), pay with the same currency and walk out with standard boxes and
cups containing very familiar food.
That's an interface (and polymorphism in action). He enacts the same
procedure for the man at each shop as they all have inherent Chinese-Shopness
(though in one he stood in bright light at a counter where a TV was blaring
out with some sport, while in another he sat in subdued luxury, next to a tank
of bright tropical fish with soft Chinese music playing).
Actually, the third shop was a laundry, but by asking for Mr Wong (not his
wife, who ran the laundry), our man was able to get his food prepared. That's
because although Mr Wong had inherited his father's laundry, he had always
wanted a restaurant (his wife wouldn't let him go that far) and so he
implemented a Chinese-take-away interface.
On getting home, our man opens the packaging and puts some items into the
fridge, some into the oven to warm while others go straight onto the table.
Some of the packaging goes in the rubbish bin, some into a recycling
container. He knows exactly what to do with the food and eventually creates a
lovely display for the family to sit at and eat.
Our man has to know what to do with food and how to prepare it. His
daughter is only 6 so she doesn't really have a clue (nor does she care that
much - what's a Dad for, after all?). He's proud of his expertise - that's
being a bachelor he says to himself.. Sometimes, though, he wishes that he
knew how to cook it as well.
=================================
I've no idea what you made of that. - just a bit of fun.
)
=================================
Getting to your situation now.
The Total OOP method would have an object for everything, of course.
Hotel, Guest, Room, DryCleaner, DryCleaningItem, DryCleaningItemList, Invoice,
DryCleaningInvoice, InvoiceStore (Excel workbook), Period, BillingPeriod, etc,
etc.
The DryCleaningInvoice would contain its Date, InvoiceNumber plus
references to its InvoiceStore, Hotel, Guest and DryCleaningItemList.
The DryCleaningInvoice would present an interface much as you described in
your post - It can give you the individual properties and it can provide the
DryCleaningItemList. The DCIList would be able to serve individual DCItems.
These would be able to give you their individual properties - and each
property would, in turn, be able to provide different renditions of itself for
different purposes.
Most often, a single rendering function, ToString, is sufficient, but some
objects provide a ToString with formatting. Other objects need more and
provide functions - MeAsThis and MeAsThat. A user of such an object needs to
know which property it wants, which form it wants it an and where to put it
once it's got it. How the object produces each of these forms is none of its
concern, however.
The parallel with our Chinese Food story now breaks down a bit. Our man
had to know what to do with his food - he even had to do some more work on it,
(such as cutting the fat off the pork for his daughter). In an OOP scenario,
the food would have unpacked itself and heated/cooled/defatted/etc as
required. It would still be up to the man to bring it to the table, however.
Your task is the storage of these Invoices. You are in the position of the
Chinese shops in that you know about the underlying storage and maniupulation
of the data, ie Excel workbooks. It'll be your task (as an Invoice) to get the
data from the workbook and parcel it up to go out to the users in your
standard boxes. These boxes are the other objects - DCInvoice, DCItemList,
DCItem. These may be designed totally with the convenience of the end user in
mind leaving you a lot of work preparing the data for that interface. Or you
could design it with your ease in mind and leave more work for the end user.
The more work you do for them, though, the more they will thank you (no they
won't they'll take you for granted!!) as the task of using your facilities
will be easier. What you certainly <won't> do is give any hint of Excellness.
If your users need to do some special processing, then, if it is likely to
be used elsewhere or frequently (ie it's not so special), or is tricky (ie
it's really special), or for other reasons, you would move that logic into
your objects - this way you can guarantee the work. It depends on how you want
to divide the labour.
Well, that's enough of that. I've enjoyed this one - I hope you have too,
and found it of some use.
Your fortune cookie says: 'A man with a simple face may hide deep
thoughts'.
Regards,
Fergus
