17 slide grasp

BY : Afaq Ahmed

1

1. Low Coupling2. Controller3. High Cohesion

2

Presentation Topics

CouplingCouplingCoupling is a measure of how

strongly one element is connected to other, has knowledge of, or relies upon other elements

3

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

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

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

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.

ControllerController

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

8

ControllerControllerAssign 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

ControllerControllerThe 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

ControllerControllerYou 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

Façade ControllerFaçade ControllerSuitable when there are not too

many system eventsThis could be an abstraction of

the overall physical unit, such as PhoneSwitch, CashRegister, etc.

12

Use Case ControllerUse Case ControllerThis 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

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

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

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

Design the controller so that it primarilly the fullfillment of each system operations and responsibilities of other objects.

CS6359 Fall 2011 John Cole 17

High CohesionHigh Cohesion

Cohesion is a measure of how strongly related and focused the responsibilities of an element are

18

Problems with Low Problems with Low CohesionCohesionA 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

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.

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