Re: Listing objects

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
.

Quantcast