The Factory Method Pattern

Transcription

1 The Factory Method Pattern Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses. 1

2 The Factory Method Pattern Structure 2

3 Applicability Use the Factory Method pattern in any of the following situations: A class can not anticipate the class of objects it must create A class wants its subclasses to specify the objects it creates 3

4 Participants The classes and/objects participating in this pattern are: Product: defines the interface for the type of objects the factory method creates ConcreteProduct: implements the Product interface Creator: declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. may call the factory method to create a Product object ConcreteCreater: Overrides the factory method to return an instance of a ConcreteProduct 4

5 Collaborations Collaborations: Creator relies on its subclasses to implement the factory method so that it returns an instance of the appropriate ConcreteProduct 5

6 Consequences Benefits Code is made more flexible and reusable by the elimination of instantiation of application-specific classes Code deals only with the interface of the Product class and can work with any ConcreteProduct class that supports this interface Liabilities Clients might have to subclass the Creator class just to instantiate a particular ConcreteProduct 6

7 Implimentation Issues Creator can be abstract or concrete Should the fatory method be able to create multiple kinds of products? If so, then the fatory method has a parameter (possibly used in an if-else!) to decide what object to create. 7

8 The Abstract Factory Pattern Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. The Abstract Factory pattern is very similar to the Factory pattern. One difference between the two is that with the Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition whereas the Factory pattern uses inheritance and relies on a subclass to handle the desired object instatiation. Actually, the delegated object frequently uses factory method to perform the instantiation. 8

9 The Abstract Factory Structure 9

10 The Abstract Factory Participants AbstractFactory: Declares an interface for operations that create abstract products objects. ConcreteFactory: Implements the operations to create concrete product objects. AbstractProduct: Declares an interface for a type of product object. 10

11 ConcreteProduct: Defines a product object to be created by the corresponding concrete factory. Implements the AbstractProduct interface. Client: Uses only interfaces declared by the AbstractFactory and AbstractProduct classes.s. 11

12 Applicability Use when A system should be independent of how its products are created, composed and represented A system should be configured with one of multiple families of products A family of related product objects is designed to be used together, and you need to enforce this constraint You want to provide a class library of products, and you want to reveal just their interfaces, not their implementation 12

13 Collaborations 1. A single instance of each different Concrete Factory is created at run time. These Concrete Factories are used to create product objects having different implementations. The client should use a different concrete factory for each different product object. 2. The Abstract Factory defers the creation of the product object to its Concrete Factory subclass 13

14 Normal usage: the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. Separate the details of implementation of a set of objects from its general usage. 14

15 Consequences The Abstract Factory pattern has the following consequences: Advantages: It isolates concrete classes because a factory encapsulates the responsibility and the process of creating product objects. - isolates clients from implementation classes. - Clients manipulate instances through their abstract interfaces It makes exchanging products families easy since the class of a concrete factory appears only once in an application. It promotes consistency among products since the application is using objects from only one family at a time. 15

16 Disadvantages: Extending the abstract factory is not easy because the AbstractFactory interface fixes the set of products that can be created. So new products requires extending the factory interface which involves changing the AbstractFactory class and all its subclasses. 16

17 Abstract Fcatory - an example [2001 exam] A software system for handling student results has these requirements: 1. There are two classes of students: Arts and Science. Each Faculty will have its own set of records, one for all Arts students, the other for all Science students. 2. A student's record contains an ID number, type of degree, and marks for all subjects taken this semester. 3. Arts students records have their major discipline (a string like "History"). 4. Arts students only take Arts subjects; Science students only take Science subjects. 5. Each arts student takes 4 subjects, each science student takes only Every subject has a name and a subject code. 7. Arts subjects have an exam mark and an essay mark, each out of Science subjects have an exam mark out of 100 and two assignment marks 9. Every subject has a final mark that can be computed by a function called final. 10. The same method called grade is used for all subjects for calculating the grade from the final mark. 17

18 Students and subjects Student ID,degree RM = new ArtsRecordMaker() // or new ScienceRecordMaker() s = RM.CreateStudent() -- includes setnsubjs for sc in [1..s.NSubjs] s.subject[sc]= RM.CreateSubject() ArtsStudt major SciStudt Subject <<create>> ArtsRecordMaker CreateStudent() CreateSubject() AbstractRecordMaker CreateStudent() CreateSubject() ArtsSubjt exam essay final() ScienceRecordMaker CreateStudent() CreateSubject() ScienceSubjt exam asg1 asg2 final() 18

19 ProductA1 ArtsStudt major Abstract ProductA ConcreteFactory1 Student ID,degree ArtsRecordMaker CreateStudent() CreateSubject() AbstractFactory AbstractRecordMaker CreateStudent() CreateSubject() ProductA2 SciStudt ProductB1 ArtsSubjt exam essay final() ConcreteFactory2 ScienceRecordMaker CreateStudent() CreateSubject() Abstract Factory Abstract ProductB Subject ProductB2 ScienceSubjt exam asg1 asg2 final() 19

