ECE 355 Software Engineering CHAPTER 8 Instructor Kostas

ECE 355: Software Engineering CHAPTER 8 Instructor Kostas Kontogiannis 1

Course outline • Unit 1: Software Engineering Basics • Unit 2: Process Models and Software Life Cycles • Unit 3: Software Requirements • Unit 4: Unified Modeling Language (UML) • Unit 5: Design Basics and Software Architecture • Unit 6: OO Analysis and Design Unit 7: Design Patterns • Unit 8: Testing and Reliability • Unit 9: Software Engineering Management and Economics 2

• These slides are mainly based on: – Tutorial slides by John Vlissides, see http: //www. research. ibm. com/designpatterns/pubs/dp-tutorial. pdf and http: //www. research. ibm. com/designpatterns/pubs/dwp-tutorial. pdf • Text © 1994 -1999 by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides • Diagrams © 1995 by Addison-Wesley Publishing Company • Note: Compared to the original tutorial by John Vlissides, the diagram notation have been upgraded from OMT to UML and some text has been updated 3

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor • Some more patterns – Template Method – Singleton – Façade • Observations and Conclusions • Further reading 4

Iterator (Behavioral) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Intent – Access elements of an aggregate sequentially without exposing its representation • Applicability – Require multiple traversal algorithms over an aggregate – Require a uniform traversal interface over different aggregates – When aggregate classes and traversal algorithm must vary independently 7

© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Iterator (cont'd) • Structure 8

Iterator Examle import java. util. *; class Int. Set { private Hashtable ht = new Hashtable(); public static class Iterator { private Int. Set set; private Enumeration e; private Integer current; public Iterator( Int. Set in ) { set = in; } public void first() { e = set. ht. keys(); next(); } public boolean is. Done() { return current == null; } public int current. Item() { return current. int. Value(); } public void next() { try { current = (Integer) e. next. Element(); } catch (No. Such. Element. Exception e) { current = null; } } public void add( int in ) { ht. put( new Integer( in ), "null" ); } public boolean is. Member( int i ) { return ht. contains. Key(new Integer(i)); } public Hashtable get. Hashtable() { return ht; } public Iterator create. Iterator() { return new Iterator( this ); } } 9

Iterator Example class Iterator. Demo { public static void main( String[] args ) { Int. Set set = new Int. Set(); ………. // Code to add elements to the set and other code // Clients ask the collection object to create many iterator objects Int. Set. Iterator it 1 = set. create. Iterator(); Int. Set. Iterator it 2 = set. create. Iterator(); // Clients use the first(), is. Done(), next(), current. Item() protocol System. out. print( "n. Iterator: " ); for ( it 1. first(), it 2. first(); ! it 1. is. Done(); it 1. next(), it 2. next() ) System. out. print( it 1. current. Item() + " " + it 2. current. Item() + " " ); System. out. print( "n. Enumeration: " ); for (Enumeration e = set. get. Hashtable(). keys(); e. has. More. Elements(); ) System. out. print( e. next. Element() + " " ); System. out. println(); } } 10

Iterator (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Consequences + Flexibility: aggregate and traversal are independent + Multiple iterators multiple traversal algorithms – Additional communication overhead between iterator and aggregate • Implementation – Internal versus external iterators – Violating the object structure's encapsulation – Robust iterators • Known Uses – Penpoint traversal driver/slave – Inter. Views List. Itr – Unidraw Iterator 11

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor • Some more patterns – Template Method – Singleton – Façade • Observations and Conclusions • Further reading 12

Visitor (Behavioral) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Intent – Centralize operations on an object structure so that they can vary independently but still behave polymorphically • Applicability – When classes define many unrelated operations – Class relationships of objects in the structure rarely change, but the operations on them change often – Algorithms over the structure maintain state that's updated during traversal 19

Visitor (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Consequences + + – – Flexibility: visitor and object structure are independent Localized functionality Circular dependency between Visitor and Element interfaces Visitor brittle to new Concrete. Element classes • Implementation – – Double dispatch Overloading visit operations Catch-all operation General interface to elements of object structure • Known Uses – Program. Node. Enumerator in Smalltalk-80 compiler – IRIS Inventor scene rendering 20

© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Visitor (cont'd) • Structure 21

Example—A Printing Visitor public class Some. Container implements Container { public void accept (Visitor visitor) { for each Object i in this container{ visitor. visit (i); if (visitor. is. Done(this)) break; Definition of Some. Container } } and of the accept method //. . . } public class Printing. Visitor extends Abstract. Visitor { public void visit (Object object) { System. out. println (object); } //. . . Use of visitor } // // in another class. . . Container c = new Some. Container (); //. . . c. accept (new Printing. Visitor ()); 22

Editor Example – Summary – Document Structure • Composite – Formatting • Strategy – Embellishment • Decorator – Multiple Look&Feels • Abstract Factory – (Multiple window systems) • Bridge – (User operations) • Command – Spelling checking & hyphenation • Iterator & Visitor 23

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor • Some more patterns – Template Method – Singleton – Façade • Observations and Conclusions • Further reading 24

Template Method (Behavioral) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Intent – Define the skeleton of an algorithm in an operation, deferring some steps to subclasses • Applicability – To implement invariant aspects of an algorithm once and let subclasses define variant parts – To localize common behavior in a class to increase code reuse – To control subclass extensions 25

© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Template Method (cont'd) • Structure 26

Template Method (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Consequences + Leads to inversion of control (“Hollywood principle”: don't call us – we'll call you) + Promotes code reuse + Lets you enforce overriding rules – Must subclass to specialize behavior • Implementation – Virtual vs. non-virtual template method – Few vs. lots of primitive operations – Naming conventions (do- prefix) • Known Uses – Just about all object-oriented systems (especially frameworks) 27

Template Method (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Typical implementation: public abstract class Node { public final void stream. Out (Output. Stream out) { if (is. Readable()) { do. Stream. Out(out); } else { do. Warning(unreadable. Warning); } } //. . . • is. Readable, do. Stream. Out, and do. Warning are primitive operations 28

Template Method - Example 29

Template Method - Example class Account { public: void Transaction(float amount); void virtual Transaction. Subpart. A(); void virtual Transaction. Subpart. B(); void virtual Transaction. Subpart. C(); } void Account: : Transaction(float amount) { Transaction. Subpart. A(); Transaction. Subpart. B(); Transaction. Subpart. C(); // Even. More. Code; } class Junior. Account : public Account { public: void virtual Transaction. Subpart. A(); } class Savings. Account : public Account { public: void virtual Transaction. Subpart. C(); } // Client code Account* customer; customer = Junion. Account(); customer->Transaction(amount); 30

Singleton (Creational) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Intent – Ensure a class only ever has one instance, and provide a global point of access to it. • Applicability – When there must be exactly one instance of a class, and it must be accessible from a well-known access point – When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code 31

© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Singleton (cont'd) • Structure 32

Singleton (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Consequences + Reduces namespace pollution + Makes it easy to change your mind allow more than one instance + Allow extension by subclassing – Same drawbacks of a global if misused – Implementation may be less efficient than a global – Concurrency pitfalls • Implementation – Static instance operation – Registering the singleton instance 33

Singleton (cont'd) © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley • Known Uses – Unidraw's Unidraw object – Smalltalk-80 Change. Set, the set of changes to code – Inter. Views Session object 34

Singleton - Example class Singleton { public: static Singleton* Instance(); protected: Singleton(); Singleton(const Singleton&); Singleton& operator= (const Singleton&) private: static Singleton* pinstance; }; Singleton* Singleton: : pinstance = 0; // initialize pointer Singleton* Singleton: : Instance () { if (pinstance == 0) // is it the first call? { pinstance = new Singleton; // create sole instance } return pinstance; // address of sole instance } Singleton: : Singleton() { //. . . perform necessary instance initializations } 35

Singleton - Example // Client code Singleton *p 1 = Singleton: : Instance(); Singleton *p 2 = p 1 ->Instance(); Singleton & ref = * Singleton: : Instance(); Although the above example uses a single instance, modifications to the function Instance() may permit a variable number of instances. For example, you can design a class that allows up to three instances. 36

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor • Some more patterns – Template Method – Singleton – Façade • Observations and Conclusions • Further reading 37

© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley Façade 38

Façade 39

Façade - Example 40

Overview • Example: WYSIWYG Editor (Cont'd) – Spelling checking & hyphenation • Iterator • Visitor • Some more patterns – Template Method – Singleton – Façade • Observations and Conclusions • Further reading 41

Inheritance vs. Object Composition • Object composition + + + – – – Provides for clean separation between components through interfaces Allows for dynamic composition Allows for flexible mixing and matching of features Has the overhead of forwarding Suffers from the identity crisis Leads to more fragmentation • Inheritance + – – – No explicit forwarding necessary Close coupling between a class and its base class Inheritance hierarchies are static and cannot be reconfigured at runtime Adding features through subclassing may lead to a combinatorial explosion – Beware of overusing inheritance–inheritance is not always the best choice • Deep inheritance hierarchy (6 levels and more) in your application is a red flag 42

Implementation vs. interface inheritance • Implementation inheritance – inheriting implementation of methods – Is a convenient reuse mechanism, but… – Introduces high coupling • Changing a superclass may brake all subclasses (“fragile base class problem”) • Interface inheritance – inheriting interface but no implementation (e. g. , inheritance involving abstract classes in C++ and interfaces in Java) – Does not suffer from the problems of implementation inheritance – Subtyping and interface inheritance are more important than implementation inheritance – Consider declaring the type of variables to be interfaces rather than 43 concrete classes

OO Frameworks • A framework consists of a set of cooperating classes embodying a design for a family of applications. • There are different categories of frameworks: – White-box frameworks are reused by subclassing, which usually requires understanding the implementation of the framework to some degree • Template method is one of the main mechanisms for white-box frameworks – Black-box framework is reused by parameterizing and assembling framework objects. Black-box frameworks hide their implementation from their users • Black-box frameworks make heavy use of patterns based on object composition such as decorator and strategy. – Many practical frameworks fall somewhere between the white-box 44 and black-box categories

Patterns at Different Levels • Applicable in most stages of the OO lifecycle – Analysis, design, implementation, reviews, documentation, reuse, and refactoring • Analysis patterns – Typical solutions to recuring anlysis problems – See Analysis Patterns, Fowler; Addison-Wesley, 1996 • Architectural patterns – See POSA • Design patterns – Most Go. F design patterns are applicable both at the architectural and detailed design • Idioms – – Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997 Concurrent Programming in Java, Lea; Addison-Wesley, 1997 Advanced C++, Coplien, Addison-Wesley, 1992 Effective C++: 50 Specific Ways to Improve Your Programs and Design (2 nd Edition), Scott Meyers, Addison-Wesley, (September 1997) – More Effective C++: 35 New Ways to Improve Your Programs and Designs, Scott 45 Meyers, Addison-Wesley (December 1995)

Observations • Patterns permit design at a more abstract level – Treat many class/object interactions as a unit – Often beneficial after initial design – Targets for class refactorings • Variation-oriented design – – Consider what design aspects are variable Identify applicable pattern(s) Vary patterns to evaluate tradeoffs Repeat 46