24 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser

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

24 October 2006Kaiser: COMS W4156 Fall History of Design Patterns Architect Christopher Alexander –A Pattern Language (1977) –Several other books… – “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. “

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

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

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

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

24 October 2006Kaiser: COMS W4156 Fall 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()

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

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

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

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

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

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

24 October 2006Kaiser: COMS W4156 Fall The Proxy Pattern

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

24 October 2006Kaiser: COMS W4156 Fall The Adapter Pattern

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

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

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

24 October 2006Kaiser: COMS W4156 Fall The Observer Pattern

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

24 October 2006Kaiser: COMS W4156 Fall 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 October 2006Kaiser: COMS W4156 Fall The Mediator Pattern

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

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

24 October 2006Kaiser: COMS W4156 Fall Where to Get Code Examples GoF book defines 23, with sample C++ and Smalltalk Sample C# code for all patterns at Sample Java code for all patterns at Some sample code in various languages (some each C++, Java, C#, Perl, Python) at 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

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

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

24 October 2006Kaiser: COMS W4156 Fall Demo due November 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

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

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

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

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

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

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

24 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser