1. Chapter 8, Object Design: Reuse and Patterns Qutaibah Malluhi Software Engineering Qatar University Based on slides by Bernd Bruegge & Allen H. Dutoit

2. Object Design Analysis  Determines what the implementation must do (What)  Analysis object model: Skeleton of the final system System design  Formulates the plan of attack (How),  But on a very high level (subsystems, layers and partitions). Object design  Carries out the plan of attack!  Process of adding details to the previous models and making implementation decisions  Iterates on and refines the previous models  Full definitions of classes and associations used in the implementation, as well as the interfaces and the algorithms of the methods used to implement operations.  Basis of implementation

3. Overview of Object Design Activities Reuse: Identification of existing solutions  Proper use of inheritance  Off-the-shelf components  Design patterns  Frameworks Interface specification  Describes precisely each class interface Object model restructuring  Transforms the object design model to improve its understandability and extensibility Object model optimization  Transforms the object design model to address performance criteria such as response time or memory utilization. Chapter 8 Chapter 9 Chapter 10

4. Agenda Reuse Concepts  Solution domain objects, Inheritance, and design patterns Implementation versus Interface Inheritance Delegation Components and Design Patterns (Student Presentations)

5. Moving to the Solution Domain New objects are often needed during object design:  The use of design patterns introduces new classes  The implementation of algorithms may necessitate objects to hold values  New low-level operations may be needed during the decomposition of high-level operations Example: The EraseArea() operation in a drawing program.  Conceptually very simple  Implementation Area represented by pixels Repair () cleans up objects partially covered by the erased area Redraw() draws objects uncovered by the erasure Draw() erases pixels in background color not covered by other objects

6. The Use of Inheritance Description of Taxonomies  Used during requirements analysis. Activity: identify application domain objects that are hierarchically related Goal: make the analysis model more understandable  Specialization or generalization Enhance Reuse  Used during object design  Reduce redundancy: factor out common behavior May lead to implementation inheritance– see later  Extensibility: specify abstract classes and interfaces Typically leads to interface inheritance– see later

7. Metamodel for Inheritance Inheritance is used during analysis and object design Inheritance Interface Inheritance Implementation Inheritance for Reuse Taxonomy Inheritance detected by generalization Inheritance detected by specialization Analysis activity Object Design

8. Implementation Inheritance vs. Interface Inheritance Implementation inheritance  Reuse the implementation  Typically corresponds to “extends” in Java  Goal: Extend an applications’ functionality by reusing functionality that exist in parent class Interface inheritance  Reuse the interface  Typically corresponds to “implements” in java Not necessarily. “extends” if an abstract class is used instead of interface  Inherit from an abstract class with all operations specified, but not yet implemented

9. Taxonomy Example Mammal Tiger Wolf Wale Employee +printInfo() Faculty +printInfo() Staff +printInfo() Secretary +printInfo Engineer +printInfo() Specialization

10. Interface Inheritance Examples Example 1: Dealing with multiple image formats  Abstract Image class defining all operations images should support  Series of specialized image classes for different formats: GIFImage, JPEGImage, etc.  The application deals with the Image superclass  Application can support new image formats by simply adding another specialized subclass (E.g. TiffImage ) Example 2: Dealing with multiple drawing objects  Abstract DrawingObject class  Many specializations Rectangle, Circle, etc.

11.  Problem with implementation inheritance: Some of the inherited operations might exhibit unwanted behavior. What happens if the Stack user calls Remove() instead of Pop()?  Example: I have a List class, I need a Stack class. How about subclassing the Stack class from the List class and providing three methods, Push() and Pop(), Top()? Add() Remove() List Push() Pop() Stack Top() “Already implemented” Implementation Inheritance A very similar class is already implemented that does almost the same as the desired class implementation.

12. Problem with implementation inheritance Some of the inherited operations might exhibit unwanted behavior. What happens if the Stack user calls Remove() instead of Pop()?  This will lead to inability to change stack implementation after clients start using it because some clients may be using remove() Solve by overriding all superclass (List) methods. Unwanted methods can through exception  More complex class that is difficult to understand and reuse  Inheritance decouple the classes using the superclass from the specialized subclass but introduces strong coupling between the subclass and its superclass. This strong coupling is sometimes unwanted (as in the above example)

