Grasp Patterns,low coupling controller high cohession

1. BY :
Afaq Ahmed
1

2. 1. Low Coupling
2. Controller
3. High Cohesion
2
Presentation Topics

3. CouplingCoupling
Coupling is a measure of how strongly one
element is connected to other, has
knowledge of, or relies upon other elements
3

4. Low Coupling:Low Coupling:
An element with Low Coupling is not
dependent upon too many other
elements.These Elements include
classes,systems,subsystems and so on.
High Coupling:
A class with high Coupling relies on many
other classes.
4

5. Problems with high coupling:
◦ Forced local changes because of changes in
related classes
◦ Harder to understand in isolation
◦ Harder to reuse because it requires other
classes
Solution:
Assign responsibility so coupling remains low
5

6. NextGen exampleNextGen example
 If we need to create a Payment instance and associate it
with Sale, who should do it? Since Register records a
payment, the Creator pattern suggests register as a
candidate for creating the payment.
 Register instance then pass message to sale with
parameter payment.
6

7. 7
Alternative solutionAlternative solution
In both cases Sales must be coupled eventually with
payment. In Design 1 Register creates the payment,
adds coupling of register with the payment. In design
2 sales creates the payment which does not increase
the coupling. Design 2 is preferable because the
coupling is low in design 2 than design 1.

8. ControllerController
A controller is the first object beyond
the user interface that is responsible for
receiving or handling a system operation
message.
8

9. ControllerController
Assign responsibility to a class with one
of the following:
◦ Represents the overall “system,” a “root
object,” a device the software is running
within, or a major subsystem (façade
controller)
◦ Represents a use case scenario within which
the system event occurs, often called
<UseCaseName>Handler
9

10. ControllerController
The UI layer gets data and an “Enter Item”
message (or some other message, in the case
of the assignment)
CS6359 Fall 2011 John Cole 10

11. ControllerController
You may want to use the same controller
class for all system events of one use case
so it can maintain state.
Possible problem of over-assignment of
responsibility
It should delegate the work to other
objects, not do it
11

12. Façade ControllerFaçade Controller
Suitable when there are not too many
system events
This could be an abstraction of the
overall physical unit, such as
PhoneSwitch, CashRegister, etc.
12

13. Use Case ControllerUse Case Controller
This Kind of controller is not a domain
object. It is an artificial construct to
support the system.For example if our
next generation application contains
usecases Process sales and Payment then
there may be a processalehandling class.
When using a façade controller leads to
low cohesion and high coupling
When the façade controller gets blotted
then usecase controller is a good choice
13

14. Bloated ControllerBloated Controller
Poorly designed, a controller class which
have low cohesion, unfocused and
handling to many areas of responsibility it
is called blotted controller.
14

15. Issues :Issues :
If there is a single controller class
receiving all system events in the system.
This sometimes happen if a façade
controller is chosen.
A controller it self performs many tasks
necessary to fulfill the system events. This
usually involves the violation of
information expert and High cohesion.
CS6359 Fall 2011 John Cole 15

16. Solutions:Solutions:
Add more controllers to a system does
not need to have only one.Consider an
application with many events such as
airline reservation system which might
have these controllers
16

17. Design the controller so that it primarilly
the fullfillment of each system operations
and responsibilities of other objects.
CS6359 Fall 2011 John Cole 17

18. High CohesionHigh Cohesion
Cohesion is a measure of how strongly
related and focused the responsibilities of
an element are
18

19. Problems with Low CohesionProblems with Low Cohesion
A class with low cohesion does many
unrelated things.
It is hard to understand,.
hard to reuse.
hard to maintain.
Constantly affected by Change
19

20. 20
The responsibility of making a payment is assigned to the Register.
But if we making class register to do more work and other system
Operations it will become burdened.
Suppose 50 operations received to the register and it become blotted
Object.

21. In this design register is just initializing
one operation makepayment and passing
messege to the sale class for further
operations.
This design is suitable because it have
high cohesion and low coupling.
21

22. 22