Software Design Patterns I Chap 6

1. CS251 Software Engineering I FCI – Cairo University Software Design Patterns IChap 6

2. Resources • Chapter 6 in the book • List of patterns: http://www.oodesign.com/ • A two page of each patter studied is added to acadox

3. TOC • What are SW patterns & why do we need them • The Observer pattern

4. 1. Background1 • Search for recurring successful designs – emergent designs from practice (via trial and error) • Supporting higher levels of reuse (i.e., reuse of designs) is quite challenging • Described in Gama, Helm, Johnson, Vlissides 1995 (i.e., “gang of 4 book”) • Based on work by Christopher Alexander (an Architect) on building homes, buildings and towns.

5. Background2 • Design patterns represent solutions to problems that arise when developing software within a particular context. E.g., problem/solution pairs within a given context • Describes recurring design structures • Describes the context of usage

6. Background3 • Patterns capture the static and dynamic structure and collaboration among key participants in software designs • Especially good for describing how and why to resolve nonfunctional issues • Patterns facilitate reuse of successful software architectures and designs.

7. Origins of Design Patterns “Each 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 doing it in the same way twice” • Christopher Alexander, A Pattern Language, 1977 • Context: City Planning and Building architectures

8. Elements of Design Patterns • Design patterns have four essential elements: • Pattern name • Problem • Solution • Consequences

9. Pattern Name • A handle used to describe: • a design problem • its solutions • its consequences • Increases design vocabulary • Makes it possible to design at a higher level of abstraction • Enhances communication • “The Hardest part of programming is coming up with good variable [function, and type] names.”

10. Problem • Describes when to apply the pattern • Explains the problem and its context • May describe specific design problems and/or object structures • May contain a list of preconditions that must be met before it makes sense to apply the pattern

11. Solution • Describes the elements that make up the • design • relationships • responsibilities • collaborations • Does not describe specific concrete implementation • Abstract description of design problems and how the pattern solves it

12. Consequences • Results and trade-offs of applying the pattern • Critical for: • evaluating design alternatives • understanding costs • understanding benefits of applying the pattern • Includes the impacts of a pattern on a system’s: • flexibility • extensibility • portability

13. Design Patterns are NOT • Designs that can be encoded in classes and reused as is (i.e., linked lists, hash tables) • Complex domain-specific designs (for an entire application or subsystem) • They are: • “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”

14. Where They are Used • Object-Oriented programming languages [and paradigm] are more amenable to implementing design patterns • Procedural languages: need to define • Inheritance • Polymorphism • Encapsulation

17. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 2. Observer Pattern • Defines a “one-to-many” dependency between objects so that when one object changes state, all its dependents are notified and updated automatically • a.k.a Dependence mechanism / publish-subscribe / broadcast / change-update

18. Subject & Observer • Subject • the object which will frequently change its state and upon which other objects depend • Observer • the object which depends on a subject and updates according to its subject's state.

19. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 b a c a b c x 60 30 10 y 50 30 20 z 80 10 10 Observer Pattern - Example Observers a b c a = 50% b = 30% c = 20% Subject requests, modifications change notification

20. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 Observer Pattern - Working A number of Observers “register” to receive notifications of changes to the Subject. Observers are not aware of the presence of each other. When a certain event or “change” in Subject occurs, all Observers are “notified’.

21. Observer Pattern - Key Players • Subject • has a list of observers • Interfaces for attaching/detaching an observer • Observer • An updating interface for objects that gets notified of changes in a subject • ConcreteSubject • Stores “state of interest” to observers • Sends notification when state changes • ConcreteObserver • Implements updating interface

22. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 observers Observer update() Subject For all x in observers{ x.update(); } attach (Observer) detach (Observer) notify () ConcreteObserver ConcreteSubject subject subjectState observerState setState() update() getState() observerState= subject.getState(); Observer Pattern - UML

23. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 observers Observer update() Subject For all x in observers{ x.update(); } attach (Observer) detach (Observer) notify () ConcreteObserver ConcreteSubject subject subjectState observerState setState() update() getState() observerState= subject.getState(); Observer Pattern - UML

24. Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 :ConcreteSubject :ConcreteObserver-1 :ConcreteObserver-2 setState() notify() update() getState() update() getState() Observer Pattern - Collaborations

25. Java terminology for Subject. Observer Pattern - Implementation interface Observer { void update (Observable sub, Objectarg) // repaint the pi-chart } class Observable { … } public void addObserver(Observer o) {} public void deleteObserver (Observer o) {} public void notifyObservers (Object arg) {} public boolean hasChanged() {}