Cohesion and Coupling Concepts In Object Oriented Design
Object-oriented design and programming has fundamental concepts such as Polymorphism, Inheritance and Encapsulation that collaborate to achieve modular, easy to understand, reuse, maintain and evolve software. These concepts are built in any OO programming language, but there are other important concepts to a good design. Some of them are even older than Object Oriented Design itself, and still apply to it.
Cohesion and Coupling, and the desired High Cohesion and Low Coupling, are some of these concepts. They were created by Larry LeRoy Constantine in the 70's (W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 1974) and were included in GRASP (General Responsibility Assignment Software Patterns) as design patterns applied to Object Oriented Design by Craig Larman (Larman, Craig. "Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development", New Jersey: Prentice Hall, 2004). I couldn't find the first reference of these concepts applied to OO design, but should point that the famous "Design Patterns: Elements of Reusable Object Oriented Software" (Gamma, et al; known as the GOF book) uses these concepts and even defines them on the glossary.
Cohesion is how much a class (or object or module; a software component) is focused in a single purpose. High Cohesion tend to be always preferable because it increases testability (unit tests), understanding, reusefulness, extensibility and maintainability of software.
Coupling (or Dependency) is how much a class (or object or module; a software component) relies to another directly. Low Coupling is having classes depend directly on each other the minimum possible, so maintenance, reuse and replacing of them are easier to achieve. Low Coupling tend to be always preferable than High (or Tight) Coupling in designing software.
High Cohesion and Low Coupling are generally used together to analyse and design software, and can be considered metrics of quality of a software.
Software Design Patterns
Design Patterns are tricky to define. They were created (or discovered) inspired by a civil architect called Christopher Alexander, which stated "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander et al, "A Pattern Language". Oxford, 1977). Some definitions on computing context are:
- "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context" (Gamma et al, "Design Patterns: Elements of Reusable Object Oriented Software", 1995, page 3);
- "The focus of the pattern is a particular solution, one that's both common and effective in dealing with one or more recurring problems." (Fowler, Martin, "Patterns of Enterprise Application Architecture" Addison-Wesley, 2003);
- "general reusable solution to a commonly occurring problem within a given context" ("Software design pattern", Wikipedia at http://en.wikipedia.org/wiki/Design_pattern_(computer_science));
- "best practices given a name, with a description of what the pattern does, where to apply it, the problems it addresses, and so forth" ("Introduction to Spring" at http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/overview.html);
There are several design patterns "discovered" (as Martin Fowler says) and documented in books. They can be general or applied to a specific kind of software (such as Enterprise Applications), but there is no doubt they're useful and important to the Software Design field for study and practice.
Decoupling Object Instantiation
The creation (or instantiation) of objects is where lies the dependency between classes. It is where the coupling of a software is stated, and classifies a software as having High or Low Coupling. For that, some design patterns were discovered and documented to help developers. My plan is to cite and explain some of them together on next posts, as they can be very useful. I hope you enjoy it. :)
Decoupling Object Instantiation Part 2 - GOF Creational Patterns