The document discusses low coupling and high cohesion in object-oriented design. It defines coupling as the degree to which elements of a system are connected to each other, and explains that low coupling is preferable to avoid issues with changes. It then defines different types of coupling between objects, such as data coupling and method calls. The document also defines cohesion as how related the functions of a component are, and that high cohesion is preferable to keep components focused and understandable. It recommends assigning responsibilities to achieve both low coupling and high cohesion.

1. By:
Altaf Hussain
SSO, KRL

23. Low Coupling
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

24. Low Coupling
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
classes
Harder to understand in isolation
Harder to reuse because its use requires the additional
presence of the classes on which it is dependent.

25. Low Coupling

26. Low Coupling
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

27. Controller
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
message.

28. Controller

29. Controller

30. Controller

31. Controller

32. High Cohesion
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

33. Cohesion ?
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

34. High Cohesion

35. Supporting Discussion on High Cohesion