20 Example: Different animal world for computer game: Video Game: In this game, different animal objects are created. Requirements: We need to create different animal objects with different characteristics. The way in which the animals are created must be the same from the clients point of view. The animals are divided into two classes: Herbivore and Carnivore. The animals are grouped together by continent, for example, AfricanAnimal, AmericanAnimal, AustralianAnimal, etc. The way in which the animal objects member functions are accessed must be the same for all animals from the point of view of the client. Classes: Abstract Product1 Herbivore Abstract Product2 Carnivore Concrete Product1 Wildebeest & Bison Concrete Product2 Lion & Wolf Draw or sketch the solution on blackboard, relate to the UML diagram of Abstract factory pattern for class discussion. 20

21 The Facade Pattern Description: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. 21

22 Before using the Facade Pattern 22

23 After using the Facade Pattern 23

24 The Facade Pattern Structure 24

25 Applicability Use the Facade pattern: Need to provide a simple interface to a complex system. This is good enough for most clients; more sophisticated clients can look beyond the facade. Need to decouple a subsystem from its clients and other subsystems, thereby promoting subsystem independence and portability. Need to provide an interface to a software layer 25

26 The Facade pattern provides a simple, easy-to-use interface to a complicated software subsystem. Simplifies coupling with this subsystem. Allows changes to subsystem implementation (including changing the names of classes, adding or taking away classes) without affecting clients. Effectively allows higher level object orientation. The whole subsystem now looks like a single class to the outside world. Another way to think of this is as a form of encapsulation. Here instead of hiding some data, we're hiding all the details of a whole subsystem (abstract module). This is higher level encapsulation. With lots of use of this pattern, there could possibly be a class representing each Abstract Module (in Parnas' terminology), acting as a Facade for all the classes in its implementation. Is this a good way to go about developing a large system? A bit like the old ``top-down design''. 26

27 Consequences Advantages It hides the implementation of the subsystem from clients, making the subsystem easier to use. It promotes weak coupling between the subsystems and its clients.this allows you to change the classes that comprise the subsystem without affecting the clients. It reduces compilation dependencies in large software system. 27

28 It simplifies porting systems to other platforms, because it's less likely that building one subsystem requires building all others. Note that Facade does not add any functionality, it just simplifies interfaces. Disadvantage: It does not prevent clients from accessing the underlying classes. 28

29 Example: A compiler Stream BytecodeStream CodeGenerator Compiler Compile() Scanner Parser PnodeBuilder Token Symbol Pnode Invocations StatementNode ExpressionNode RISCCodegenerator StackMachineCodegenerator 29

30 The Iterator Pattern Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. An aggregate object is an object that contains other objects for the purpose of grouping those objects as a unit. It is also called a container or a collection. Examples are a linked list and a hash table. 30

31 The classes and/or objects participating in this pattern are: Iterator (AbstractIterator) defines an interface for accessing and traversing elements. ConcreteIterator (Iterator) implements the Iterator interface. keeps track of the current position in the traversal of the aggregate. Aggregate (AbstractCollection) defines an interface for creating an Iterator object 31

32 ConcreteAggregate (Collection) implements the Iterator creation interface to return an instance of the proper ConcreteIterator. 32

33 The Iterator Pattern Structure 33

34 Applicability Use the Iterator pattern: To support traversals of aggregate objects without exposing their internal representations. To support multiple, concurrent traversals of aggregate objects. To provide a uniform interface for transversing different aggregate structures (that is, to support polymorphic iteration). 34

35 Consequences Advantages: Simplifies the interface of the Aggregate by not polluting it with traversal methods. Supports multiple, concurrent traversals Supports variant traversal techniques. Disadvantages: None. 35

36 Implimentation issues: Who controls the iteration? The client => more flexible: called an external iterator. The iterator itself => called an interior iterator. Who defines the traversal algorithm? The iterator => more common: easer to have variant traversal techniques. The aggregate => iterator only keeps state of the iteration. 36

37 How robust is the iterator? It can be dangerous to modify an aggregate while you are traversing it. If elements are added or deleted from the aggregate you might end up accessing an element twice or missing it completely. A simple solution is to copy the aggregate and traverse the copy, but that is too expensive to do in general. Example: Look at Java Implementation of Iterator, the java.util.enumeration interface act as iterator interface. 37

38 The Command Pattern Intent: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. 38

39 The Command Pattern Structure 39

40 The classes and/or objects participating in this pattern are: Command: declares an interface for executing an operation. ConcreteCommand: defines a binding between a Receiver object and an action. implements Execute by invoking the corresponding operation(s) on Receiver. Client (CommandApp): creates a ConcreteCommand object and sets its receiver. 40

