CFObjective: Day 1 - Object Oriented Modeling

Hal Helms

Ontology - ask things like "what does it mean to be a customer?"  Beware of an unrelated collection of functions masquerading as a component.
Big mistake is thinking about "attributes" of an object rather than it's "responsibility"!  What responsibilities does a customer have?  What do they need to do that a normal person doesn't do?

Different tiers for different purposes: Bullseye

• Data in the middle, then Domain Model, Services, App controllers.
• Domain model should get the most thought.  "In our view, this is how we define the world."  Business logic.  What are the objects within your domain?  This is excellent for Phoenix.  Your domain model should be able to stretch across applications.  A "user" always acts like a user across apps.  A "goal" is always a goal.
• Services simply provide services to your Objects.  A user needs a login service.
  

Problems - Anemic domain model

• If behavior is inherited in the domain's understanding of itself, a domain model component is usually a good choice.
• If behavior is specific to a particular app, a service layer component is usually a good choice.

Domain Model

• An abstraction of the domain (business logic) in which the domain is accurately reflected through it's objects.
• Abstract Data Types - idealizes real world components
• Interesting example - Bob borrows money from Linda
• "How much does Bob owe Linda?" - Where would you place this function, in Bob or Linda?
• Everyone said Linda, but Bob is the real answer.
• In the real world, Linda is the choice because it's safe, but in OO, there is no danger and it makes far more sense to place it in Bob.
• Nobody knows better how much money Bob owes... than Bob.
• What if you needed a function where Bob wants to pay back a certain amount of his debt?  He needs the total owed value.  Why should he have to get that from Linda?
• Linda would contain functions to loop over borrowers and ask each... how much do you owe me?

UML - Class diagrams

• Class name
• Properties/Attributes
• Responsibilities/Methods/Behaviors
• Avoid going crazy with adding properties as you probably don't need them.

Classes should work together through a stable API rather than through detailed knowledge of the internals of that class. (low coupling)

Another interesting example - creating classes for a company - Employees where some are hourly and some are salaried.
Everyone would be tempted to use inheritance:

• Employee object
• HourlyEmployee extends from Employee
• SalaryEmployee extends from Employee

This is wrong.  What happens if an Employee changes from Salary to Commission?  What if you hire Temps?  etc.
Much better to use a design pattern called "Strategy".  Payroll or Compensation becomes it's own object.
This another example of "Composition over Inheritance".