Outline. Design Patterns. Observer Pattern. Definitions & Classifications

Transcription

1 Outline Design Patterns Definitions & Classifications Observer Pattern Intent Motivation Structure Participants Collaborations Consequences Implementation 1

2 What is a Design Pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever using it the same way twice [Christopher Alexander quoted by Gamma, et. al.] A pattern is a problem-solution pair, which can be used in different contexts, together with an advise, on how it has to be used in a new situation 2

3 What is a Design Pattern Reusable solutions to recurring problems that we encounter during software development [Mark Grand] Documentation of a solution for a given (analysis, design or implementation) problem Description of a frequently occurring structure of cooperating components, which solves a general design problem in a particular context 3

4 Design Patterns: History Christopher Alexander Published a pattern book 1970 Pattern language in the realm of urban planning and building architecture 253 patterns for buildings and public spaces Each pattern provided a general solution to a reoccurring design problem in a particular context 4

5 Design Patterns: History Low Sill Pattern Context Windows are being planned for a wall. Problem How high should the windowsill be from the floor? A windowsill that is too high cuts you off from the outside world. One that is too low could be mistaken for a door and is potentially unsafe. Solution Design the windowsill to be 12 to 14 inches from the floor. On upper floors, for safety, make them higher, around 20 inches. The primary function of a window is to connect building occupants to the outside world. The link is more meaningful when both the ground and horizon are visible when standing a foot or two away from the window. 5

6 Design Patterns: History Low Sill Pattern illustrates a couple of important characteristics of patterns: Design (and more generally engineering) is about balancing conflicting forces or constraints Design patterns provide general solutions at a medium level of abstraction Patterns aren't dogma 6

7 Why Design Patterns? Designing object-oriented code is hard, and designing reusable object-oriented software is even harder [E. Gamma] Design patterns foster development of reusable and extensible software Patterns enable programmers to recognize a problem and immediately determine the solution without having to stop and analyze the problem first. Design patterns capture and document design experience Patterns provide a framework/vocabulary for communicating about object oriented design at a high level of abstraction 7

8 Properties Patterns do... provide common vocabulary for communicating about design help document software architectures capture essential parts of a design in compact form (solution schema) describe software abstractions document design experience Patterns do not... provide an exact solution, only provide a solution schema solve all design problems necessarily be object-oriented replace a good software designer / architect but support them 8

9 References Design Patterns 9

10 Types of Patterns Software Patterns Architectural patterns (system design) Pattern-Oriented Software Architecture (POSA) Design patterns (micro architectures) Gang of Four (GOF) Design Patterns Coding Patterns (low level) Idioms / Recipes Analysis Patterns Recurring & reusable analysis models used in requirements engineering Domain-Specific patterns UI patterns, security patterns Anti-Patterns => Refactoring 10

11 Types of Software Patterns Classification Language Specificity Idioms JEE Pattern Recipes Code Smell Design Pattern Architecture Pattern AntiPattern Abstraction 11

12 Pattern Form: GoF Pattern name and classification Intent what does pattern do / when the solution works Also known as other known names of pattern (if any) Motivation the design problem Applicability situations where pattern can be applied Structure a graphical representation of classes in the pattern Participants the classes participating and their responsibilities Collaborations of the participants to carry out responsibilities Consequences trade-offs, concerns Sample code code fragment showing possible implementation Implementation hints, techniques Known uses patterns found in real systems Related patterns closely related patterns 12

13 References Head First Design Patterns Eric Freeman, Elisabeth Freeman and Kathy Sierra O Reilly, 2015 ISBN Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Prentice Hall ISBN

14 Outline Design Patterns Definitions & Classifications Observer Pattern Intent Motivation Structure Participants Collaborations Consequences Implementation 14

15 Observer Pattern Intent One-to-many relation between objects which allows to inform the dependent objects about state changes Consistency assurance between cooperating objects without connecting them too much Notification of a dependent object without knowing it Also Known As Publish-Subscribe Listener Pattern 15