41 Invoker (User): asks the command to carry out the request. Receiver: knows how to perform the operations associated with carrying out the request. 41

42 Applicability When to Use the Command Pattern: When you need an action as a parameter. When you want to implement a callback function capability. When you need to specify, queue, and execute requests at different times. When you need to support undo. When you need to support logging changes. 42

43 When you structure a system around high-level operations built on primitive operations. A Transactions encapsulates a set of changes to data. Systems that use transaction often can use the command pattern. When you need to support a macro language. 43

44 Consequences Command decouples the object that invokes the operation from the one that knows how to perform it. It is easy to add new commands, because you do not have to change existing classes. You can assemble commands into a composite object. 44

45 Implementation Issues: How intelligent should a command be? A command can have a wide range of abilities. At one extreme it merely defines a binding between a receiver and the actions that carry out the request. At the other extreme it implements everything itself without delegating to a receiver at all, (in this case, it is useful for a command that creates independent application). Supporting undo and redo (to reverse execution). Avoiding error accumulation in the undo process. 45

46 What the Command Pattern does: When two objects communicate, often one object is sending a command to the other object to perform a particular function. The most common way to accomplish this is for the first object (the "issuer") to hold a reference to the second (the "recipient"). The issuer executes a specific method on the recipient to send the command. But what if the issuer is not aware of, or does not care who the recipient is? That is, the issuer simply wants to abstractly issue the command? The Command design pattern encapsulates the concept of the command into an object. The issuer holds a reference to the command object rather than to the recipient. The issuer sends the command to the command object by executing a specific method on it. The command object is then responsible for dispatching the command to a specific recipient to get the job done. 46

47 Example: Situation: A GUI system has several buttons that perform various actions. We want to have menu items that perform the same action as its corresponding button. Draw or sketch the solution on blackboard, relate to the UML diagram of Command Pattern for class discussion. Solution: Have an action listener for each paired button and menu item. Keep the required actions in the actionperformed() method of this one action listener. This solution is essentially the command pattern with ConcreteCommand classes that perform the actions themselves. 47

48 Class Problem: Scenario: We want to run a backup operation every hour and a disk status operation every ten minutes. But we do not want the class to know the details of these operations or the objects that provide them. We want to decouple the class that schedules the execution of these methods with the classes that actually provide the behavior we want to execute. (We want to write a class that can periodically execute one or more methods of various objects.) Classes: TaskMinder, TaskEntry, Task, BackupTask, DiskStatusTask, etc. Draw or sketch the solution on blackboard, relate to the UML diagram of Command Pattern for class discussion. 48

49 The State Pattern Intent: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. 49

50 The State Pattern Structure 50

51 The classes and/or objects participating in this pattern are: Context: defines the interface of interest to clients. maintains an instance of a ConcreteState subclass that defines the current state. State: defines an interface for encapsulating the behavior associated with a particular state of the Context. Concrete State: each subclass implements a behavior associated with a state of Context. 51

52 Applicability Use the State pattern in either of the following cases: An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. Often, several operations will contain this same conditional structure. 52

53 Consequences It localize state-specific behavior and partitions for different states. It makes state transitions explicit. State objects can be shared. 53

