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

2. 24 October 2006Kaiser: COMS W4156 Fall 20062 Design Patterns A design pattern is a way of reusing abstract knowledge about a problem and its solution A pattern is a description of the problem and the essence of its solution A pattern should be sufficiently abstract to be reused in different settings Patterns often rely on object characteristics such as inheritance and polymorphism

3. 24 October 2006Kaiser: COMS W4156 Fall 20063 History of Design Patterns 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. “

4. 24 October 2006Kaiser: COMS W4156 Fall 20064 Software Developers’ Lament “If only software engineering could be more like X...”, where X is any design-intensive profession with a longer and apparently more successful history than software It is therefore both comforting and troubling to discover that the same fundamental philosophical, methodological and pragmatic concerns arise in all of these Xs

5. 24 October 2006Kaiser: COMS W4156 Fall 20065 History of Software Design Patterns “Gang of four” 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 by many

6. 24 October 2006Kaiser: COMS W4156 Fall 20066 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.” 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

7. 24 October 2006Kaiser: COMS W4156 Fall 20067 Types of Patterns Creational –Concerned with instantiation –Create objects for you, rather than having you instantiate objects directly, giving your program more flexibility in deciding which objects need to be created for a given case –Class-creation patterns use inheritance in the instantiation process while Object-creation patterns use delegation Structural –Concerned with composition –Help you compose groups of objects into larger structures –Use inheritance to compose interfaces or define other ways to compose objects to obtain new functionality Behavioral –Concerned with communication –Help you define the communication between objects and how the flow is controlled

8. 24 October 2006Kaiser: COMS W4156 Fall 20068 The Abstract Factory Pattern Creational 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()

9. 24 October 2006Kaiser: COMS W4156 Fall 20069 The Abstract Factory Pattern If you want to construct instances of a class, where the class is selected at run-time, then 1.Create one abstract factory class for each existing class (or group of related classes) you wish to create 2.Have a polymorphic “create instance” method on each abstract factory class, conforming to a common method signature, used to create instances of the corresponding class 3.Store and pass around instances of the abstract factory class to control selection of the class to create

10. 24 October 2006Kaiser: COMS W4156 Fall 200610 The Abstract Factory Pattern

11. 24 October 2006Kaiser: COMS W4156 Fall 200611 Other Creational Patterns Builder – separates complex object construction from its representation, so that same construction process can create different representations Factory Method – creates an instance of any of several derived classes, lets a class defer instantiation to subclasses Prototype – specify the kind of objects to create using a prototypical instance, a fully initialized instance is copied or cloned Singleton – a class of which only a single instance can exist, ensure the class has only one instance and provide a global point of access to it

12. 24 October 2006Kaiser: COMS W4156 Fall 200612 The Façade Pattern Structural A single class that represents an entire subsystem Provide a unified interface to a set of interfaces in a subsystem Defines a higher-level interface that makes the subsystem easier to use Applicable when need to provide a simple interface to a complex system, to shield clients from subsystem components, or to provide a single entry point to a library or layer Often semantic wrapper of existing [legacy] objects Example: Java Font and Graphics classes front for dozens of classes for parsing font files and rendering text into geometric outlines and ultimately into pixels

13. 24 October 2006Kaiser: COMS W4156 Fall 200613 The Façade Pattern

14. 24 October 2006Kaiser: COMS W4156 Fall 200614 The Proxy Pattern Structural Provide a surrogate or placeholder for another object to control access to it Several types: –Virtual (or Lazy) – lazy instantiation, useful for holding off on creating resource-hungry objects until functionality actually needed by a client, also Copy-on-write –Remote – hide the fact that the real object is in another address space and provide communication mechanisms between remote objects –Synchronization – multiple accesses to target object, also Caching –Access (or Protection) – checks client’s access permissions, also Firewall –Smart (or Decorator) – provide additional functionality to top of proxied object Example: Reference counting pointer object

15. 24 October 2006Kaiser: COMS W4156 Fall 200615 The Proxy Pattern

16. 24 October 2006Kaiser: COMS W4156 Fall 200616 The Adapter Pattern Structural Convert or wrap the interface of a class into another interface clients expect Lets classes work together that could not otherwise because of incompatible interfaces Makes heavy use of delegation Example: Convert the interface of a Document Object Model of an XML document into a tree structure that can be displayed.

17. 24 October 2006Kaiser: COMS W4156 Fall 200617 The Adapter Pattern

18. 24 October 2006Kaiser: COMS W4156 Fall 200618 Other Structural Patterns Bridge – separates an object’s interface from its implementation, decouples an abstraction from its implementation so that the two can vary independently 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 Decorator – attach additional responsibilities to an object dynamically, provides a flexible alternative to subclassing for extending functionality Flyweight – use sharing to support large numbers of fine-grained objects efficiently

19. 24 October 2006Kaiser: COMS W4156 Fall 200619 The Observer Pattern Behavioral Separates the display of object state from the object itself, e.g., when multiple distinct display views of state are needed (model-view-controller paradigm) Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically Useful for dynamic relationships between objects, hook up a new observer while the program is running, unhook it later However, optimizations to enhance display performance may be impractical

20. 24 October 2006Kaiser: COMS W4156 Fall 200620 Example: Multiple displays enabled by Observer

21. 24 October 2006Kaiser: COMS W4156 Fall 200621 The Observer Pattern

