Lecture 5b: Basic Design Patterns CSE 111

Lecture 5b: Basic Design Patterns CSE 111

Basic Design Patterns We know our subsystem interface classes and (some of) their methods We need to create classes in our subsystems, and assign responsibilities to those classes There were many ways of doing this, how do we know whether we are making a good choice? 06/09/24 Copyright W. Howden 2

Basic Design Patterns Expert – Which class gets which responsibilities Creator – Which object creates other objects Controller – Which class instance(s) detects events, creates class instances to handle the events if necessary, and calls on appropriate class/object methods 06/09/24 Copyright W. Howden 3

Expert Pattern Assign the responsibility to the class that has the information necessary to fulfill those responsibilities Related principle – Object animation: Take the things that you would normally do to an object and have it do it itself 06/09/24 Copyright W. Howden 4

DateRequest Object Animation Assume that the parameters userName and daterPrefs are what is needed to find a date Instead of calling a procedure, say FindDate(), that takes these parameters and looks for a date, we design a DateRequest class that stores this information. We give the responsibility of finding dates to the DateRequest class because it has the information needed to do this We design DateRequest with a method execute() which causes it to use its information to find dates 06/09/24 Copyright W. Howden 5

Creator Pattern Give class B the responsibility of creating instances of class A if: – B aggregates object instances of A i.e. has class variable of type A – B contains objects of class A e.g. B is an array containing objects of type A – B “records” instances of objects of class A i.e. A is an event class whose instances are recorded by instances of B – B has the initialization data that will be passed to an object of class A when it is created 06/09/24 Copyright W. Howden 6

Creator Pattern Example Who should create an instance of DateRequest that will find a date? dL, the interface object of type DomainLogic the interface of the DomainLogic subsystem – dL has the initialization data for date request – dL is called by the GUI when a dater makes a dating request, so we can view dL as being the object that records the getDate event/request 06/09/24 Copyright W. Howden 7

Controller Pattern Control in procedural designs – top down tree showing procedure calls. E.g. procA() procB() procC() ProcD() procD() procA() calls procB(), procC(), and procD(); procC() calls procD() – call tree shows who is in control of whom – procA() is the main controller since it decides when other procedures should be used/called 06/09/24 Copyright W. Howden 8

Object Oriented Design and Control At the object level we have objects sending each other messages. – looks like a madhouse with everyone talking to everyone else at the same time – however, nothing is going on at the same time, only one message is sent at one time – putting control into an object oriented design? – one or more classes take on control responsibilities 06/09/24 Copyright W. Howden 9

Alternative Controllers Design question: to which class(es) do we give control responsibilities? Possible Kinds of Controllers – System/subsystem – Role – Use Case 06/09/24 Copyright W. Howden 10

System/subsystem Controller Object representing system or subsystem E.g. could be the subsystem interface – E.g. DS – 3 subsystem controllers GUI, DomainLogic, and DB controllers – The objects get the requests and figure out which classes to create and/or send messages to, and in which order, to accomplish the tasks – Called objects may have sub-controller responsibilities 06/09/24 Copyright W. Howden 11

Use Case Controller Recall that Use Cases are the functions that the system needs to perform Use case controllers could result in many controllers since there could be many use cases E.g. DS: instead of one DL interface class, have one for each use case ask for date; update data; delete member, add member, . The GUI would receive a request and send it to the interface/controller for the DomainLogic subsystem that corresponded to the use case E.g. the GUI would receive a request to get a date, and pass it to an instance of the GetDate controller/interface for the DomainLogic subsystem which would then coordinate creation of objects in the DomainLogic, and calls to these objects and the DataBase, as needed to fulfil the request/responsibility 06/09/24 Copyright W. Howden 12

Role Controller “Role” is an actor using the system – E.g. DS – 2 role controllers Member Controller, Administrator Controller – What would this look like in the DS? the GUI would receive a request, and then send it to a role interface/controller for the DomainLogic subsystem e.g. admin request to delete a member would be passed from the GUI to an instance of the AdminController interface which would then coordinate creation of objects in the DomainLogic, and calls to these objects and the DataBase, as needed to fullfill the request/responsibility 06/09/24 Copyright W. Howden 13

Which Controller to Use? System/Subsystem Controllers – corresponds nicely to system architecture/design If it becomes bloated and poorly cohesive, decompose into individual use case controllers – in DS example, subsystem interfaces are good choices Role Controller Disadvantages? – What if two actors/roles can make the same requests? May lead to design awkwardness. 06/09/24 Copyright W. Howden 14