Design Patterns. Structural Patterns. Oliver Haase

Transcription

1 Design Patterns Structural Patterns Oliver Haase 1

2 Purpose Structural patterns describe how to compose classes (incl. interfaces) and objects to get larger structures. Class based structural patterns use interface and implementation inheritance to compose classes and interfaces. Object based structural patterns use aggregation, composition, and associations to compose objects, in order to gain new functionality. 2

3 Adapter 3

4 Motivation Assume, a framework defines a base class (interface) that the specific custom class has to extend (implement), in order to be used in place of the base class (interface). The custom class might not be able to be hooked in this way, because 1.it is unmodifiable (e.g. third party software), or 2.it cannot extend the base class because it already has its own superclass. 4

5 Idea Write an adapter that adapts the custom class' interface to the required framework interface. 5

6 Example Situation: framework custom class VectorUtils filter(vector): Vector <<interface>> Colored isred()? Toy getcolor() for ( Colored item: in) if ( item.isred() ) out.add(item) How to make legacy class Toy look as if it had type Colored? 6

7 Example Solution 1: Object Adapter VectorUtils filter(vector): Vector for ( Colored item: in) if ( item.isred() ) out.add(item) framework <<interface>> Colored isred() custom class Toy getcolor() ToyAdapter toy isred() return toy.getcolor() == RED 7

