I have talked about a couple of GRASP Patterns that are presented in Applying UML and Patterns (3rd Edition) by Craig Larman (Amazon):
If you haven't purchased Applying UML and Patterns, buy it now, you won't be disappointed.
High Cohesion:
Problem: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?
Solution: Assign a responsibility so that cohesion remains high.
In terms of object design, cohesion is a measure of how strongly related and focused the responsibilities of an object are. An object with highly related responsibilites that does a little amount of work is considered highly cohesive.
Reading that might have you shaking your head a bit, so let's make a bit more sense of this in a way that is more clear. Let's use the Controller and Creator GRASP Patterns to describe high cohesion.
Controller Pattern and High Cohesion
As we discussed before the controller in an application is the first object beyond the UI layer that is responsible for receiving or handling a system operation message. We mentioned two types of controllers, a facade controller and a use case controller. Typically, the controllers do very little work themselves. They only pass responsibility to the domain objects that are responsible for all the work.
The use case controllers are used when there are a lot of messages coming from the UI and the messages are “unrelated” and it doesn't make sense for a single facade controller to manage all requests. For example, in the case of an e-commerce application, you may have the following messages:
- Get Categories
- Get Product in Category X
- Get Items in Shopping Cart
- Add Item to Shopping Cart
Now these are only 4 messages and a real e-commerce application will have many more messages. To keep the application cohesive (keep messages related and focused), I am going to assign the first 2 messages that are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages that are related to the shopper's cart to ShoppingCartHandler:
- ProductCatalogHandler
- Get Categories
- Get Product in Category X
- ShoppingCartHandler
- Get Items in Shopping Cart
- Add Item to Shopping Cart
This keeps the ProductCatalogHandler and ShoppingCartHandler highly cohesive. (If you were to go through all the messages in an e-commerce application, you may even break those use case controllers down to more specialized controllers.)
Creator Pattern and High Cohesion
Domain Driven Design has this concept of Repository, which is the vehicle by which an object is reconstituted from a persistent state (database, XML file, memory, etc.). Because the responsibility of populating an object from a persistent state is really a “distraction” from the role of the object in the domain, the repository is a separate object that handles the reconstitution (highly cohesive idea).
Sometimes the reconstitution is so involved that a purely fabricated class (factory class) is used within the repository to create the object from its last persistent state (highly cohesive idea). This factory class (creator pattern idea) is created based solely on the concept of high cohesion so that the monumental effort of reconstituing the object does not “distract” the repository from losing its focus.
public class ShoppingCartRepository {
public ShoppingCart FetchByID (string ID)
{
// IDataReader reader = select * from ShoppingCart where CartID = ID
// cart = ShoppingCartFactory.Create(reader)
// return cart
}
}
As shown above, because fetching the shopping cart from its persistent state is so involved, we off-loaded the task to a purely fabricated factory class, which will create the shopping cart object and populate its values from the DataReader object.
High Cohesion and Low Coupling pretty much go hand in hand, so I will be talking about Low Coupling in a later post. You can read all my posts from Applying UML and Patterns here.