13. Client Receiver Delegate Delegates to calls Delegation as alternative to Implementation Inheritance A class A is said to delegate to class B if it implements an operation by resending a message to B In delegation two objects are involved in handling a request  A receiving object delegates operations to its delegate.  The developer can make sure that the receiving object does not allow the client to misuse the delegate object

14. Delegation instead of Implementation Inheritance Inheritance: Extending a Base class by a new operation or overwriting an operation. Delegation: Catching an operation and sending it to another object. Use aggregation relationship (List object is included in Stack) Which of the following models is better for implementing a stack? +Add() +Remove() List Stack +Push() +Pop() +Top() +Push() +Pop() +Top() Stack Add() Remove() List

15. Delegation vs. Implementation Inheritance Delegation Pro: Flexibility: Any object can be replaced at run time by another one  E.g. change implementation of stack to use an array without affecting clients Con: Inefficiency: Objects are encapsulated.  E.g. instance of list must be held inside the stack Implementation Inheritance Pro: Straightforward to use Con: Inheritance exposes a subclass to the details of its parent class Any change in the parent class implementation forces the subclass to change (which requires recompilation of both)

16. When should we use inheritance?

17. Liskov Substitution Principle (LSP) “If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T”  “All derived classes must be substituteable for their base class” LSP Gives a good check of when to use inheritance by providing a formal definition of interface inheritance. Demand no more, promise no less  Demand no more: the subclass would accept any arguments that the superclass would accept.  Promise no less: Any assumption that is valid when the superclass is used must be valid when the subclass is used. Interface inheritance – The principle applies  e.g. substitute Image by GIFImage Implementation inheritance – Does not always apply. If it does not, use delegation instead.

18. The Liskov substitution principle Implementation inheritance  When you use List to implement Stack (in Java), use delegation (composition), not inheritance.  The intention is that you use only List’s implementation Implementation inheritance but not interface inheritance List +add() +remove() +find() Stack +push() +pop() +isEmpty() List +add() +remove() +find() Stack +push() +pop() +isEmpty() List +add() +remove() +find() Stack +push() +pop() +isEmpty() MyList

