TK2023 Object-Oriented Software Engineering

CHAPTER 13c

GRASP Patterns: Low Coupling

GRASP PATTERNS: LOW COUPLING

Problem

How to support low dependency, low change impact, and increased reuse?

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. These elements include classes, subsystems, systems and so on.

A class with high coupling relies on many other classes. Highly coupled classes suffer the following problems: Forced local changes because of changes in

related classes Harder to understand in isolation Harder to reuse because its use requires the

additional presence of its dependants.

Solution

Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives.

EXAMPLE OF APPLICATION

This example shows how two patterns may suggest different solutions.

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?

In the real-world domain,a Register “records” a Payment

According to the Creator pattern, Register is a candidate class for that responsibility.

DESIGN A

: Register p : Payment

: Sale

1. makePayment( )

1.1. Payment( )

1.2. addPayment(p)

{new}

Since the Payment object will eventually be linked to the Sale object, why not assign the responsibility to Sale?

DESIGN B

: Register

: Payment : Sale

1. makePayment( )

1.1. makePayment( )

1.1.1. Payment( )

{new}

Note that applying the Information Expert pattern also results in this design.

Which design supports low coupling?

DESIGN ARegister Payment

Sale

DESIGN B

Register Payment

Sale

Based only on the “coupling” factor, we prefer Design B as it maintains overall lower coupling.

We need to remember that when evaluating different designs, we should not just consider one factor (e.g. degree of coupling) in isolation. We need to consider other principles as well such as Information Expert and High Cohesion.

DISCUSSION Low Coupling is an evaluative principle that is

applied while evaluating design decisions. Common forms of coupling from TypeX to TypeY

include: TypeX has an attribute that refers to a TypeY object.

class Car {private Person owner;…

} A TypeX object calls on services of a TypeY object.

class Application {public void start() {

(new Game()).initialize();}

}

DISCUSSION TypeX has a method that references a TypeY object. For

example, as a parameter or local variable or the object returned from a message sent to a TypeY object.

class Game {

…

public void addPlayer(Person p) {

…

}

} TypeX is a direct or indirect subclass of TypeY.

class MyApplet extends JApplet {

…

}

DISCUSSION TypeY is an interface, and TypeX implements that

interface.class Game extends JApplet implements ActionListener {

…

}

Low coupling supports the design of classes that are more independent, which reduces the impact of change.

Inheritance is a strong form of coupling. Any decision to create an inheritance relationship between two classes should be considered carefully.

Is no coupling between classes a good thing? An object-oriented system is a system of

collaborating objects. Some moderate degree of coupling between classes is normal and necessary.

CONTRAINDICATIONS

High coupling to stable elements and to pervasive elements is seldom a problem. For example, a Java application can safely couple itself to the Java libraries because they are stable and widespread.

BENEFITS

Low Coupling has the following benefits. Lowly coupled classes are less affected by changes in other components simple to understand in isolation convenient to reuse