Enrico Vicario - AA 18/19 Enrico Vicario - AA 18/19 Design Patterns SW Engineering SW Engineering Software Engineering - A.A. 18/19 . 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 Design Patterns in Java . like a handbook of electronics schemes (amplifiers push-pull, totem-pole, …) from the original [GOF] c++ version . ProducerConsumer or Monitor are also patterns in operating systems with a certain regard for Java implementation . 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, … . Basically agnostic, but differently mapped to different languages Enrico Vicario Dipartimento di Ingegneria dell'Informazione Laboratorio Tecnologie del Software – stlab.dinfo.unifi.it Università di Firenze [email protected], stlab.dinfo.unifi.it/vicario 1/98 2/98 Enrico Vicario - AA 18/19 The Observer pattern Enrico Vicario - AA 18/19 The Observer pattern SW Engineering SW Engineering . The problem . one step ahead . (an object of type) Subject has a state variable whose value . assign to Subject is necessary also to (objects of type) Observer_A and Observer_B the responsibility of . (this might occur in the transition from specification to implementation, notifying Observers or in refactoring for separation of main concerns) (inversion of responsibility) . Much about . after any change of its state, maintaining consistence Subject invokes notify() across decoupling which in turn invokes update() on each Observer . a naive solution . (naive is a positive attribute, in the 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) . Yet, the Subject must be aware of all the types and instances of Observer 3/98 4/98 1 Enrico Vicario - AA 18/19 The Observer pattern Enrico Vicario - AA 18/19 The Observer pattern SW Engineering SW Engineering . Some further steps ahead . Dynamic registration of Observers on the Subject . get the Subject rid off the responsibility to register Observers: . attach() and detach() invoked by the Observer or someone else attach() and detach() to be used by the Observers, or by their creators . Subject notifies to AbstractSubject (same object) through notify() (one more inversion of responsibility) . notify() invokes update() on each registered Observer . Decouple the inherent business of a Subject from being observable . Each Observer may call-back on getState() to get the state (using inheritance to reuse the methods for observability) (pull vs push mode) . 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/98 6/98 Enrico Vicario - AA 18/19 The Observer pattern Enrico Vicario - AA 18/19Patterns are often supported or applied by classes n standard APIs SW Engineering SW Engineering . Amplification of interaction :-( . class java.util.Observable . 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 . interface java.util.Observer 7/98 8/98 2 Enrico Vicario - AA 18/19 Notes on java.util.Observable Enrico Vicario - AA 18/19 Observer: examples of code SW Engineering SW Engineering notifyObservers() is public, setChanged() is protected . TBD: show here the piece of code . notification will not be effected unless setChanged has been invoked based on java.util.Observable class and java.util.Observer interface. Observable and ConcreteObservables are not in the same package Stress the fact that the state is a primitive but it must be boxed into an Integer . notifyObservers() is provided with 2 different signatures to pass the reference needed for the push mode. No arguments for pull-mode, an Object for the State in push-mode Stress also the fact that the Observers shall be aware of the type passed in the Object reference received in the push mode notifcation. TBD: A possible exercise: the state is a reference type (not a primitive int); in the push mode implementation, the subject erroneously passes the reference to the state without making a defensive copy; the observer modifies the state of the subject, though this was supposed to be private. TBD: a thought experiment: what about separating responsibilities by composition rather than subclassing; notification trigger cannot be protected, multiple observers lists can be . update() in java.util.Observer receives an Observable and an Object maintainedand switched, … more dynamic, more functional, more complex dependency installation, more error prone, more test demanding, … as usual in the confrontation of composition versus subclassing 9/98 10/98 Enrico Vicario - AA 18/19 Enrico Vicario - AA 18/19 Design Patterns [GOF] SW Engineering SW Engineering . TBD: a ottobre 18 e’ venuto bene descrivere tutto questo cosi’: . A system of 23 Design Patterns . inizia che c’e una calsse che gioca il ruolo di concrete subject e una . [GOF95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, quella di observer, con un constraint "Design Patterns, elements of reusable Object-Oriented software" . Si arriva facilmenet a dire che la resposnabilita’ di enorce the constraint e’ in capo al subject. Sviluppo oluzioen naïve con deu classi, di cui discutiamo limiti (e.g. notificare a piu’ oggetti e di tipo diverso, mescolare il business specific con la conoscenza di chi osserva, … e dettagli, in modo push o pull. Si arriva a un intent: vorremmo che l’observer dipende da subject m anon viceversa . Partiziona du resposnabilita’ ortogonali: ilbusiness specific e farsi osservare, e decidi di partizionare epr subclassing (open issue: potresti epr composizione?). La base class e’ quella riusata e quindi quelloc he serve a farsi osservare, e sta in un package separato. Descrivi le resposnabilita’d elel tre classi; pe rimplementare l’abstract subject non puoi invocare direttamente il concrete observer perche’ sta in un package esterno; deve essere generalizzato il concrete observer, che potrebeb avere tipi diversi, epr identificare l’interfaccia di chi osserva, e introduce l’interfaccia observer . In the next few slides: . emphasis on how a pattern is described, . Concludere con la discussion di chi dipende da chi. not on the pattern itself 11/98 12/98 3 Enrico Vicario - AA 18/19 description of a pattern (Observer) : WHEN Enrico Vicario - AA 18/19 description of a pattern (Observer) : HOW 1/3 SW Engineering SW Engineering . Intent . Structure . Define a one-to-many dependency between objects so that . Described through a class diagram (in a partially superseded notation) when one object changes state, . Close enough, c++ biased, but basically agnostic 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. 13/98 14/98 Enrico Vicario - AA 18/19 description of a pattern (Observer) : HOW 2/3 Enrico Vicario -1 AA page 18/19 aside on: Class, Responsibility, and Collaborations (CRC) cards SW Engineering 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. 15/98 16/98 4 Enrico Vicario - AA 18/19 description of a pattern (Observer) : HOW 3/3 Enrico Vicario - AA 18/19 description of a pattern (Observer) : CONSEQUENCES