|
|
Posted by Dikkie Dik on 12/30/05 15:50
As Peter Fox has pointed out, put the tasks where they belong. I have
the feeling that you are playing the role of a conductor who has to
learn each musician how to play as well.
Use clear names for objects. If your model represents companies,
departments, employees, tasks and subtasks, just call your classes those
descriptive names.
If you have to compare different instances that might have the same
state (value of internal variables), you could give the class an
IsEqualTo method to do the comparison. Even better, a lazy collection
can be used to ensure that equal objects are actually the same instance.
You could then just use the reference equality operator (===).
Oh, and just delegate. Conductors trust their musicians in their skills.
At least in a concert. In software, use unit tests as a "musician's exam".
For instance, if each object in your structure has some value and you
want to calculate the total of it, don't traverse the structure
yourself. Trust your directly known objects and ask them to calculate
THEIR total and add these.
It is not always bad to repeat methods:
Employee->Name()
May be defined as
Employee->EmployeeRecordWrapper->Name()
The short verion is clearer AND independent of the underlying structure,
giving you more architectural flexibility.
If you fancy some technical stuff, google for the "Law of Demeter". It
is about what objects should know each other and what objects should not.
Best regards
Navigation:
[Reply to this message]
|