Scribd
Upload
46 views8 pages

Scan 0001

OOMD Chapter 4 scan number 1

Uploaded by

NALE SVPMEngg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
46 views8 pages

Scan 0001

OOMD Chapter 4 scan number 1

Uploaded by

NALE SVPMEngg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
Artem MLC CAECUM ELLE General Responsibility Assignment Software Pattern (GRASP) ‘+ Definition : General Responsibility Assignment Software Patterns (or Principles) or GRASP consists of guideline required for designing an object. «The different patterns and principles used in GRASP are : Creator, Information Expert, Controller, Low Coupling, High Cohesion and so on. + Responsibility. Driven Design (RDD) : The design of objects for a large system is done in terms of responsibilities, roles and collaborations. This approach is called Responsibility-Driven-Design (RD). + Responsibilities are the aggregation of objects in terms of its behavior. In UML, while designing the interaction diagram the responsibilities can be assigned to the object. In UML terminology these responsibilities are called the methods. «Definition of pattern - The pattern can be defined as a named and well-known problem solution pair which can be applied in new context, and guides on how to apply it in current situations and discussion of its trade-offs, implementations, variations and 50 on. + Various patterns suggested by GRASP are - Creator, Information Expert, Low Coupling, Controller, High Cohesion and so on. Let us discuss them in detail Creator Problem Who should create an instance of a new class ? Sol. :. Consider assigning class B the responsibility to create an instance of class A if one of the following is true - 1. Class B contains A. 2, Class B aggregates A. 3. Class B records A. 4, Class B closely uses A. Thus B is a creator of instances of class A. Example In library management system, when a book is added in the library the catalog is updated by its title. Then the creator pattern can be applied as follows - +#Create(Bcok) Fig. 5.21 Creator pattern Another example of creator pattern is - When we want to add the records in the database then the table creates a new instance for the Datarow. Using this instance the record can be added in the table at the next row. Discussion : Creation of objects is a common task in object oriented system and this task is guided by the creator pattern. The basic goal of Creator pattern is to find a creator that needs to be connected to the created object in any event. Various common relationships between the ciasses of the class diagram are aggregates, contains and records. In other words connect an object to its creator when - + Aggregator aggregates part ‘Container contains content Recorder records ‘Initializing data passed to it during creation. Composition is an excellent candidate considered by the Creator pattem for creating object. (Contraindications : Sometimes creation of object involves si complexity. In such a situation it is preferred to create object using Concrete Factory or Abstract Factory. Benefits : Creator Pattern supports low coupling. Due low coupling there are less dependencies between the objects and the objects become more reusable. Related Patterns or Principles : + Low coupling. + Abstract Factory. ‘ Aggregation and composition. | Review Questions: | @1. Explain the need for eretor pattern, Q2 Describe the concept of creator. | [53] information Expert Problem What is the basic principle responsibilities to objects ? Sol.: Assign a responsibility to the class that has the information needéd to respond to it. Such a class is known as Information Expert. of assigning Example In the ATM system application, the some class ‘might need to know the account balance. While finding the information expert make use of the principle - ” Start assigning the responsibilities by clearly stating the responsibility”. Using this principle following question can be asked - ” Who is responsible for knowing the balance amount” By information expert we should look for the class of the objects that need balance amount. Now in order to know the balance amount we need to know - 1) The account number of the customer whose balance amount must be known. 2) The transactions made by the same customer till date. Obviously this information might be available to the class Bank. For finding out the information expert in this context, the interaction diagram is designed. A partial interaction diagram and the class diagram is as shown below - |?GetBatancelnton For the information that we need to determine the account balance? Account Number and Transaction made so far. Therefore by information expert the Bank class will return the Account number of the desired customer because it managed the Account class. 1 Gatbalancone p=] Fig, 6.3.3 Information expert pattern Discussion : Information expert is used for assigning the responsibilities. But for the fulfillment of the responsibilities the 2ccess to the information which is spread across the clas.s is needed. This implies that the partial information experts will collaborate to perform some task. For example for knowing the balance amount the classes like Customer, Bank and Account work in collaboration. Whenever information is spread across different objects they will need to interact via messages to share the work. Contraindications : Information expert may contradict the low coupling and high cohesion pioperties in the dgsign. The basic architectural principle of keeping the core logic/systems separate may get violated due to information expert. Benefits : 1) It supports the information encapsulation because objects posses their own information in order to perform the responsibilities, 2) It supports low coupling because of which system becomes more maintainable. 3) The behaviour in distributed across the classes. that need the related information. This helps in designing of the lightweight class definition. 4) High cohesion is supported. Related Patterns or Principles : ‘* Low coupling ‘* High cohesion | Review Question | | 1 Explain the information expert pattern with | some illustrative example. | 5.4 | Low Coupling Coupling is a measure of how strongly one object is connected to, knowledge of or dependant upon the other object. An element with low coupling is not dependant upon too many objects. The classes with high coupling rely upon many classes and it leads to various problems Problems + How to reduce the impact of changes ? + How to understand the iolated object ? ‘+ How to reuse the object which is dependant upon another object’? Sol. : Assign the responsibilities to the objects in such a way that the coupling between the objects remain low. Example Consider the clases in the ATM System - Fig. 8.4.4 Assume that the customer wants to withdraw money. The Creator patiern suggest that there should be the relationship between Customer, ATMSystem and Transaction. If these classes are related to each other by the relationship as shown in Fig. 542 (a) then it indicates that the Customer must have the knowledge of both the ATMSystem class and the Transaction class. ‘This leads to poor design. But as shown in Fig. 5.4.2 (b) if the Customer is related to the ATMSystem class and the ATMSystem class performs the desired transaction then it leads to low coupling. TL Ee: = ERT] 2: Whew 0) —— (a) Customer creates transaction 1 Enter PINTS (0) ATMsystem creates transaction Fig. 64.2 Low coupling Discussion : In object oriented languages common forms of coupling between class A and class B is - When class A has an attribute which refers the instance of class B. # Class A object calls upon the service of class B object. #Class A is inherited from class B. «The class A has a method that refers the instance of class B. +-Class B is an interface and if class A implements that interface. Low coupling ericourages assigning of responsibilities to independent classes. Due to this there is no impact of changes made in one class to other class. There is no exact measure of coupling but in general the generic classes or the classes that can be reused frequently should have low coupling. * Contraindication : High coupling to stable classes create the problems in the system design. Benefits : Following are the benefits of low coupling - # Impact of changes can be reduced. ‘* The objects can be understood easily in isolation. The reusability of objects is convenient. | | | | | Review Questions | Q1 Define coupling. | @.2 Explain the concept of low coupling with some | | suitable example. [5] controtier A simple layered architecture has a User Interface Layer at the top and then comes the domain layer. The user interacts with the Ul layer and generate UI events by pressing button, or clicking menu and so on. The UI software objects must process the event and cause the execution of the desired process. For example when the user clicks on the slide show button of Presentation software then, the transition of slides one after the other starts . These are known as the system operations. When user generates some event using the UI objects then there is a first object beyond the UI layer who handles these events. This object is called controller. Problem What first object beyond the UI layer that receives and co-ordinates a systemt operation ? Sol. : Assign the responsibility of controller to an object representing one of the following choices - © Represent overall system or root object or a device which is running within a major subsystem. These choices of controller are called facade controller. «Represent the use case scenario within which some events occur as the controller. Such controller are often named as Handler or Coordinator or Session. Example In the ATMSystem the controller can be Card Reader object. This is the first object that handles the requests after inserting the card in the ATMSystem, Gard Reader =ATMID *CaidReaden) +ReadCard)) ‘4EjectCardl) +RetainCard) Fig. 6. During the analysis, some system operations might be assigned to this controller object. Fig. 5.5.2 ‘The controller Card Reader will handle the enterPIN. Discussion : Normally’ the UI layer objects delegate the work request to domain layer. The controller pattern collects all those work requests from the domain objects. Hence controller is a kind of facade into the domain layer from UI layer. ‘The controller object co-ordinates or controls the activity. It does not do the work itself. Benefits : . « By delegating the system operations responsibilities to the controller supports the concept of reusability. elf the responsibility of controller is handled in an interface object then it is possible to develop the pluggable interfaces. ‘« For occurring the system operations in some specific sequence use of controller pattern is a reasonable choice. Related patterns : ‘Command - In message handling system, each message is handled using separate command object. Fagade - Facade pattern is an object that provides the interface in a large sub-system. When “the client class wants to communicate to the subsystem classes then instead of having direct communication, the client class communicates with the facade interface and then this interface delegates the request to the subsystem classes. For example Layers - According to layers pattern, each layer contains some specific logic. For instance the UI layer contains the User Interface Logic. Subeyotem Class Cont class ean Subsystem Class C] Pure fabrication - This is a GRASP pattern which does not represent the concept in the problem domain. It is an arbitrary creation of designer for achieving low coupling, high cohesion and reusability. This pattern provide some service in domain design model. | Fig. 5.6.3, Review Questions | Q1 What is the controller pattern ? Explain it with | some suitable example. | Q2 Enlist the benefits of controller objec. | 3 What is GRASP ? Explain the following GRASP | patterns : Creator, information expert, low | | coupling, high cohesion and controller. | | a4 Explain crestor and controller design patterns | | Il with examples. 5.6 | High Cohesion ‘The word cohesion means "sticking together". In object oriented system cohesion is said to be a measure of relatedness of all the elements. These elements can be classes, subsystems and so on. Problem How to keep classes: focused, understandable and manageable ? Sol. : Assign the responsibilities in such a manner that the cohesion remains high. ‘A class with low cohesion may camry many unrelated things or does the a lot of work. These classes might face following problems - + These classes are hard to understand. These classes are harder to reuse and finding out reusable elements from these classes is very difficult. * These classes are hard to maintain. Example Consider the ATM System, Discussion : The most common goal of effective design is high lcohesion and low coupling. The cohesion can be described from low to high lcohesion as follows - Very low cohesion : In this type of cohesion, classes are responsible for many things in unrelated areas. low cohesion : In this type of cohesion, classes have responsibilities for many things in related areas. g makeTransaction() F Customer The responsibilities ‘are delegated to other classes Design i | > Withdraw Money [> Deposit Fundy | > Balance Enquiry Moderate cohesion : In this type of cohesion, classes have sibilities for few things. ‘These responsibilities are related to the class but are not related to each other. High ‘cohesion : In this type of cohesion, the classes have responsibilities in one fundamental area. These responsibilities collaborate with other classes to accomplish the desired task. Contraindication : Following are few cases where low cohesion is justified - «The situation in which grouping of responsibilities or code into one class or component to simplify the maintenance by one person. + Sometimes it is desirable to create less cohesive server ‘objects that provide an interface for many operations of remote objects. In distributed environment the remote communication occurs and to avoid the overhead and performance implications associated with these remote objects it is desirable to create less ‘The responsibilty of "ATMSystem" include "Withdrawal", “deposition”, "enquiry’, - ‘These are unrelated responsibilities ‘that result in ow cohesion cohesive server objects that provide an interface for many operations. This approach is called Coarse-Grained Remote Interface. Benefits : 1) The high cohesion pattern often supports for low coupling. 2) The maintenance and modifications are simplified due to high cohesive elements. 3) Reusability can be achieved as the system elements focus the specific functionality. Example 5.6.1 Compare cohesion and coupling with suitable example. Reviow Questions Q.1 What is high cohesion ? Give exampie of it Q.2 What is GRASP ? Explain the design patterns | and the principles used in it, Q3 Explain about low coupling, controller and high | ‘cohesion. [7] Polymorphism - Poly means many and morph means form. In object oriented programming, the polymorphism is a mechanism that decides which object is responsible for handling the corresponding element. Problem How to handle related but varying elements ‘based on element type ?or How to design pluggable components ? Sol. (1) Use subslassing. (2) Make subclass objects responsible for their own behavior and (3) iet proper behavior be invoked automatically by subclass type. Example 8.7.1 Consider an application that computes the area of a shape. The shape can be Rectangle or circle, depending upon the parameters passed, the area of particular shape can be computed. Refer following that represents the polymorphisrs ‘Shape eo 4 Rectangle Triangle gsiarea Fig. 8.7.4 ‘The getarea() function varies from type of shape. Hence ‘the responsibility is assigned to the corresponding subclasses. By sending message to the Shape object, a call will be made to the corresponding sub class object - Rectangle or Triangle, Contraindication : Polymorphism is a powerful property of object-oriented programming. It is a technique that simplifies code rastically , when there are choices that the code must make. For example, if we were writing code for a calculation of area for the Shape, we might find that the code executed for Rectangle, Triangle or Circle will be different. | Without polymorphism we would have to use iftthen-else or switch statements to code the choice. JE we use polymorphism then for each particular shape, the code behaves in the correct way. Benefits : (1) It helps programmer to reuse the class once written, tested and implemented. 2) New implementations can be introduced without affecting other classes. Related Patterns : (1) Protected Variations 2) Adpater, Command, Composite, Proxy, State, and Strategy 5.8 | Pure Fabrication Problem Sometimes, during design, responsibilities need to be assigned that are not naturally attributable to any of the conceptual classes. Then how to assign these responsibilities? Sol. : Assign the responsibility to an artificial class that doesn't belong to domain class model. Most of the GoF Patterns the fabrication of new classes such as observer, adapter, abstract factory ete. Example In Payroll System, domain classes need to store information about employees. In order to do that one option is to assign data storage responsibilities to domain classes. But this option will reduce the cohesiveness of domain. classes as there will be more than one responsibilities that get assigned to domain classes. Other option is to introduce another class which does not represent any domain concept. In the Payroll System we can introduce a new class named PersistenceStorage. This class does not represent any domain entity. The only purpose of this class is to handle data storage functions. Therefore PersistenceStorage is a pure fabrication. Contraindications Sometimes the objects of pure fabrication can be overused . The software is decomposed or organized in terms of functionalities only. Sometimes functions behave just like objects. If overused, Pure fabrication could lead to too many behavior objects that have responsibilities not co-related with the required information. The data is simply passed from one object to another object. Benefits : (1) High cohesion is supported because responsibilities are factored into different classes. 2) Reusability of code. Related Patterns : (@) ‘Low coupling (2) High cohesion (3) All GoF patterns ‘such as Adapter, Command, Strategy 5.9 | indirection Problem How to assign responsibilities in order to remove direct coupling between two things ? Sol. : Assign the responsibility to an intermediate object placed between two components that are not directly When customer makes a peyment” to shop the CreditCardAuthorization class will talk to Modem devices. Persistencestorage! capes ‘Hingert_empinfo) (oes ++delete_empinfo() | ‘+update_empinfo() | This invokes low level API's. Fig. 5.8.41 | Customer ‘1 :makesPayment ae Shop [creditCardAuthorization) AuthorizePayment Ll.

You might also like