54 Implementation issues Who defines the state transitions? The Context class => ok for simple situations. The ConcreteState classes => generally more flexible, but causes implementation dependencies between the ConcreteState classes. The State Pattern does not specify which participants defines the criteria for state transitions. When are the ConcreteState objects created? (Creating and destroying State objects.) Create ConcreteState objects as needed (avoids creating objects that won't be used). Create all Concrete objects once and have the Context object keep references to them (it is better when state change occur rapidly; it might be inconvenient, because the Context must keep reference to all states that might be entered). 54

55 Using dynamic inheritance Changing the delegation target at run-time effectively changes the inheritance structure. It lets objects change their behavior and amounts to changing their class. 55

56 Class problem: Situation: Consider a simplified version of the Post Office Protocols used to download from a mail server. Simple POP (SPOP) supports the following command: USER username The USER command with a username must be the first command issued. PASS password The PASS command with a password or the QUIT command must come after USER. If the username and password are valid, then the user can use other commands. 56

57 LIST <message number> The LIST command returns the size of all messages in the mail box. If the optional message number is specified, then it returns the size of that message. RETRV <message number> The RETRV command retrieves all messages in the mail box. If the optional message number is specified, then it retrieves that message. QUIT The QUIT command updates the mail box to reflect transactions taken, then logs the user out. Draw or sketch the solution on blackboard, relate to the UML diagram of State Pattern for class discussion. 57

58 The Chain of Responsibility Pattern Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. With the Chain of responsibility pattern, you create a chain of objects that examine a request. Each object in turn examines the request and handles it, or passes it on to the next objects in the chain. 58

59 The Chain Responsibility Pattern Structure Sample Object Structure 59

60 Participants Handler Defines the interface for handling the requests May implement the successor link ConcreteHandler Handles requests it is responsible for Can access its successor Handles the request if it can do so, otherwise it forwards the request to its successor Client (ChainApp) initiates the request to a ConcreteHandler object on the chain 60

61 Collaborations Client instantiates the Handlers, their connections, and when needed, fires off the chain of action. Handlers take action if they can, otherwise they pass it off to the next successive Handler. Final handler takes action regardless. 61

62 Consequences Reduced coupling between sender and receiver no knowledge of each other Added flexibility in assigning responsibilities to objects (Chain of handlers can be modified dynamically). Not guaranteed that request will be handled 62

63 Applicability When to use: When more than on object may handle a request, and the handler isn't known a priori When you want to issue a request to one of several objects without specifying the receiver explicitly When the set of objects that can handle a request should be specified dynamically 63

64 Implementation Issues The successor chain Use existing links in the program The concrete handlers may already have pointers to their successors, so just use them Define new links Give each handler a link to its successor 64

65 Representing Requests Each request is hard-coded convenient and safe not flexible limited to the fixed set of requests defined by handler Unique handler with parameters more flexible but it requires conditional statements for dispatching request less type-safe to pass parameters Unique handler with Request object parameter Subclasses extend rather than overwrite the handler method 65

66 Class Problem: Situation: Suppose that you are writing software to monitor a security system. Physically, the security system consists of sensing devices (motion detectors, smoke detectors...) that transmit status information to a computer. The computer's job is to log all status information, maintain a display showing current status information and transmit alarms in the event of an emergency. To keep things simple, your monitoring program should instantiate an object for every sensor it is to monitor. This provides a simple way to model each sensor's state. To ensure scalability, an object responsible for an individual sensor should not assume anything about its environment, except that it is at the bottom level of a hierarchical organization. The organization will include objects corresponding to such real world things such as rooms, areas, floors and buildings. Directly modeling the real world provides a straightforward way to display the status of different parts of buildings. It also allows the interpretation of a sensor's state to be based on its environment. For example, if the temperature of a closed room exceeds 180 F then you may want the fire sprinklers in just that room to turn on. If the temperature in an open area of a warehouse exceeds 150 F you may want to turn on the fire sprinklers over that area and the adjacent areas. On the other hand, if the temperature in a freezer exceeds 30 F, to may want to sound an alarm to let people know that that freezer is getting too warm. In all these cases, the object that models a sensor does not decide what to do with the state of the sensor. Instead, it delegates that decision to an object at a higher level of the hierarchy that has more contextual knowledge. Such objects either decide what to do about a notification or pass it on to the object that is organizationally above it. Draw UML diagram for it. 66

67 Physical Security object diagram 67

68 Class diagram showing the general organization of the Chain of Responsibility pattern: 68

69 Solution: See the next slide 69

70 70

71 The Mediator Pattern Description Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly. 71

72 The Mediator Pattern Structure 72

73 The Mediator Pattern Structure Classes Objects 73

74 The classes and/or objects participating in this pattern are: Mediator Defines an interface for communicating with Colleague objects ConcreteMediator Implements cooperative behavior by coordinating Colleague objects Knows and maintains its colleagues Colleague defines an interface for communicating with the Mediator class ConcreteColleague classes (OneColleague, NextColleague) Each Colleague class knows its Mediator object Each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague. 74

75 Applicability When to use the Mediator Pattern Use the Mediator Pattern to centralise complex communications and control between related objects. When a set of objects communicate in a well-defined but complex ways When reusing an object is difficult because it refers to and communicates with many other objects When a behavior that's distributed between several classes should be customizable without a lot of subclassing Complex interaction exists. 75

76 Consequences Limits subclassing Decouples colleagues Simplifies object protocols Abstracts how objects cooperate Centralizes control 76

77 Implementation issues How do Colleagues and Mediators Communicate? Explicit methods in Mediator Generic change method Generic change method overloaded 77

78 Class Problem: Scenario: Font resources are shared data structures, shared between applications and the GUI system. These font resources maybe quite large and complex. If the system had a lot of components(either ActiveX or JavaBeans), each component would have to allocate, manage and destroy their font resources. Every time each of these components repaint, they would have to create the font, select it into the device context, use it, select it out and then delete it. Imagine a container having a number of such components each one doing this on every repaint. A separate mediator object can assist here by maintaining ownership of a reuseable pool of font resources on an application or system-wide basis without affecting the application or the GUI system. It would also help if the mediator object could 'cache' frequently used fonts. This mediator object can thus act as a centralised point of access. Draw a UML diagram for this scenario for class discussion. 78