16 Observer Pattern: Motivation A = 50% B = 30% C = 20% 16

17 Observer Pattern: Structure 17

18 Observer Pattern: Participants Subject (may be an abstract class) Knows its observers only through the Observer interface Offers methods to attach or detach an observer Observer (is typically an interface) Defines interface to publish notifications Concrete Subject Stores state of interest to concrete observer objects Notifies its observers when its state changes Concrete Observer Implements Observer interface to keep its state consistent with the subject May maintain a reference to a concrete subject 18

19 Observer Pattern: Collaborations :ConcreteSubject :ConcreteObserver :ConcreteObserver setstate notify update update 19

20 Observer Pattern: Consequences Decoupling Subject only knows Observer interface, no concrete observers Update = dynamically bound => dynamic invocation Subject and observer may belong to different abstraction layers Support for broadcast communication Notification is broadcast, subject does not care about number of observers It is up to the observer to handle or ignore notifications Unexpected updates A simple operation on a subject may cause a cascade of updates 20

21 Observer Pattern: Sample Code (1/2) interface Observer { void update(); } abstract class Observable { private List<Observer> observers = new ArrayList<>(); public void addobserver(observer o) { observers.add(o); } public void removeobserver(observer o) { observers.remove(o); } } protected void notifyobservers() { for(observer obs : observers) { obs.update(); } } 21

22 Observer Pattern: Sample Code (2/2) class Sensor extends Observable { private int temp; public int gettemperature() { return temp; } public void settemperature(int val) { temp = val; notifyobservers(); } } class SensorObserver implements Observer { private Sensor s; SensorObserver (Sensor s) { this.s = s; s.addobserver(this); } } public void update() { System.out.println("Sensor has changed, new temperature is " + s.gettemperature()); } 22

23 One or Many Observables Observable addobserver(observer o) removeobserver(observer o) notifyobservers()??? * Observer update() ConcreteObservable ConcreteObserver setstate(state s) getstate() : State update() 23

24 One or Many Observables Observable Observer addobserver(observer o) removeobserver(observer o) notifyobservers() 0..1 * update() protected void notifyobservers() { for(observer obs : observers) { obs.update(); } } 0..1 : * Observable is typically passed to constructor of concrete Observers Observer may ignore events from other Observables (but then it needs to know the source of the event) 24

25 One or Many Observables Observable Observer addobserver(observer o) removeobserver(observer o) notifyobservers() * * update( Observable source) protected void notifyobservers() { for(observer obs : observers) { obs.update(this); } } * : * Observable is passed as additional argument to update 25

26 What has changed: Push / Pull Model Observable addobserver(observer o) removeobserver(observer o) notifyobservers(object arg) * * Observer update( Observable source, Object arg) protected void notifyobservers(object arg) { for(observer obs : observers) { obs.update(this, arg); } } java.util.eventobject contains method getsource which returns the object on which the event initially occurred 26

27 What has changed: Push / Pull Model Push-Model Observable sends all (relevant) information needed by its observers Observable must know which information is needed by observers (or it has to send all data) Pull-Model Observable sends information about what has changed Observer has to access the Observable's state Example Text replacement in a (long) document Stock change server (subscribed by several thousand listeners) 27

28 Invocation of notifyobservers When is notifyobservers called Automatically at every state change => many updates Explicitly after a set of change operations => responsibility Approaches to reduce number of updates Asynchronous update at idle time AWT/Swing repaint registers an asynchronous request that this component needs to be repainted => multiple calls to repaint may be combined java.util.observable: explicit, but change operations call setchanged notifyobservers becomes only active if ischanged() == true notifyobservers calls clearchanged 28

29 Observer Pattern: Known Uses AWT Event handling ActionListener, MouseListener, MouseMotionListener, Swing: Model-View separation JTable JList Java Beans Event Notifications JavaFX Data Binding 30