Problem: How to support dependency, low change impact
and increased reuse?
Solution: Assign responsibility so that coupling remain
low. Use the principle to evaluate the alternative
Coupling is a measure how strongly one element is
connected to, has knowledge of other element. An
element with low (or weak) coupling is not dependent
on too many other elements. These elements include
classes, systems, subsystems and so on. High coupling
elements have problems:
Forced local changes because of changes in related
Harder to understand in isolation
Harder to reuse because its use requires the additional
presence of the classes on which it is dependent.
In OOP languages like C#, C++ or Java, common forms of
coupling from Object X to Y includes the followings:
X has attributes (data members or instance variables) that
refers to a Y instance or Y itself.
A X object calls on services of a type Y.
X has a method that references an instances of Y. These
typically include a parameter or local variable of Y or the
object returned from a message being an instance of Y.
X is direct or indirect subclass of Y
Y is an interface and X implements that interface
Problem: What first object beyond the User Interface layer
receives and coordinates (Controls) a system operation?
System Operations were first explored during the analysis
of SSD. These are the major input events upon our system.
For example, when a cashier using POS terminal presses the
End Sale button, he is generating a system event indicating
the Sale has ended. Similarly when writer using a word
processor presses the Spell Check button, he is generating a
system event indicating to perform a spell check.
Controller is the first object beyond the UI layer that is
responsible for receiving and handling system operation
Problem: How to keep objects focused,
understandable, and manageable, and as a side effect
support low coupling?
Solution: Assign responsibility so that cohesion remain
high. Use the principle to evaluate the alternative
Cohesion or Coherence is the strength of
dependencies within a subsystem.
Cohesion is a measure of how related the functions
performed by a software component are.
Cohesion is the "glue" that holds a module together.
Cohesion is about making sure each component does
one thing and does it well. (Cohesion Test)
In a highly cohesive subsystem:
subsystem contains related objects
all elements are directed toward and essential for
performing the same task.
A class with low cohesion does many unrelated and
does to many things