Enrico Vicario - AA 13/14 SW Engineering Software Engineering - A.A. 13/14 Design Patterns From the original [GOF] c++ version with some regard to Java implementation Enrico Vicario Dipartimento di Ingegneria dell'Informazione Laboratorio Scienza e Tecnologia del Software Università di Firenze [email protected], www.dsi.unifi.it/~vicario 1/97 Enrico Vicario - AA 13/14 Design Patterns SW Engineering ° Design pattern: a reusable solution scheme for some recurrent problem ° A name, a problem, alternative solutions, known consequences, … ° Term first made explicit in Architecture by Christopher Alexander ° A Handbook of electronics schemes (e.g. amplifiers push-pull, totem-pole, …) ° ProducerConsumer or Monitor are also patterns in operating systems ° Patterns in OO Design ° Advanced use of OO programming schemes ° Substitutability and polymorphism, inheritance, composition, … ° Override, method look-up or dynamic binding and virtual methods, … ° Differently mapped to different languages 2/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° The problem ° (an object of type) Subject has a state variable whose value is necessary also to (objects of type) Observer_A and Observer_B ° (this might occur in the transition from specification to implementation, or in refactoring for separation of main concerns) ° Much about maintaining consistence across decoupling ° a naive solution ° (naive is a positive attribute, when beginning) ° Subject provides a public method that Observer invokes to get the value ° But, when shall the Observer unpdate its copy of the state? … might be before using it … but, intermediate states could be relevant as well (e.g. Computing interest on a banking current account) 3/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° one step ahead ° assign to Subject the responsibility of notifying Observers (inversion of responsibility) ° after any change of its state, Subject invokes notify() which in turn invokes update() on each Observer ° Yet, the Subject must be aware of all the types and instances of Observer 4/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Some further steps ahead ° Move out from Subject the responsibility to register Observers: attach() and detach() to be used by the Observers, or by their creators (one more inversion of resposnibility) ° Decouple the inherent business of a Subject from being observable (using inheritance to reuse the methods for observability) ° Abstract Observers under a common interface for homogenous collection ° Call this Observer ° define a one to many dependency so that when an object changes state all its dependents are notified ° Also Known As: Publish & Subscribe (enterprise scale) 5/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Dynamic registration of Observers on the Subject ° attach() and detach() invoked by the Observer or someone else ° Subject notifies to AbstractSubject (same object) through notify() ° notify() invokes update() on each registered Observer ° Each Observer may call-back on getState() to get the state (pull vs push mode) 6/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Amplification of interaction :-( ° In principle might even be unbounded (call-backs) ° Can be reduced by registering Observers on specific Topics, at the attach() ° usual in the enterprise scale publish&subscribe ° Pull vs puh mode ° Pull: the Subject notifies that a change happened, and the Observer calls-back, if needed, accordind to its policy ° Push: Notification from the Subject carries the state change some parameter to distinguish among multiple subjects ° A matter of: efficiency, robustness, coupling ° State consistency ° When the update() is performed, the state must be “stable”, but, some action might trigger multiple "atomic" state changes ° A change manager (Mediator pattern) may get responsibility of coordination 7/97 Enrico Vicario - AA 13/14 Design Patterns [GOF] SW Engineering ° A system of 23 Design Patterns ° [GOF95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, "Design Patterns, elements of reusable Object-Oriented software" ° In the next few slides: emphasis on how a pattern is described, not on the pattern itself 8/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : WHEN SW Engineering ° Intent ° Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ° Also known as ° Publish & subscribe, Dependents, (Listener) ° Motivation: ° <a situation where the problem may occur> ° A common side-effect of partitioning is the need to maintain consistency between related objects, without making the classes tightly coupled, so as because that preserve reusability. ° A User Interface based on the Model View Controller ° Applicability ° When a change to one object requires changing others, and you don't know how many objects need to be changed. 9/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 1/3 SW Engineering ° Structure ° Described through a class diagram ° Close enough, c++ biased, but basically agnostic 10/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 2/3 SW Engineering ° Participants ° Subject: knows its observers; any number of Observer objects may observe a subject; provides an interface for attaching and detaching Observer objects. ° Observer: defines an updating interface for objects that should be notified of changes in a subject. ° ConcreteSubject: stores state of interest to ConcreteObserver objects; sends a notification to its observers when its state changes. ° ConcreteObserver: maintains a reference to a ConcreteSubject object; stores state that should stay consistent with the subject's; implements the Observer updating interface to keep its state consistent with the subject's. ° Collaborations ° ConcreteSubject notifies its observers whenever a change occurs ° After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information. ° ConcreteObserver uses this information to reconcile its state with that of the subject. ° <Class, Responsibility, and Collaborations cards> ° 11/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 3/3 SW Engineering ° collaborations often documented through a sequence diagram 12/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : CONSEQUENCES SW Engineering ° Consequences ° <Good and bad news> ° As main consequences you can : vary subjects and observers independently; reuse subjects without reusing their observers, and vice versa; add observers without modifying the subject or other observers. ° Abstract coupling between Subject and Observer : Subject doesn't know the concrete class of any Observer ° Support for broadcast communication. ° Unexpected updates: since Observers do not know of each other, unexpected updates may occur :-( 13/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : IMPLEMENTATION SW Engineering ° Implementation ° Observing more than one subject : an Observer may depend on many Subjects; in this case, extend the update() interface to let the Observer know which Subject is sending the notification (a paremeter, or a self reference). ° Who triggers the update? Let state-setting methods of the Subject call notify(): simple, but possibly expensive with multiple consecutive changes; Or else, make clients responsible for calling notify() at the right time: is more efficient and flexible, but puts responsibility over (unknown) clients ° Dangling references to deleted Subjects ° Make sure Subject state is self-consistent before notification: unexpected notification may occur (e.g. a Subject subclass call inherited operations); document which Subject methods invoke notify() ° Update protocols: push/pull notification: ° Specifying modifications of interst explicitly: specify topics/aspects of interest to limit inteaction and update ° Sample Code ° <pieces of code, in c++> 14/97 Enrico Vicario - AA 13/14 description of a pattern (Observer): MORE SW Engineering ° Known uses ° Model view controller ° <often coming from a superior yet past world> ° Related Patterns ° Mediator: between Subjects and Observers, to encapuslate complex update ° Singleton: to ensure single instance of the Mediator 15/97 Enrico Vicario - AA 13/14 Impact of change from c+ to Java SW Engineering ° [GOF] Design Patterns refer to C++ ° but, patterns are by construction somehow language agnostic: no impact on WHEN, minor impact on STRUCTURE, some impact on IMPLEMENTATION ° What changes from c++ to java ? ° <intentionally incomplete> ° Method lookup vs dynamic binding and virtual methods ° single inheritance, interfaces, and abstract classes, ° Protected and package-private visibility ° Garbage collection ° Nested classes ° Concrete support from standard API ° <Often an opportunity more than problem to fix> ° Some references to work with ° J.W.Cooper, "The design patterns java companion" ° F.Guidi Polanco "GoF's Design Patterns in Java" ° J.Bloch, "Effective Java" ° … GOF, "Design Patterns, elements of reusable OO software" 16/97 Enrico Vicario - AA 13/14Patterns are often supported or applied by classes n standard APIs SW Engineering ° class java.util.Observable ° interface java.util.Observer 17/97 Enrico Vicario - AA 13/14 The Adapter pattern SW Engineering ° Intent ° Convert the interface of a class into another interface that clients expect ° Also Known as ° Wrapper ° Motivation ° an already