TK2023 Object-Oriented Software Engineering CHAPTER 13d GRASP Patterns: High Cohesion

GRASP PATTERNS: HIGH COHESION Problem How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?

In object design, cohesion is a measure of how strongly related and focused the responsibilities of an element are. An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion. The element can be a class, subsystem, and so on.

A class with low cohesion does many unrelated things or does too much work. Classes with low cohesion are undesirable because they are  hard to understand  hard to reuse  hard to maintain  delicate; constantly affected by change Low cohesion classes usually represent a very “large grain” of abstraction or have been assigned responsibilities that should have been delegated to other objects.

Solution Assign a responsibility so that cohesion remains high. Use this principle to evaluate alternatives.

EXAMPLE OF APPLICATION In the POS application, when the Cashier enters a payment, a Payment object needs to be created and associated with the current Sale. Who should be responsible for creating a Payment instance and associate it with Sale ?

The Creator pattern suggests assigning that responsibility to Register. : Register p : Payment : Sale 1. makePayment( ) 1.1. Payment( ) 1.2. addPayment(p) {new} DESIGN 1

If we continue to make the Register class responsible for doing some or most of the work related to more and more system operations, it will become increasingly burdened with tasks and become incohesive.

The following design delegates the responsibility for creating the Payment instance to Sale. : Register : Payment : Sale 1. makePayment( ) 1.1. makePayment( ) Payment( ) {new} DESIGN 2

In Design 1, the Register class is less cohesive. Design 2 supports not only high cohesion but also low coupling. Thus, it is more desirable than Design 1.

DISCUSSION Like Low Coupling, High Cohesion is an evaluative principle that is applied while evaluating design decisions. As a rule of thumb, a class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work. It collaborates with other objects to share the effort if the task is large.

Real-world analogy: A person who takes on too many unrelated responsibilities (ones that should be delegated to others) becomes an ineffective person.

CONTRAINDICATIONS There are certain cases where lower cohesion is accepted. Examples:  Grouping of responsibilities or code into one class or component to simplify maintenance by one person.  Creating fewer and larger, less cohesive server objects to reduce remote calls and improve performance.

BENEFITS Benefits of High Cohesion:  Increases clarity and ease of comprehension  Simplifies maintenance and enhancements  Often supports low coupling  Increases reuse of fine-grained, highly related functionality because a cohesive class can be used for a very specific purpose.