This document introduces object-oriented design concepts. It discusses how software design can be represented using interacting objects that manage their own state and operations. Various models for describing object-oriented design are introduced, including class diagrams, sequence diagrams, and state machine diagrams. Design patterns are also introduced as a way to reuse knowledge about solving common design problems.

1. Object Oriented Design Sudarsun S., M.Tech Director – R & D Checktronix India Pvt Ltd Chennai 600010

8. Interacting objects

15. A generalisation hierarchy

21. Weather station subsystems

22. Weather station - data collection sequence

26. Example: Invoice

30. CRC Card

37. Example class Car extends Vehicle { . . . private Tire[] tires; }

38. Example UML Notation for Inheritance and Aggregation

40. UML Relationship Symbols Open Dotted Dependency Diamond Solid Aggregation Triangle Dotted Interface Implementation Triangle Solid Inheritance Arrow Tip Line Style Symbol Relationship

43. Attributes and Methods in UML Attributes and Methods in a Class Diagram

46. Aggregation and Association An Association Relationship

49. Sample Invoice

57. Printing an Invoice – UML Diagrams The Relationships Between the Invoice Classes

59. Method Documentation – Invoice class /** Describes an invoice for a set of purchased products. */ public class Invoice { /** Adds a charge for a product to this invoice. @param aProduct the product that the customer ordered @param quantity the quantity of the product */ public void add(Product aProduct, int quantity) { } /** Formats the invoice. @return the formatted invoice */ public String format() { } }

60. Method Documentation – LineItem class /** Describes a quantity of an article to purchase and its price. */ public class LineItem { /** Computes the total cost of this line item. @return the total price */ public double getTotalPrice() { } /** Formats this item. @return a formatted string of this line item */ public String format() { } }

61. Method Documentation – Product class /** Describes a product with a description and a price. */ public class Product { /** Gets the product description. @return the description */ public String getDescription() { } /** Gets the product price. @return the unit price */ public double getPrice() { } }

62. Method Documentation – Address class /** Describes a mailing address. */ public class Address { /** Formats the address. @return the address as a string with three lines */ public String format() { } }

79. Patterns by Example: Multiple displays enabled by Observer A=10% B=40% C=30% D=20% Application data A B C D A D C B Relative Percentages Y 10 40 30 20 X 15 35 35 15 Z 10 40 30 20 A B C D Change notification Requests, modifications

81. The Observer pattern observerState= subject  getState(); Subject attach (Observer) detach (Observer) Notify () Observer Update() Concrete Observer Update() observerState Concrete Subject GetState() SetState() subjectState observers subject For all x in observers{ x  Update(); }

83. The Mediator Pattern

85. Facade Pattern: Problem Subsystem classes Client Classes Need to communicate with

86. Facade Pattern: Solution Subsystem classes Fac ade Client Classes

87. The Façade Pattern

89. The Proxy Pattern

91. The Adapter Pattern

93. The Abstract Factory Pattern AbstractFactory CreateProductA() CreateProductB() ConcreteFactory1 Client ProductA1 ProductA2 AbstractProductA ProductB2 ProductB1 AbstractProductB ConcreteFactory2 CreateProductA() CreateProductB()

94. Abstract Factory Example WidgetFactory CreateScrollbar() CreateWindow() Window ScrollBar WWidgetFactory MacWidgetFactory Client WWindow MacWindow MacScrollBar WScrollBar One for each standard.

100. Changes with Rigidity The System Officially Rigid Area Where the change should be made Where the change must be made now Are we containing risk, or spreading rot?

102. Increasing Risk Defects v. Cumulative Modifications Systems tend to become increasingly fragile over time. Intentional, planned partial rewrites may be necessary to sustain growth and maintenance. Changes Probability of introducing a bug 1.0

104. The Trailer The Trailer

106. What is the benefit of good DM? Interdependencies are managed, with firewalls separating aspects that need to vary independently. Fewer Trailers Slow the rot More Flexible Less fragile, the bugs are boxed in Easier to reuse Easier to make the right change

108. First Version All designs start well The program is an overnight success! How could it be more simple, elegant, and maintainable? void copy(void) { int ch; while( (ch=ReadKeyboard()) != EOF) WritePrinter(ch); }

110. Second Version Design bool GtapeReader = false; // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) WritePrinter(ch); }

111. Third Version How unexpected! Requirements changed again! bool GtapeReader = false; Bool GtapePunch = false; // remember to clear void copy(void) { int ch; while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF) GtapePunch ? WritePunch(ch) : WritePrinter(ch); } It seems that sometimes we need to write to a paper tape punch. We’ve had this problem before, and just added a flag. Looks like it should work again.

112. Example of a Good Design First and only version. void Copy() { int c; while( (c=getchar()) != EOF) putchar(c); } But wait! Aren’t we supposed to be learning OO design? This isn’t OO is it?

114. Rephrased in OO interface Reader { char read(); } interface Writer { void write(char c); } public class Copy { Copy(Reader r, Writer w) { itsReader = r; itsWriter = w; } public void copy() { int c; while( (c==itsReader.read()) != EOF ) itsWriter.write(c); } private Reader itsReader; private Writer itsWriter; }

120. Procedural (open) version enum ShapeType {circle, square}; struct Shape {enum ShapeType itsType;}; struct Circle { enum ShapeType itsType; double itsRadius; Point itsCenter; }; void DrawCircle(struct Circle*) struct Square { enum ShapeType itsType; double itsSide; Point itsTopLeft; }; void DrawSquare(struct Square*) #include <Shape.h> #include <Circle.h> #include <Square.h> typedef struct Shape* ShapePtr; void DrawAllShapes(ShapePtr list[], int n) { int i; for( i=0; i< n, i++ ) { ShapePtr s = list[i]; switch ( s->itsType ) { case square: DrawSquare((struct Square*)s); break; case circle: DrawCircle((struct Circle*)s); break; } } } Shape.h Circle.h Square.h DrawAllShapes.c

122. A Closed Implementation Class Shape { public: virtual void Draw() const =0; }; #include <Shape.h> void DrawAllShapes(Shape* list[],int n) { for(int i=0; i< n; i++) list[i]->draw(); } Shape.h DrawAllShapes.cpp Circle.h Square.h Class Square: public Shape { public: virtual void Draw() const; }; Class Circle: public Shape { public: virtual void Draw() const; };

125. Square/Rectangle A square is-a rectangle, right? So lets consider Square as a subtype of Rectangle. void Square::SetWidth(double w) { width = w; height = w; } void Square::SetHeight(double h) { width = h; height = h; } We can make it work: Uh, oh. This doesn’t quite seem to fit

131. Dependency Inversion Principle Details should depend on abstractions. Abstractions should not depend on details. V.

133. Procedural vs. OO Architecture Procedural Architecture Object-Oriented Architecture

134. DIP Applied on Example Copy Reader Writer Keyboard Reader Printer Writer class Reader { public: virtual int read()=0; }; class Writer { public: virtual void write(int)=0; }; void Copy(Reader& r, Writer& w){ int c; while((c = r.read()) != EOF) w.write(c); } Disk Writer

136. Interface Pollution by “collection” Distinct clients of our class have distinct interface needs.

137. A Segregated Example

138. ATM UI Example

139. A Segregated ATM UI Example

140. Logger Example