Inheritance EEC 521: Software Engineering Software Design Design Patterns: Decoupling Dependencies 10/15/09 EEC 521: Software Engineering 1 Inheritance is the mechanism by which one class can acquire properties/responsibilities of another class If your application is going to include a bunch of classes that are related, and have a lot in common, then a good way of designing these classes is to put all the common properties and responsibilities in a single base class Individual classes inherit commonalities from the base class Each of the classes that inherit from a base class is called a derived class or a subclass 10/15/09 EEC 521: Software Engineering 3 Dealing with Change Changing requirements Code needs to be flexible Cohesion: how closely operations in a routine are related Coupling: how strongly operations in a routine are dependent on each other Polymorphism The ability to appear in many forms In OO, polymorphism allows a client to treat an object of a derived class as though it were an object of a base class Dynamic dispatch Strong cohesion + loose coupling = easy to change 10/15/09 EEC 521: Software Engineering 2 10/15/09 EEC 521: Software Engineering 4
Coupling and OO Design OO way of reusing code Inheritance and polymorphism Unfortunately, it is very easy to misuse inheritance Concrete dependencies between classes (and objects) makes change difficult Inheritance may cause unnatural relationships between classes Inheritance also results in tight coupling between classes 10/15/09 EEC 521: Software Engineering 5 Patterns are Discovered Patterns are discovered from existing work, not invented Alexander and his collaborators studied their past work and found 253 patterns from a number of buildings and urban settings The gang of four studied a number of OO systems and found 23 patterns It makes sense: Something called a pattern cannot be prescriptive; it has to be descriptive 10/15/09 EEC 521: Software Engineering 7 So, is OO bad? What are you trying to say? Of course OO is not bad! But there are many pitfalls that one needs to be wary of Fortunately, several of these pitfalls have already been identified and solved Design Patterns! What is a Pattern? 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 C. Alexander, The Timeless Way of Building, 1979 10/15/09 EEC 521: Software Engineering 6 10/15/09 EEC 521: Software Engineering 8
A (Short) History of Software Patterns 1987. Cunningham and Beck used Alexander s ideas to develop a small pattern language for Smalltalk 1990. The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns 1991. Bruce Anderson gives first Patterns Workshop at OOPSLA 1993. Kent Beck and Grady Booch sponsor the first meeting of what is now known as the Hillside Group 1994. First Pattern Languages of Programs (PLoP) conference 1995. The Gang of Four (GoF) publish the Design Patterns book Classification of Design Patterns Purpose Creational Patterns. Concern the process of object creation Structural Patterns. Deal with the composition of classes and objects Behavioral Patterns. Deal with the interaction between classes and objects 10/15/09 EEC 521: Software Engineering 9 10/15/09 EEC 521: Software Engineering 11 GoF Design Patterns Solution to a general design problem in a particular context A design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable objectoriented design. The GoF design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. Classification of Design Patterns Scope Class Patterns. Deal with relationships between classes and their subclasses; these relationships are static Object Patterns. Deal with object relationships, and are hence dynamic 10/15/09 EEC 521: Software Engineering 10 10/15/09 EEC 521: Software Engineering 12
Some Design Principles Template Method Solution Encapsulate what varies Favor composition over inheritance Program to interfaces, not implementations 10/15/09 EEC 521: Software Engineering 13 10/15/09 EEC 521: Software Engineering 15 Dependency: Multiple behaviors Example: Sorting Several different design choices Kind of elements being sorted Mode of sorting (ascending, descending, etc.) Algorithm for sorting (quicksort, mergesort, etc.) OO Frameworks When unable to predict all possible implementations, leave hooks open Subclasses can come along and hang behavior on these hooks 10/15/09 EEC 521: Software Engineering 14 10/15/09 EEC 521: Software Engineering 16
Strategy Pattern Solution 10/15/09 EEC 521: Software Engineering 17 Dynamic Reconfiguration On-the-fly behavior modification Injecting new behavior into running applications without stopping them High availability 10/15/09 EEC 521: Software Engineering 18