22. 24 October 2006Kaiser: COMS W4156 Fall 200622 Styles of Observer Notification Push – observed “publishes” a change and observers get notified of the change Pull – observers repeatedly poll the observed to note changes The observed does not know anything about the observers Basis for publish-subscribe messaging architectures

23. 24 October 2006Kaiser: COMS W4156 Fall 200623 The Mediator Pattern Behavioral 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 May limit subclassing, centralizes control Example: Instant messaging

24. 24 October 2006Kaiser: COMS W4156 Fall 200624 The Mediator Pattern

25. 24 October 2006Kaiser: COMS W4156 Fall 200625 More Behavioral Patterns Chain of Responsibility – a way of passing a request along a chain 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 – given a language, define a representation for its grammar along with an interpreter for sentences in this language Iterator – sequentially access the elements of a collection, access the elements of an aggregate object sequentially without exposing its underlying representation

26. 24 October 2006Kaiser: COMS W4156 Fall 200626 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

27. 24 October 2006Kaiser: COMS W4156 Fall 200627 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/JavaPatterns.htm http://www.patterndepot.com/put/8/JavaPatterns.htm Some sample code in various languages (some each C++, Java, C#, Perl, Python) at http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Design_Patterns GOF member John Vlissides has another book, Pattern Hatching: Design Patterns Applied (1998), about using patterns – but requires C++ intimacy Other authors have proposed various additional patterns, often with code

28. 24 October 2006Kaiser: COMS W4156 Fall 200628 Guiding Themes Program to an interface and not to an implementation –Define the top of any class hierarchy with an abstract class, which implements no methods, but simply defines the methods the class will support –Then in all your derived classes, you have more freedom to implement these methods as most suits your purposes Favor object composition over inheritance –Construction of objects that contain or encapsulate several other objects –Your new object can have the interface that is best for what you want to accomplish without having all the methods of the parent classes

29. 24 October 2006Kaiser: COMS W4156 Fall 200629 Project Deliverables Project concept (P/F) Revised concept (P/F) First iteration (25%) –1 st iteration plan (5%) –1 st iteration progress report (5%) –1 st iteration demo (5%) –1 st iteration final report (10%) Second iteration (25%) –2 nd iteration plan –Code inspection –2 nd iteration progress report –2 nd iteration demo –2 nd iteration final report

30. 24 October 2006Kaiser: COMS W4156 Fall 200630 Demo due November 8-14 15-20 minutes total including any "setup" time Schedule –With Prof. Kaiser for in/after class time (Thursday November 9 th or Tuesday November 14 th, 11-12:15 or 12:30-1:30) –With your TA otherwise Be prepared to show the code corresponding to any portion of the demo system Be prepared to describe your system's utilization of the component model framework. One representative of each pair must be present at the demo

31. 24 October 2006Kaiser: COMS W4156 Fall 200631 First Iteration Progress Report due November 14th realityThe purpose of this assignment is to revise your requirements, architecture and component-level design to reflect reality, and to evaluate your use of the chosen component model framework. Revise your requirements: –Include your complete set of requirements (use cases or user stories). –For any requirements that changed, show the new version of the requirement and explain the difference. –Indicate any requirements that have been dropped. –If any features are only partially completed, describe what does and does not work.

32. 24 October 2006Kaiser: COMS W4156 Fall 200632 First Iteration Progress Report due November 14th Revise your high-level architecture and lower- level design. Diagram and explain the process-level architecture of your system, including all communication paths. Describe the major expected "workflows" that a user would achieve with the system and explain the corresponding interactions among the architectural units during those scenarios. Consider both end-users and administrators, if applicable.

33. 24 October 2006Kaiser: COMS W4156 Fall 200633 First Iteration Progress Report due November 14th For each internal architectural subsystem, break down into components. Diagram and explain the use of interfaces and control and data flows among the components. Indicate any previously planned subsystems, communication paths, components, interfaces, etc. that are "missing" for whatever reason from your system. Explain the roles of any external "systems" - e.g., databases, web browsers, facilities provided by the component model framework.

34. 24 October 2006Kaiser: COMS W4156 Fall 200634 First Iteration Progress Report due November 14th Describe how you leveraged the main aspects of the component model framework Or "worked around" them if that is indeed what you did. Consider the main services provided by the framework, and discuss any you considered using - both those you did end up using and those you did not (and why not). Discuss any "challenges" that arose in deploying or utilizing the framework, and how you resolved them. State which specific implementation of the component model framework you used, including version number and where you got it from (e.g., url).

35. 24 October 2006Kaiser: COMS W4156 Fall 200635 Deliverables An archive (e.g., a.zip file) with a main document that includes: 1. Cover page (1 page): Indicate the name of your team and list all team members with their full names and email addresses. Indicate that this document presents your First Iteration Final Report. 2. Revised Requirements (no maximum page limit). 3. Revised high-level architecture and component-level design (no maximum page limit). 4. Component-model framework (no maximum page limit). 5. Controversies (maximum 1 page). Additional files in the archive should include: 6. The complete code for your system. Include a README file with installation instructions and a brief description of how to run the system.

36. 24 October 2006Kaiser: COMS W4156 Fall 200636 Upcoming First iteration progress report due October 31 st First demo week November 8-14 First iteration final report due November 14

37. 24 October 2006Kaiser: COMS W4156 Fall 200637 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/