19. The Liskov substitution principle Rectangle -int width; -int height +getWidth() +setWidth() +getHeight() +setHeight() +area(); class Square extends Rectangle { public void setWidth(int width) { super.setWidth(width); super.setHeight(width); } public void setHeight(int height) { super.setHeight(height); super.setWidth(height); } void clientOfRectangle(Rectangle r) { r.setWidth(10); r.setHeight(20); print(r.area()); } Rectangle r = new Square(…); clientOfRectangle(r); // what would be printed? Square +getWidth() +setWidth() +getHeight() +setHeight() IS-A Substituting a rectangle by A square produced different results

20. Rectangle and Square Clients (users) of Rectangle expect that setting height leaves width unchanged (and vice versa) Square does not fulfil this expectation Client algorithms can get confused Hack: attempt to identify subclasses and use if/switch  Evil that you want to prevent

21. Many design patterns use a combination of inheritance and delegation Will see a few examples of Design Patterns

22. Design Patterns Template solutions that developers have refined over time to solve a range of recurring problems. Design pattern elements  Name  Problem Description  Solution  Consequences

23. Popular Reference on Design Patterns The concept of Design Patterns gained popularity after this popular excellent book “Design Patterns: Elements of Reusable Object-Oriented Software”  by GoF (Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides)  published in 1994 Check course website for other references

24. Pattern Example: Adapter Pattern “Convert the interface of a class into another interface that clients expect.” Also known as a wrapper Used to provide a new interface to existing legacy components. Motivation:  Adapter is often used when we create an application using library classes, but where we want to retain the flexibility to select alternative library classes.  Use it when you want to use the functionality provided by an existing application modify our application as little as possible be able to easily switch to alternative implementations

25. Adapter Pattern Name  Adapter Design Pattern Problem Description:  Convert the interface of a legacy class into a different interface expected by the client, so that the client and the legacy class can work together without change Solution:  See next slide Consequences  Client and LegacyClass work together without modification  Adapter works with LegacyClass and all its subclasses  A new Adapter needs to be written for each specialization (e.g., subclass) of ClientInterface

26. Delegation is used to bind an Adapter and an Adaptee Interface inheritance is used to specify the interface of the Adapter class. Target and Adaptee (usually called legacy system) pre-exist the Adapter. Target may be realized as an interface or abstract class in Java. Adapter Pattern Solution Client ClientInterface Request() LegacyClass ExistingRequest() Adapter Request() adaptee targetAdaptee

27. Adapter Solution with Sequence Diagram :Adapter adaptee :RequiredClass :AbstractClass :Client Sequence Diagram for Adapter clientNameForRequiredMethod() requiredMethod() adaptee AbstractClass or Interface clientNameForRequiredMethod() Adapter clientNameForRequiredMethod() RequiredClass requiredMethod() Client { adaptee.requiredMethod (); }

28. Adapter Design Pattern: Example I Implement a stack using List where both List object and stack interfaces exist.

29. Adapter Design Pattern: Example II Existing Financial System: Legacy application that computes the principal money obtained from investing FinancialAdapter amount() Principal computeValue() Financial amount() Client { adaptee.requiredMethod (); } ApplicationLegacy systemAdaptation Legacy application …..: computeValue (float years, float interest, float amount) New application …….: amount (float originalAmount, float numYears, float intRate) Legacy Adaptee

30. Implementation Class FinancialAdapter extends Financial { principal legacyAdaptee = null; // Constructors go here... /** This method uses the legacy computeValue() method */ float amount ( float originalAmount, float unmYears, float intRate) { return legacyAdaptee.computeValue ( originalAmount, numYears, intRate); }} The client could be written with a to use an instance of FinancialAdapter through a Financial (abstract) variable. All calls to the amount () method of Financial are passed to the legacy method computeValue().

31. Abstract Factory Pattern Consider a user interface toolkit to support multiple look-and-feel standards. For portability an application must not hard- code its widgets for one look and feel. How to design the application so that incorporating new look and feel requirements will be easy?

32. Different Look-and-Feel

33. Abstract Factory Solution Define an abstract WidgetFactory class.  This class declares an interface to create different kinds of widgets. There is one abstract class for each kind of widget and concrete subclasses implement widgets for different standards. WidgetFactory offers an operation to return a new widget object for each abstract widget class.  Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use.

34. Widget Factory CreateScrollBar() CreateWindow() WinWidgetFactory CreateScrollBar() CreateWindow() MacWidgetFactory CreateScrollBar() CreateWindow() Client Windows MacWindowWinWindow ScrollBar MacScrollBar WinScrollBar Abstract Factory Solution

35. ABSTRACT FACTORY Pattern Problem:  Provide an interface for creating families of related or dependent objects (platforms) without specifying their concrete classes  Shield client from the implementation of the different families of products (platforms) Solution:  Abstract ProductFactory class. Contains methods for creating each basic kind of widget  Concrete factory for each platform (family of products)  Abstract class for each kind of product,  Concrete classes implement specific platform widgets  Client deals with abstract ProductFactory and abstract product objects (i.e., independent of concrete implementation)

36. Abstract Factory CreateProductA() CreateProductB() ConcreteFactory1 ConcreteFactory2 Client AbstractProductA ProductA2ProductA1 ProductB2 ProductB1 CreateProductA() CreateProductB() CreateProductA() CreateProductB() AbstractProductB Abstract Factory Structure

37. ABSTRACT FACTORY Participants AbtractFactory  Declares interface for operations that create abstract product objects ConcreteFactory  Implements operations to create concrete product objects AbstractProduct  Declares an interface for a type of product object ConcreteProduct  Defines a product object to be created by concrete factory  Implements the abstract product interface Client  Uses only interfaces declared by AbstractFactory and AbstractProduct classes

38. Abstract Factory Applicability Independence from initialization or representation:  The client system should be independent of how its products are created, composed or represented. Manufacturer Independence:  A system must be configured with one of multiple families of products.  You want to provide a class library for a customer (E.g., “dynamic look-and-feel”), but you don’t want to reveal what particular product you are using. Constraints on related products:  A family of related products is designed to be used together and you need to enforce this constraint. Cope with upcoming change:  You use one particular product family, but you expect that the underlying technology is changing very soon, and new products will appear on the market.

39. Abstract Factory Examples of Use User interface toolkit supports multiple look-and-feel standards (Motif, Presentation Manager) Different appearances and behaviors for UI widgets Applications should not hard-code its widgets An intelligent house system dealing with multiple families of products coming from different manufacturers.  Example of a family of products: (light bulb, blinds, electrical switch, etc.)  One product from one family (e.g. light-bulb) is incompatible with another product from a different family (e.g. switch)

40. Component Selection Select existing  off-the-shelf class libraries  frameworks or  components Adjust the class libraries, framework or components  Change the API if you have the source code.  Use the adapter or bridge pattern if you don’t have access Architecture Driven Design

41. Reuse... Look for existing classes in class libraries  JSAPI, JTAPI,.... Select data structures appropriate to the algorithms  Container classes  Arrays, lists, queues, stacks, sets, trees,... It might be necessary to define new internal classes and operations  Complex operations defined in terms of lower-level operations might need new classes and operations

42. Frameworks A framework is a reusable partial application that can be specialized to produce custom applications. Frameworks are targeted to particular technologies, such as data processing or cellular communications, or to application domains, such as user interfaces or real-time avionics. The key benefits of frameworks are reusability and extensibility.  Reusability leverages of the application domain knowledge and prior effort of experienced developers  Extensibility is provided by hook methods, which are overwritten by the application to extend the framework. Hook methods systematically decouple the interfaces and behaviors of an application domain from the variations required by an application in a particular context.

43. Classification of Frameworks Frameworks can be classified by their position in the software development process. Frameworks can also be classified by the techniques used to extend them.  Whitebox frameworks  Blackbox frameworks

44. Frameworks in the Development Process Infrastructure frameworks aim to simplify the software development process  System infrastructure frameworks are used internally within a software project and are usually not delivered to a client. Middleware frameworks are used to integrate existing distributed applications and components.  Examples: MFC, DCOM, Java RMI, WebObjects, WebSphere, WebLogic Enterprise Application [BEA]. Enterprise application frameworks are application specific and focus on domains  Example domains: telecommunications, avionics, environmental modeling, manufacturing, financial engineering, enterprise business activities.

45. White-box & Black-Box Frameworks Whitebox frameworks:  Extensibility achieved through inheritance and dynamic binding.  Existing functionality is extended by subclassing framework base classes and overriding predefined hook methods  Often design patterns such as the template method pattern are used to override the hook methods. Blackbox frameworks  Extensibility achieved by defining interfaces for components that can be plugged into the framework.  Existing functionality is reused by defining components that conform to a particular interface  These components are integrated with the framework via delegation.

46. Class libraries and Frameworks Class Libraries:  Less domain specific  Provide a smaller scope of reuse.  Class libraries are passive; no constraint on control flow. Framework:  Classes cooperate for a family of related applications.  Frameworks are active; affect the flow of control. In practice, developers often use both:  Frameworks often use class libraries internally to simplify the development of the framework.  Framework event handlers use class libraries to perform basic tasks (e.g. string processing, file management, numerical analysis…. )

47. Components and Frameworks Components  Self-contained instances of classes  Plugged together to form complete applications.  Blackbox that defines a cohesive set of operations,  Can be used based on the syntax and semantics of the interface.  Components can even be reused on the binary code level. The advantage is that applications do not always have to be recompiled when components change. Frameworks:  Often used to develop components  Components are often plugged into blackbox frameworks.

48. Summary Object design closes the gap between the requirements and the machine. Object design is the process of adding details to the requirements analysis and making implementation decisions Object design activities include: Identification of Reuse Identification of Inheritance and Delegation opportunities Design pattern selection Frameworks selection Component selection  Interface specification (next chapter)  Object model restructuring  Object model optimization Object design is documented in the Object Design Document, which can be automatically generated from a specification using tools such as JavaDoc. Lecture on Mapping Models to Code

49. Planning Ahead Object Design: Specifying interfaces Mapping Models to Code Testing Coping with Change Agile methodologies and Extreme Programming  Will not use the textbook. See Website resources Presentations + wrap-up session 1-2 Lectures