Object differentiation

Thanks again to Sean CorField for his great explanation on this topic. I will try to explain for my own internalization. Objects are the heart of a OO system, the way we see and understand their similarities and differences informs how we build them.

There are two types of objects that we model in our CFCs.

1 - Value objects (beans)

Things, nouns (person, place or thing) that make up our domain.

Value objects or beans are the traditional objects that represent things in your domain. For example, one of our applications is called DataMentor, these things comprise its domain,

• assessments
• resources
  
• users
  
• standards
  
• institutions
  
• scores
  
• examples
  

Each of these value objects has getter and setter attributes that allow the outside world to see or update them. Each of the value objects has a constructor method that initializes the object and sends back a reference to it. The constructor methods usually also sets the values of the attributes referenced by the getter, setter methods.

Typically, each value object has a service object that is referenced by the application who requests to communicate with it. Remember that value objects are not very social, they only like to be spoken too by their own service. The service is the more social of the two, it likes to talk to its own value bean but also to other services too.

Value objects have 'state' which means they change within a session (the time a person spends using our application). In our application, we use state assessments. If a teacher is looking at different assessments, each time one is chosen, its 'state' should change, the details of the assessment would come from the database and the getter methods for each of the attributes would be called, updating the state of the object.

In our application, a user chooses an institution, a request is made to the database to get the details of the institution. Then the institution service is called to update the state of the institution value object (bean). The service calls the DAO which calls the setter methods for the institution value bean. This process of getting and updating institution details via services, DAO and value beans is repeated whenever a new institution is selected.

2 - Service or Infrastructure

These objects are singletons and have no state. They exist to serve the value objects. They are created once and do not change during the user session, used per-application. They may cache data, because once its state is created, it does not change, requests to refresh itself do not occur.
These objects live to serve the value objects in step 1. If a value object needs to be written to a database or refreshed from a database, the value object speaks to the service layer which speaks to the data access layer which speaks to the database.

Service layer objects are social, they like to speak to other objects, like listeners, controllers, data access models and other services.

There are inherent dependencies between the value and service objects. A value object needs a service object, a DAO needs a service object and the DAO object may need a data source object. These dependencies are difficult to manage, a object management framework like coldSpring can help. A common problem is tight coupling between the objects which means knowledge of each other is required to operate.

Often we use design patterns like Factory Pattern to solve common problems like this.

The Factory Pattern

A factory makes things, like widgets, wadgets and objects. The factory knows about dependencies and manages them. The objects in your application DO NOT need to know about each other. The factory creates the objects and the dependency objects. This pattern reduces coupling between dependent objects.

The question arises, who's job is it to know about the other. For example, who's job is it to ensure that when a service calls a DAO, that the DAO object exist? Typically, you see code in the constructor of the service that creates the object to the dependent DAO. This builds coupling between the two and forces the service to maintain application state, which is a best practice no no. Since the service object has a natural relationship with its DAO or Gateway, a better example might be the service needing information from another object, not its own. How does the service know if that object exists? Whose job is it to know this? Let the factory pattern implemented in a framework like ColdSpring manage the dependency and object creation.