1. 16 October 2007Kaiser: COMS W4156 Fall 20071 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

2. 16 October 2007Kaiser: COMS W4156 Fall 20072 Design Within a class (or component) –High Cohesion –Completeness –Convenience –Clarity –Consistency Across classes (or components) –Low Coupling

3. 16 October 2007Kaiser: COMS W4156 Fall 20073 Design Pattern A general repeatable solution to a commonly occurring problem A description of the problem and the essence of its solution Should be sufficiently abstract to be reused in different settings Designed to avoid re-design Allow developers to communicate using well- known, well understood names for software interactions

4. 16 October 2007Kaiser: COMS W4156 Fall 20074 Naming Conventions Most modern programming languages supply their own naming conventions (learn it, use it! – Java, C++, C#)JavaC++C# Otherwise, choose a scheme at design- time and stick to it at coding-time For components, interfaces, classes, types, methods, exceptions, members, parameters, variables, …

5. 16 October 2007Kaiser: COMS W4156 Fall 20075 Example: Delegation An object outwardly expresses certain behavior but in reality delegates responsibility for implementing that behavior to an associated object Very general concept, refined in several more specific design patterns

6. 16 October 2007Kaiser: COMS W4156 Fall 20076 Example: Delegation class A { void f() { System.out.println("A: doing f()"); } void g() { System.out.println("A: doing g()"); } } class C { // delegation A a = new A(); void f() { a.f(); } void g() { a.g(); } // normal attributes X x = new X(); void y() { /* do stuff */ } } public class Main { public static void main(String[] args) { C c = new C(); c.f(); c.g(); }

7. 16 October 2007Kaiser: COMS W4156 Fall 20077 Example: Proxy Pattern An object functions as an interface to another object Provide a surrogate or placeholder that uses an extra level of indirection to support distributed, controlled, or intelligent access to an object In its most general form, a proxy is functioning as an interface to. The could be anything: a network connection, a large object in memory, a file, or some other resource

8. 16 October 2007Kaiser: COMS W4156 Fall 20078 Non-Software Proxy Pattern

9. 16 October 2007Kaiser: COMS W4156 Fall 20079 Software Proxy Pattern

10. 16 October 2007Kaiser: COMS W4156 Fall 200710 Discussion: Proxy Maintains a reference that lets it access the real subject Provides an interface identical to subject's so that a proxy can be substituted for the real subject Controls access to the real subject and may be responsible for creating and deleting it May also: –Count the number of references to the real object so that it can be freed automatically when there are no more references –Load a persistent object into memory when it's first referenced –Check that the real object is locked before it is accessed to ensure that no other object can change it –…

11. 16 October 2007Kaiser: COMS W4156 Fall 200711 Types of Proxies Remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space Virtual proxies are placeholders for “expensive to create” or “resource hungry” objects, may cache additional information about the real subject so that they can postpone accessing it Protection proxies check that the caller has the access permissions required to perform a request and may provide different clients with different levels of access Others: copy-on-write, cache, synchronization, …

12. 16 October 2007Kaiser: COMS W4156 Fall 200712 Proxy Pattern Example

13. 16 October 2007Kaiser: COMS W4156 Fall 200713 Example: Façade Pattern A single class that represents an entire subsystem or library Provides a unified interface to a set of interfaces May simplify by providing convenient methods for common tasks that internally involve multiple classes/methods Often semantic wrapper of existing [legacy] objects

14. 16 October 2007Kaiser: COMS W4156 Fall 200714 Non-Software Façade Pattern

15. 16 October 2007Kaiser: COMS W4156 Fall 200715 Software Façade Pattern

16. 16 October 2007Kaiser: COMS W4156 Fall 200716 Discussion: Façade Knows which subsystem classes are responsible for a request and delegates client requests to appropriate objects Subsystem classes handle work assigned by façade but have no knowledge of the façade and keep no reference to it Reduces dependencies of outside code on the inner workings of a subsystem May reduce learning curve for novice users but be insufficient for power users

17. Façade Pattern Example

18. 16 October 2007Kaiser: COMS W4156 Fall 200718 History of “Design Patterns” (Building) Architect Christopher Alexander –A Pattern Language (1977) –Several other books –www.patternlanguage.comwww.patternlanguage.com “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 the same way twice. “

19. 16 October 2007Kaiser: COMS W4156 Fall 200719 History of Software Design Patterns Arose from frameworks like Model-View- Controller used in early OO programming (notably Smalltalk) “Gang of Four” (GoF): Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software (1995) – described 23 patterns (observed, not invented) Many conferences, symposia, books, …

20. 16 October 2007Kaiser: COMS W4156 Fall 200720 Design Patterns “A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.” [GoF]

21. 16 October 2007Kaiser: COMS W4156 Fall 200721 Design Pattern Elements Name Problem description Solution description –Not a concrete design but a template for a design solution that can be instantiated in different ways Consequences –The results and trade-offs of applying the pattern

22. 16 October 2007Kaiser: COMS W4156 Fall 200722 Design Pattern Elements (Expanded) name and classification intent also known as motivation applicability structure participants collaborations consequences implementation sample code known uses related patterns

23. Original Catalog of Patterns Purpose CreationalStructuralBehavioral ScopeClassAbstract MethodAdapter (class)Interpreter Template Method ObjectAbstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

24. 16 October 2007Kaiser: COMS W4156 Fall 200724 Creational Patterns Concerned with instantiation Create objects for you, rather than having you instantiate objects directly

25. 16 October 2007Kaiser: COMS W4156 Fall 200725 Creational Patterns Factory Method – creates an instance of several derived classes Abstract Factory – creates an instance of several families of classes Singleton – a class of which only a single instance can exist, ensures the class has only one instance and provides a global point of access to it

26. 16 October 2007Kaiser: COMS W4156 Fall 200726 Factory Method Pattern Define an interface for creating an object, but let subclasses decide which class to instantiate Lets a class defer instantiation to subclasses Common in toolkits and frameworks where library code needs to create objects of types that may be subclassed by applications using the framework More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects

27. 16 October 2007Kaiser: COMS W4156 Fall 200727 Non-Software Factory Method Pattern

28. 16 October 2007Kaiser: COMS W4156 Fall 200728 Software Factory Method Pattern

29. 16 October 2007Kaiser: COMS W4156 Fall 200729 Discussion: Factory Method Defines a "virtual" constructor Unlike a constructor, factory methods can have different and more descriptive names Unlike a constructor, an existing object might be reused, instead of a new object created (object pooling) The new operator considered harmful (make all constructors private or protected)

30. 16 October 2007Kaiser: COMS W4156 Fall 200730 Factory Method Pattern Example class Complex { public static Complex fromCartesian(double real, double imag) { return new Complex(real, imag); } public static Complex fromPolar(double rho, double theta) { return new Complex(rho * cos(theta), rho * sin(theta)); } private Complex(double a, double b) { //... } // Same as fromCartesian(-1, 0) Complex c = Complex.fromPolar(1, pi);

31. 16 October 2007Kaiser: COMS W4156 Fall 200731 Abstract Factory Pattern Creates an instance of any of a family of classes Provide an interface for creating families of related or dependent objects without specifying their concrete classes Useful for families of products and to enforce families of products that must be used together Promotes consistency among products Example: DocumentCreator class that provides interfaces to create instances of several kinds of documents, e.g., createLetter() and createResume()

32. 16 October 2007Kaiser: COMS W4156 Fall 200732 Non-Software Abstract Factory Pattern

33. 16 October 2007Kaiser: COMS W4156 Fall 200733 Software Abstract Factory Pattern

34. 16 October 2007Kaiser: COMS W4156 Fall 200734 Discussion: Abstract Factory Coordinates the instantiation of sets of objects that have varying implementations in such a way that only legitimate combinations of instances are possible, and hides these concrete instances behind a set of abstractions Hides from consuming (client) objects: –The number of sets of instances supported by the system –Which set is currently in use –The concrete types that are instantiated at any point –The issue upon which the sets vary (might be determined from a config file)

35. 16 October 2007Kaiser: COMS W4156 Fall 200735 Abstract Factory Pattern Example

36. 16 October 2007Kaiser: COMS W4156 Fall 200736 Singleton Pattern Allow for only one instance of a given class to ever exist (encapsulates that the number of instances is constrained) Provide a mechanism to obtain this instance that any client can access Examples include objects needed for logging, communication, database access, etc.

37. 16 October 2007Kaiser: COMS W4156 Fall 200737 Non-Software Singleton Pattern

38. 16 October 2007Kaiser: COMS W4156 Fall 200738 Software Singleton Pattern

39. 16 October 2007Kaiser: COMS W4156 Fall 200739 Discussion: Singleton Typically instantiated lazily - the instance is not created until it is needed, perhaps never If stateful, analogous to a global variable (with many of the same problems as a global variable, e.g., unexpected side-effects) May need to ensure thread safety (if it is possible for one thread to be engaged in the creation of the instance while another is checking for null, possibly resulting in two instances) Can scale to two, three or more instances for load-balancing

40. 16 October 2007Kaiser: COMS W4156 Fall 200740 Singleton Pattern Example

41. 16 October 2007Kaiser: COMS W4156 Fall 200741 Other Creational Patterns Builder: separate the construction of a complex object from its representation so that the same construction process can create different representations Prototype: specify the kind of objects to create using a prototypical instance, a fully initialized instance is copied or cloned (not the same as prototypes used during software engineering lifecycle requirements phase) …

42. 16 October 2007Kaiser: COMS W4156 Fall 200742 Structural Patterns Concerned with composition Help you compose groups of objects into larger structures Eases design by identifying a simple way to realize relationships between entities

43. 16 October 2007Kaiser: COMS W4156 Fall 200743 Structural Patterns Proxy - a class functioning as an interface to another thing Façade - create a simplified interface of an existing interface to ease usage for common tasks Adapter – 'adapts' one interface for a class into an interface that a client expects

44. 16 October 2007Kaiser: COMS W4156 Fall 200744 Adapter Pattern Convert or wrap the interface of a class into another interface clients expect Useful when an already existing class provides some or all of the services needed but does not provide the interface needed Lets classes work together that could not otherwise because of incompatible interfaces Example: Convert the interface of a Document Object Model of an XML document into a tree structure that can be displayed

45. 16 October 2007Kaiser: COMS W4156 Fall 200745 Non-Software Adapter Pattern

46. 16 October 2007Kaiser: COMS W4156 Fall 200746 Software Adapter Pattern

47. 16 October 2007Kaiser: COMS W4156 Fall 200747 Discussion: Adapter Creates an intermediary abstraction that translates, or maps, the old component to the new system Makes heavy use of delegation where the delegator is the adapter (or wrapper) and the delegate is the class being adapted Responsible for handling any logic necessary to transform data into a form that is useful for the consumer Can wrap either an individual object instance or an aggregation of multiple object instances, and operate at either object or class level

48. 16 October 2007Kaiser: COMS W4156 Fall 200748 Adapter Pattern Example

49. 16 October 2007Kaiser: COMS W4156 Fall 200749 Individual Object Adapter

50. 16 October 2007Kaiser: COMS W4156 Fall 200750 Aggregate Adapter

51. 16 October 2007Kaiser: COMS W4156 Fall 200751 Object Adapter

52. 16 October 2007Kaiser: COMS W4156 Fall 200752 Class Adapter

53. 16 October 2007Kaiser: COMS W4156 Fall 200753 Other Structural Patterns Bridge – separates a varying entity from a varying behavior, decouples an abstraction from its implementation so that the two can vary independently (analogous to branching conditional logic) Composite – compose objects into a tree structure of simple and composite objects to represent part-whole hierarchies, lets clients treat individual objects and compositions of objects uniformly (e.g., root vs. internal vs. leaf node) Decorator – attach additional behavior(s) to an object dynamically, provides a flexible alternative to subclassing for extending functionality (e.g., pre and post processing) Flyweight – use sharing to support large numbers of fine-grained objects efficiently (e.g., each character object in a word processor shares reference to same object with font, formatting, etc.) …

54. 16 October 2007Kaiser: COMS W4156 Fall 200754 Behavioral Patterns Concerned with communication Identify common communication patterns between objects and realize these patterns Help you define the communication between objects and how the flow is controlled

55. 16 October 2007Kaiser: COMS W4156 Fall 200755 Behavioral Patterns Observer (Publish/Subscribe or Event Listener) - objects register to observe an event which may be raised by another object Mediator - defines simplified communication between classes

56. 16 October 2007Kaiser: COMS W4156 Fall 200756 Observer Pattern Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically Encapsulate the core (or common or engine) components in a Subject abstraction, and the variable (or optional or user interface) components in an Observer hierarchy

57. 16 October 2007Kaiser: COMS W4156 Fall 200757 Non-Software Observer Pattern

58. 16 October 2007Kaiser: COMS W4156 Fall 200758 Software Observer Pattern

59. 16 October 2007Kaiser: COMS W4156 Fall 200759 Discussion: Observer Useful for dynamic relationships between objects, hook up a new observer while the program is running, unhook it later Often associated with the model-view-controller (MVC) paradigm: separates the display of object state from the object itself, e.g., when multiple distinct display views of state are needed Possible optimizations such as event compression (only sending a single change broadcast after a series of consecutive changes has occurred)

60. 16 October 2007Kaiser: COMS W4156 Fall 200760 Styles of Observer Notification Push – subject “publishes” a change and observers get notified of the change Pull – observers repeatedly poll the subject to note changes The subject does not know anything about the observers A single observer may monitor multiple subjects

61. 16 October 2007Kaiser: COMS W4156 Fall 200761 Example: Multiple Displays Enabled by Observer

62. 16 October 2007Kaiser: COMS W4156 Fall 200762 Mediator Pattern Define an object that encapsulates how a set of objects interact Promotes loose coupling by keeping objects from referring to each other explicitly, and allows to vary their interaction independently Defines simplified communication between classes where otherwise the interactions may be complex, with code buried inside those classes Example: Instant messaging

63. 16 October 2007Kaiser: COMS W4156 Fall 200763 Non-Software Mediator Pattern

64. 16 October 2007Kaiser: COMS W4156 Fall 200764 Software Mediator Pattern

65. 16 October 2007Kaiser: COMS W4156 Fall 200765 Discussion: Mediator Design an intermediary to decouple and orchestrate many peers, promotes the many-to-many relationships between interacting peers to "full object status“ Like façade, provides a unified interface to a set of interfaces in a subsystem, different from façade in that the underlying classes interact with each other through the mediator Façade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes (i.e., it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa)

66. 16 October 2007Kaiser: COMS W4156 Fall 200766 Mediator Pattern Example

67. 16 October 2007Kaiser: COMS W4156 Fall 200767 More Behavioral Patterns Chain of Responsibility – a way of passing a request along a chain of objects, or choosing among a set of objects, avoid coupling the sender of the request to its receiver by giving more than one object a chance to handle the request Command – encapsulate a command request as an object, used to parameterize clients with different requests, queue or log requests, and support undoable operations Interpreter – implements a specialized computer language grammar to solve a specific set of problems (e.g., SQL) Iterator – sequentially access the elements of a collection, access the elements of an aggregate object sequentially without exposing its underlying representation

68. 16 October 2007Kaiser: COMS W4156 Fall 200768 More Behavioral Patterns Memento – capture, externalize and restore an object’s internal state (without violating encapsulation) State – alter an object’s behavior when its internal state changes, the object will appear to change its class Strategy – define a family of algorithms, encapsulate each one inside a class, and make them interchangeable; let’s the algorithm vary independently from clients that use it Template Method – define the skeleton of an algorithm and defer (some) exact steps to subclasses, lets subclasses refine certain steps of an algorithm without changing the algorithm’s structure Visitor - defines a new operation on the elements of an object’s structure without changing its class …

69. 16 October 2007Kaiser: COMS W4156 Fall 200769 Where to Get Code Examples GoF book defines 23, with sample C++ and Smalltalk Sample C# code for all patterns at http://www.dofactory.com/Patterns/Patterns.aspx http://www.dofactory.com/Patterns/Patterns.aspx Sample Java code for all patterns at http://www.patterndepot.com/put/8/JavaPatternsht m http://www.patterndepot.com/put/8/JavaPatternsht m Sample Java and C++ code for all patterns http://www.vincehuston.org/dp/, also “Who ya gonna call?” http://www.vincehuston.org/dp/“Who ya gonna call?” Some sample code in various languages at http://en.wikipedia.org/wiki/Design_Patterns, includes many patterns beyond original 23 (includes a new category of Concurrency Patterns) http://en.wikipedia.org/wiki/Design_Patterns

70. 16 October 2007Kaiser: COMS W4156 Fall 200770 Summary Design Patterns write down and catalog common interactions between objects (or classes, or components) that programmers have frequently found useful Primarily applicable to OO programming, but also applies to some non-OO programming Intuition: Non-Software Examples of Software Design PatternsNon-Software Examples of Software Design Patterns Another great source of intuition particularly wrt testing and cost-benefit issues, but only covers subset of patterns, at http://www.netobjectivesrepository.com/ http://www.netobjectivesrepository.com/

71. 16 October 2007Kaiser: COMS W4156 Fall 200771 First Iteration Progress Report Due Next Week! Tuesday 23 October, 10am Assignments posted on course websitecourse website Submit via CourseWorksCourseWorks First Iteration Progress Report

72. 16 October 2007Kaiser: COMS W4156 Fall 200772 Upcoming Deadlines First iteration demo “week” October 30 th – November 8 th (schedule with your TA) First iteration final report due November 9 thFirst iteration final report Midterm Individual Assessment posted Friday November 9 th Midterm Individual Assessment due Friday November 16 th  Reminder: reading Szyperski is optional, but reading Patton is required (you’ll need for FIA) – bookstore is sending back unsold texts this week

73. 16 October 2007Kaiser: COMS W4156 Fall 200773 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/