8 Object Adapter - Code public class ToyAdapter implements Colored { private Toy toy; public ToyAdapter() { this.toy = new public boolean isred() { return toy.getcolor() == RED; 8

9 Example Solution 2: Class Adapter VectorUtils filter(vector): Vector for ( Colored item: in) if ( item.isred() ) out.add(item) framework <<interface>> Colored isred() custom class Toy getcolor() ToyAdapter isred() return getcolor() == RED 9

10 Class Adapter - Code public class ToyAdapter extends Toy implements Colored { public ToyAdapter() { public boolean isred() { return getcolor() == RED; 10

11 Object Adapter - Structure works with target interface. defines interface that the client uses. legacy class. Client Target operation() AdaptedClass similaroperation() Adapter adaptee operation() adaptee. similaroperation() adapts interface of AdaptedClass to required Target interface. 11

12 Class Adapter - Structure Client Target operation() AdaptedClass similaroperation() Adapter operation() similaroperation() 12

13 Class vs. Object Adapter Class Adapter single inheritance only applicable if Target is an interface only adapts AdaptedClass, not its subtypes Adapter can override some of AdaptedClass's behavior preserves object unity (Adapter & AdaptedClass) Object Adapter single inheritance always applicable adapts AdaptedClass and all its subtypes hard to override AdaptedClass's behavior ( subtype AdaptedClass, then adapt this subtype) requires two objects per adapted entity 13

14 Discussion Adapter might draw on multiple classes to provide target interface. Adapter deals with interface inheritance. For legacy code, this is completely sufficient ( legacy code can and need not be modified to take advantage of implementation inheritance). For new code that need not use implementation inheritance, the adapter pattern is sufficient, too. Other scenarios will be considered in the following section. 14

15 Implementation Reuse Patterns 15

16 Motivation Assume, a framework provides a base class that implements certain functionality that custom classes can subtype so as to inherit this functionality. The custom class might not able to be hooked in this way, because it already has its own superclass and thus cannot subclass the base class. However, it wants to benefit from the base class's functionality anyway. Note: This situation does not apply to unmodifiable legacy or third party software, which cannot and need not use the base functionality. 16

17 Situation framework BaseService operation() OwnSuper CustomService1 someoperation()... operation()...? CustomService2 otheroperation()... call of operation()... 17

18 Idea Use composition and delegation instead of inheritance. 18

19 Solution Case 1: BaseService is a concrete class framework BaseService operation() OwnSuper CustomService1 someoperation()... operation()... CustomService2 delegate otheroperation()... delegate.operation()... 19

20 Solution Case 2: BaseService is an abstract class framework BaseService operation() OwnSuper CustomService1 someoperation() SimpleBaseService operation() CustomService2 delegate otheroperation()... operation() delegate.operation()... 20

21 More Complex Situation Assume, a framework provides a base class that defines an interface that the specific custom class has to implement (interface inheritance), and implements certain functionality that custom classes that subtype the base class will inherit (implementation inheritance). The custom class might not able to be hooked in this way, because it already has its own superclass and thus cannot subclass the base class. Note: Third party software that cannot be modified can only be hooked in via an adapter cannot (and need not) use base functionality. 21

22 Idea Combine Adapter and Delegation patterns, i.e. use an adapter for interface inheritance and delegation for implementation inheritance. 22

23 Case 1: Concrete Base Class framework BaseService operation2() OwnSuper ConcreteService1? ConcreteService2 operation1'() operation2() call of operation2() adapt ConcreteService2 to BaseService interface let ConcreteService2 use BaseService.operation2() 23

24 Case 1: Concrete Base Class framework BaseService operation2() OwnSuper ConcreteService1 operation2() Adapter delegate delegate.operation1'() ConcreteService2 delegate operation1'() delegate.operation2() 24

25 Case 2: Abstract Base Class framework BaseService operation2() OwnSuper ConcreteService1 operation2()? ConcreteService2 delegate operation1'() delegate.operation2() adapt ConcreteService2 to BaseService interface let ConcreteService2 use BaseService.operation2() 25

26 Case 2: Abstract Base Class framework BaseService operation2() OwnSuper ConcreteService1 operation2() SmartAdapter delegate ConcreteService2 delegate operation1'() delegate.operation1'() delegate.operation2() Solution: SmartAdapter combines Adapter and SimpleBaseService functionality. 26

27 How is it Done Right? Providing a base class that needs to be extended for interface and implementation inheritance is not the silver bullet But then, how is it done right? provide for interface inheritance: an interface, and for implementation inheritance: - an (abstract, incomplete) skeletal implementation, or - a (concrete, complete) simple implementation of the interface 27

28 Interface & Implementation a) skeletal implementation b) simple implementation <<interface>> Service operation2() <<interface>> Service operation2() AbstractService operation2() operation3() SimpleService operation2() operation3() Note the naming convention for skeletal implementations! 28

29 Interface & Implementation Interface & implementation inheritance thru subclassing <<interface>> Service operation2() (using skeletal implementation, analogous for simple implementation) AbstractService operation2() operation3() ConcreteService otheroperation() operation3() 29

30 Interface & Implementation Pure interface inheritance <<interface>> Service operation2() AbstractService operation2() operation3() OwnSuper ConcreteService operation2() 30

31 Interface & Implementation Implementation inheritance thru delegation: 1) using simple implementation <<interface>> Service operation2() SimpleService operation2() operation3() ConcreteService delegate delegate.operation3() 31

32 Interface & Implementation Implementation inheritance thru delegation: 1) using skeletal implementation <<interface>> Service operation2() AbstractService operation2() operation3() SimpleService ConcreteService delegate operation2() delegate.operation3() 32

33 Adapting Legacy Code, I Class adapter: <<interface>> Service operation2() AbstractService operation2() operation3() LegacyCode similaroperation() Adapter similaroperation() 33

34 Adapting Legacy Code, II Object adapter: <<interface>> Service operation2() AbstractService operation2() operation3() LegacyCode similaroperation() Adapter delegate delegate.similaroperation() 34

35 Adapting Legacy Code, III If implementation inheritance helps adapting: <<interface>> Service operation2() SimpleService operation2() operation3() LegacyCode similaroperation() Adapter delegate operation3(); delegate.similaroperation() 35

36 Alternative Option : Reverse Delegation <<interface>> Service OwnSuper operation() if ( specialization!= null ) specialization.operation() else // own implementation SimpleService specialization: Service operation() ConcreteService1 anotheroperation() ConcreteService2 operation() anotheroperation() Note: specialization object usually passed into SimpleService s c'tor. 36

37 Reverse Delegation - Example Java Thread Class interface Runnable OwnSuper run() // create new thread if ( specialization!= null ) specialization.run() else this.run() { Thread specialization: Runnable start() run() run() MyThread2 MyThread1 run() 37

38 Delegation vs. Reverse Delegation Delegation + client uses instance of ConcreteService with its extended interface - ConcreteService must implement delegation Reverse Delegation - client uses instance of Service with its narrow interface + ConcreteService does not need to implement delegation 38

39 Proxy 39

40 Description Also known as: Surrogate Purpose: Control access to a subject through indirection, i.e. a placeholder object (proxy) that provides the same interface and that delegates operation calls to the actual subject. Computer Science is the discipline that believes all problems can be solved with one more layer of indirection. - Dennis DeBruler. 40

41 Applicability Common reasons to hide a subject behind a proxy: local placeholder for remote communication; basic idea behind Remote Procedure Call (RPC), Remote Method Invocation (RMI) Remote Proxy create expensive objects only on demand Virtual Proxy Example: high resolution graphic in text document, virtual proxy might only know size (bounding box) and position. 41

42 Applicability Common reasons to hide a subject behind a proxy: control access to original subject Protection Proxy access control can mean to only filter out interfaces that shall not be usable, or a full-fledged authentication and authorization mechanism. need for an intelligent reference that e.g. counts number of existing references to subject (needed for automatic garbage collection) Smart Reference 42

43 Structure Client interface through which clients access subject Subject operation() has reference to real subject controls access to real subject might create real subject on demand further functionality depends on kind of proxy Proxy delegate operation() RealSubject operation() The real thing delegate.operation() 43

44 Implementation Example: A service interface that contains methods for usage, for administration, and methods to get a usage or administration proxy: public interface ServiceUsage { void use(); public interface ServiceAdmin { void administrate(int state); public interface Service extends ServiceAdmin, ServiceUsage { ServiceAdmin getadminproxy(); ServiceUsage getusageproxy(); 44

45 Implementation Simple Service implementation... public class ConcreteService implements Service { private int state; private class ConcreteAdminProxy implements ServiceAdmin public void administrate(int state) { ConcreteService.this.administrate(state); private class ConcreteUsageProxy implements ServiceUsage public void use() { ConcreteService.this.use(); 45

46 Implementation... public ServiceAdmin getadminproxy() { return new public ServiceUsage getusageproxy() { return new public void administrate(int state) { this.state = public void use() { System.out.println("state: " + state); 46

47 Implementation Sample application that creates a ConcreteService, then feeds an administration thread with an AdministrationProxy and a usage thread with a UsageProxy. public class Application { private static class AdminThread extends Thread { private final ServiceAdmin serviceadmin; public AdminThread(ServiceAdmin serviceadmin) { this.serviceadmin = serviceadmin; public void run() { for ( int value = 0; true; value++ ) { serviceadmin.administrate(value); try { TimeUnit.SECONDS.sleep(5); catch ( Exception e) { 47

48 Implementation... continued... private static class UsageThread extends Thread { private final ServiceUsage serviceusage; public UsageThread(ServiceUsage serviceusage) { this.serviceusage = serviceusage; public void run() { while ( true ) { serviceusage.use(); try { TimeUnit.SECONDS.sleep(2); catch ( Exception e) { 48

49 Implementation... continued: public static void main(string[] args) { ConcreteService service = new ConcreteService(); ServiceAdmin sa = service.getadminproxy(); ServiceUsage su = service.getusageproxy(); new AdminThread(sa).start(); new UsageThread(su).start(); 49

50 Implementation Variant with dynamic proxies: Java allows to create dynamic proxies that implement a set of interfaces specified at run-time. public class ConcreteService implements Service public ServiceAdmin getadminproxy() { return (ServiceAdmin) Proxy.newProxyInstance( ServiceAdmin.class.getClassLoader(), new Class[] {ServiceAdmin.class, new public ServiceUsage getusageproxy() { return (ServiceUsage) Proxy.newProxyInstance( ServiceUsage.class.getClassLoader(), new Class[] {ServiceUsage.class, new DelegationHandler(this));... 50

51 Implementation Class DelegationHandler forwards all incoming calls to delegate object: public class DelegationHandler implements InvocationHandler { private Service delegate; public DelegationHandler(Service delegate) { this.delegate = public Object invoke(object proxy, Method method, Object[] args) throws Throwable { return method.invoke(delegate, args); 51

52 Implementation Java 5 uses dynamic proxies for Java RMI: When an RMI server object is exported, the runtime system (Java virtual machine) creates a dynamic proxy (RMI stub) that implements the respective remote interface, and forwards all methods calls to the remote server object. This obsoletes the necessity to create stub classes (rmic) beforehand. 52

53 Bridge 53

54 Purpose Decouple abstraction (interfaces) and implementation, such that both can evolve independently of each other. A computer once beat me at chess, but it was no match to me at kick-boxing - Emo Philips 54

55 Motivation Communication send(op, params): void receive(): Result TcpCommunication send(op, params): void receive(): Result UdpCommunication send(op, params): void receive(): Result Scenario: Provide more comfortable RemoteOpComm interface without modification of existing type hierarchy. 55

56 Motivation Communication send(op, params): void receive(): Result TcpCommunication send(op, params): void receive(): Result UdpCommunication send(op, params): void receive(): Result RemoteOpComm invoke(op, params): Result send(op, params) return receive() 56

57 Motivation Communication send(op, params): void receive(): Result TcpCommunication send(op, params): void receive(): Result UdpCommunication send(op, params): void receive(): Result RemoteOpComm invoke(op, params): Result send(op, params) return receive() TcpRemOpComm send(op, params): void receive(): Result UdpRemOpComm send(op, params): void receive(): Result Problem: Implementation classes TCPCommunication and UDPCommunication must be duplicated. 57

58 Solution using Bridge Pattern Client Communication impl send(op, params): void receive(): Result CommunicationImpl send(op, params): void receive(): Result Bridge impl.send(op, params) return impl.receive() RemoteOpComm invoke(op, params): Result send(op, params) return receive() TcpCommunication send(op, params): void receive(): Result UdpCommunication send(op, params): void receive(): Result 58

59 General Structure defines interface for implementation classes (can differ from Abstraction) Client defines interface of the abstraction maintains reference to implementor instance Abstraction impl operation() Implementor operation() Bridge impl.operation() Specialization specialoperation() ConcreteImplementorA operation() ConcreteImplementorB operation() extends Abstraction through usage of Abstraction s operations provides implementation of Implementor interface 59

60 Implications the abstractions (left hand side) use only the functionality provided by class Implementor. Additional functionality in the subclasses cannot be taken advantage of; additional functionality in sub-interfaces must be achieved only through usage of the general functionality as contained in the root interface Abstraction. Bridge leads to loose coupling of abstraction and implementation Implementor object can be replaced at run-time 60

61 Implementation Who decides when and how, what particular Implementor object to use? Option 1: Specialization object, based on the params passed in at construction time. Example: Collection object that gets initialized with small initial size uses LinearList implementation. Large Collection object uses BTree implementation. (Note: Implementation can be dynamically replaced as the collection grows.) 61

62 Implementation Option 1I: Others decide creational patterns! Specialization object gets fed with factory or prototype Dependency injection Specialization object gets passed in Implementor object by Client. 62