Reinforce the principles of cohesion and coupling as they apply to class modeling.
Cohesion and Coupling Revisited
Cohesion and coupling are measures of quality for your model. As such, they should be applied to every activity of the modeling process.
Like encapsulation, cohesion and coupling may and should be applied to every level your model, not just to individual class design.
Key to achieving High Cohesion
The key to achieving high cohesion and low coupling is defining purpose. The best way I have found to understand this concept is to think in terms of human interaction. People and organizations work best when they have a single, well-defined purpose.
When the purpose is poorly defined, people have a hard time setting priorities, developing a plan of action, and coordinating unrelated tasks. Cohesion Business Example
Systems, applications, components, and objects react in the same way. Actually, it is the developers who react in the same way. Development becomes increasingly complex as you attempt to put more and more functionality into the same component.
More and more code is required to track object state, juggle priorities, and manage the execution of loosely related or unrelated activities.
Refactoring for higher cohesion
Refactoring for higher cohesion and looser coupling is usually a matter reassigning responsibilities and the associated functionality.
The diagrams below will show you two examples of refactoring.
In the first example, the initial job description for a Software Developer is refactored so that the skill and tool sets in the initial definition are distributed into three distinct job classifications.
In the second example, the definitions for a security user interface and a security client are refactored so that their responsibilities are divided in such a way so as to allow the user interface to change without disturbing or even touching the logic behind it.
Initial Job Description Example 1: View the diagram below to examine the initial job description for a Software Developer.
Refactoring Revisited
In this definition the distinct skill and tool sets are distributed into three distinct classifications.
You initial reaction might be would not that be nice.
But most organizations do not have the resources to use a different person for each job description.
The point is not whether each job is assigned to a different person.
The point is that the jobs may be assigned separately or together without losing sight of the distinct responsibilities and the corresponding skills and tools. Flexibility and focus have been improved.
The result is a set of responsibilities that are easier to measure and manage
Example 2: View the diagram below to read about a refactored version of the job description for a Software Developer.
In this definition the user interface contains the screen elements needed to obtain the user input and the logic to prevent unlimited attempts.
The client application knows what database to access and how to lookup the user. Changing the security database to another database engine would require significant changes to the client application.
View the diagram below to see a refactored definition for 1) a Security User Interface and 2) Security Client Application
You can see from the examples that refactoring based on cohesion and coupling typically results in more objects that are also smaller and simpler, and consequently far more reusable.
This definition divides the responsibilities into a) user data entry and b) user access, c) the security system, and d) the database behind the security system. This approach allows the user interface to change without disturbing or even touching the logic behind it. The interface is completely ignorant of how it is being used. It merely provided fields to receive and display information. In fact the same interface could be used at many different levels through the system, e.g. application security, system security, and function level security.
The client application knows nothing about presentation or the actual validation. Its sole responsibility is to obtain valid input for the security system Validate User interface.
The security system knows how to interpret security information about a user, but not how its knowledge will be presented to the user. It does not even know where the security data is physically stored.
The security system database knows the current database and how to format the validation request in to the SQL or other language needed to get an answer from the current database. This separation of the database from the security system using an interface allows for the replacement or upgrade of the database without changes to the applications that use it as long as the interfaces remain the same.
