cf.Objective() Hal Helms: Object Oriented Modeling

This is a heady session.

Hal says a big mistake OO developers have is thinking about "attributes" of objects instead of their "responsibilities".

He says be careful of collections of unrelated functions "masquerading" as Objects.

Domain Models

Domain model is built of ADTs (Abstract Data Types) which relate to each other in a way that "models" the behavior of the objects in the real world. (Although, it may not model exactly the real world, because there are differences in the assumptions between the two).

How do you model the Domain Objects?

UML (Unified Modeling Language)

When modeling, resist adding all properties initially. Really focus on Classes and Methods. Use cases will help keep the focus on behavior.

UML portion of talk it too much for me to detail while listening. (Sorry)

Next is "Seperation of Concerns"

Classes should be Cohesive: A class should have a tight focus on it's responsibilities.

And they should exibit "Low coupling": Classes should work with each other through a stable interface (API). They should only know about this stable API and not the internal implementation.

An Exercise In OO Modeling

Hal walked us through the beginning of modeling a company and it's employees. Again, this is too detailed to document. But, basically, he started with HourlyEmployee and SalarieEmployee inheriting from Employee. Then he brought in employees that could be commissioned and how the inheritance tree was getting messy. Plus, you would have to change an employees fundamental type to change how he is payed.

So, this could be solved better by composition. Now an Employee would have a Wages object. And his Wages object could be switched without disrupting his relation to any other objects.

My Summary

I can tell that this is a topic that I will be improving on as long as I work in this field. And I may hit landmarks along the way, but, there will be no end of the road.