Design Patterns

1. Design Patterns Moshe Fresko Bar-Ilan University תשס"ח 2008

2. Introduction • Designing OO Software is hard • To find relevant objects • Factor them into classes • Define class Interfaces • Define inheritance hierarchies • Establish key relationships among them • OO Design must be • Specific to the problem at hand • General to address future problems and requirements

3. Introduction • The purpose of the Course is • To record experience in designing object-oriented software as Design Patterns. • Each design pattern systematically names, explains, and evaluates an important and recurring design in OO Programming. • To capture Design Experience in the form that people can use effectively.

4. Introduction • Design Patterns: Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. • Why Design Patterns? • They make it easier to reuse successful designs • Expressing proven techniques makes them more accessable • They help you choose design alternatives • They can improve the documentation and maintenance • They help to get a design “right” faster

5. Resources • Books • Design Patterns: Elements of Reusable Object Oriented Software, Gamma, Helm, Johnson and Vlissides. • The Design Patterns Java Companion, Cooper • Thinking in Patterns, Eckel • Pattern Hatching, Vlissides

6. Design Patterns • In general a pattern has • Pattern Name • Problem • Solution • Consequences

7. Design Patterns inMVC – Model View Controller • MVC is used to build user interfaces in Smalltalk. • MVC consists of three kinds of objects • Model is the Application Object. • View is the screen presentation. • Controller defines the way the user interface reacts to user input. • MVC decouples these objects to increase flexibility and re-use • Subscribe/notify protocol

8. MVC Model

9. MVC - Designs • Subscribe/ Notify protocol • Observer: Decoupling objects so that changes to one can effect any number of others without requiring the changed object to know details of the other • Views can be nested (Buttons, Panels, etc.) • Composite: Lets you create a class hierarchy in which some subclasses define primitive objects and other classes define composite objects that assemble the primitives into more complex objects. • It encapsulates the response mechanism in a Controller object. • Strategy: Is an object that represents an algorithm. It is useful when you want to replace the algorithm either statically or dynamically.

10. Catalog of Design Patterns

11. Organizing the Catalog • With respect to “Purpose” • Creational patterns concern the process of object creation • Structural patterns deal with the composition of classes or objects • Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility • With respect to “Scope” • Class patterns deal with relationships between classes and their subclasses. (with Inheritance, they are static) • Object patterns deal with object relationships (dynamic)

12. Finding Appropriate Objects • OO programs are made of objects • Object: Packages both data and the procedures that operate on that data. • Methods or Operations: The procedures of an objects. • An object performs an operation when it receives a request (or message) from a client. • The object’s internal state must be encapsulated, it cannot be accessed directly. • Decomposing a system into object is hard. (These must be considered: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, etc.)

13. Determining Object Granularity • Objects can vary tremendously in size and number. • Example: • Façade describes how to represent complete systems as an object. • Flyweight pattern describes how to support huge numbers of objects at finest granularities.

14. Specifying Object Interfaces • Every operation has a name, parameters, and return type. This is the operation’s signature. • The set of all signatures are defined as interface to the object. • A type is a name used to denote a particular interface. • Inheriting of types. Subtype and Supertype. • The run-time association of a request to an object is known as dynamic-binding. • Dynamic binding lets you substitute objects that have identical interfaces for each other at run-time. (Polymorphism)

15. Specifying Object Implementation • An object’s implementation is defined by its class. • OMT (Object Modeling Technique) – notification

16. Specifying Object Implementations • Objects are created by instantiating a class. • The object is said to be the instance of the class.

17. Specifying Object Implementations • New classes can be defined in terms of existing classes using class inheritance. • When a sub-class inherits from a parent-class, it includes all the data and operations.

18. Specifying Object Implementations • An abstract class is one whose main purpose is to define a common interface for its subclasses. • An abstract class can not be instantiated. • The operations that an abstract class declares but does not implement is called abstract operations. • Classes that aren’t abstract are called Concrete Classes.

19. Specifying Object Implementations • Subclasses can override an operation defined by its parent classes.

20. Specifying Object Implementations • A mixin class is a class that is intended to provide an optional interface or functionality to other classes. Requires multiple inheritance.

21. Class vs interface Inheritance • An object’s class defines how the object is implemented. • An object’s type refers to its interface – the set of requests to which it can respond.

22. Programming to an Interface not to an Implementation • Two benefits • Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect. • Clients remain unaware of the classes that implement these objects. Clients only know about the abstract classes defining the interface.

23. Reuse Mechanisms • Class Inheritance vs. Object Composition • Inheritance = white-box reuse, Composition = black-box reuse • Class inheritance • Is defined at compile-time, • Is straightforward to use, • Can modify the implementation. • But • You can’t change it at run-time. • Breaks-up the encapsulation. • Depends to the parent class’ implementation. • Object composition • Is defined at run-time • Fewer implementation dependencies • Each class will focus on one work. • Less classes • Favor object composition over class inheritance

24. Reuse Mechanisms • Delegation • Delegation is a way of making composition as powerful for reuse as inheritance. • In delegation, two objects are involved in handling a request, a receiving object delegates the operations to its delegate.

25. Reuse Mechanisms • Parameterized Types • Another technique for reusing functionality is through parameterized types, also known as generics and templates. • This technique lets you define a type without specifying all the other types it uses. • Cannot change at run-time.