1. Design Principles
iwongu at gmail dot com

2. What is Object-Oriented design?

3. Dependency Management

4. First Version All designs start well
void copy() { int ch; while ( (ch = ReadKeyboard()) != EOF) WritePrinter(ch); }

5. Second Version Oh, no! Nobody said the requirements might change!
bool gTapeReader = false; // remember to reset this flag
void copy() {
int ch;
while ( (ch = gTapeReader ? ReadTape() : ReadKeyboard()) != EOF)
WritePrinter(ch); }

6. Third Version How unexpected! Requirements changed again!
bool gTapeReader = false; bool gTapePunch = false; // remember to reset these flags void copy() { int ch; while ( (ch = gTapeReader ? ReadTape() : ReadKeyboard()) != EOF) gTapePunch ? WritePunch(ch) : WritePrinter(ch); }

7. Wonderful
Use
Change
Rot
Smell
Redesign

8. Design Smells The odors of rotting software
It’s rigid.
It’s fragile.
It’s not reusable.

9. Rigidity Rigidity is the inability to be changed
The impact of a change cannot be predicted.
If not predicted, it can not be estimated.
Time and cost can not be qualified.
Managers become reluctant to authorize change.

10. Fragility Software changes seem to exhibit non-local effects.
A single change requires a cascade of subsequent changes.
New errors appear in areas that seem unconnected to the changed areas
Quality is unpredictable.
The development team loses credibility.

11. Immobility It's not reusable.
Desirable parts of the design are dependent on undesirable parts.
The work and risk of extracting the desirable part may exceed the cost of redeveloping from scratch.

12. Example of a good design First and only version!
void copy(FILE* in, FILE* out) {
int ch;
while ( (ch = fgetc(in)) != EOF)
fputc (ch, out); }
But, wait! Aren't we supposed to be learning OO design? This isn't OO, is it?

13. … Is it? It's a small program based on abstraction!
FILE is an abstraction.
It represented some kind of byte stream.
It has many variations.
It has methods.
The methods are dynamically bound.
FILE is a class, just implemented differently.

14. Rephrased in OO First and only version!
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); Reader itsReader; Writer itsWriter;

15. CHANGE

16. “CHANGE” The one constant in software development

17. “Belady and Lehman’s Laws” Software will continually change
“Belady and Lehman’s Laws” Software will continually change. Software will become increasingly unstructured as it is changed.

18. Ities of Software Quality
Reliability
Efficiency
Readability
Understandability
Modifiability, Maintainability
Testability
Portability

19. UML Unified Modeling Language

20. Class

21. Association

22. Generalization

23. Dependency

24. UML Class Diagram shows the relationships of Classes.
Dependency
Association
Aggregation
Composition
Generalization
Realization

25. Design Principles

26. Design Principles SRP Single Responsibility Principle
OCP Open Closed Principle
LSP Liskov Substitution Principle
DIP Dependency Inversion Principle
ISP Interface Segregation Principle

27. SRP Single Responsibility Principle

28. There should never be more than one reason for a class to change.

29. In the context of the SRP, a responsibility means "a reason for change

30. Each responsibility is an axis of change.

31. Orthogonal
class Y
class X
No need to change

32. Non-Orthogonal
class Y
class X
Need to change

33. SRP Violation

34. SRP

35. But, it’s not easy to see SRP.

36. But, it’s not easy to see SRP.

37. Question?

38. OCP Open-Closed Principle

39. Software entities should be open for extension but closed for modification.

40. But how?

41. Abstraction is the key.

42. enum ShapeType { circle, square }; struct Shape { ShapeType itsType; }; struct Circle { ShapeType itsType; }; struct Square { ShapeType itsType; }; void DrawAllShapes(Shape* list[], int n) { for (int i = 0; i < n; ++i) { Shape* s = list[i]; switch (s->itsType) { case square: DrawSquare((Square*)s); break; case circle: DrawCircle((Circle*)s); break; } } }

43. struct Shape { virtual void Draw() const = 0; }; struct Square : Shape { virtual void Draw() const; }; struct Circle : Shape { virtual void Draw() const; }; void DrawAllShapes(Shape* list[], int n) { for (int i = 0; i < n; ++i) { Shape* s = list[i]; s->Draw(); } }

44. OCP Violation If new shapes are needed,

45. OCP Violation

46. OCP If new shapes are needed,

47. OCP

48. But, OCP is not just inheritance.

49. OCP is the root motivation behind many of the heuristics and conventions. For example,

50. Make All Member Variables Private.

51. No Global Variables – Ever.

52. RTTI is Dangerous.

53. Question?

54. LSP Liskov Substitution Principle

55. Subtypes should be substitutable for their base types.

56. Rectangle

57. Square IS-A rectangle.

58. Square

59. void Square::set_width(double w) {. Rectangle::set_width(w);
void Square::set_width(double w) { Rectangle::set_width(w); Rectangle::set_height(w); } void Square::set_height(double h) { Rectangle::set_width(h); Rectangle::set_height(h); }

60. double g(Rectangle& r) { r.set_width(5); r.set_height(4); assert(r.area() == 20); }

61. Square IS-A rectangle. But, Square is NOT substitutable for rectangle.

62. Violating the LSP often results in the use of Run-Time Type Information (RTTI).

63. double g(Rectangle& r) {. r. set_width(5);. r. set_height(4);
double g(Rectangle& r) { r.set_width(5); r.set_height(4); if (dynamic_cast<Square*>(&r) != 0) { assert(r.area() == 16); } else { assert(r.area() == 20); } }

64. It’s also a violation of OCP.

65. Using DBC, LSP means,

66. DBC? Design By Contract. Precondition Postcondition Invariant

67. A routine redeclaration may only replace the original precondition by one equal or weaker, and the original postcondition by one equal or stronger.

68. Base
Derived

69. The postcondition of Square::set_width() is weaker than the postcondition of Rectangle::set_width().

70. Rectangle
Square

71. Question?

72. DIP Dependency Inversion Principle

73. a. High-level modules should not depend on low-level modules
a. High-level modules should not depend on low-level modules. Both should depend on abstractios.

74. b. Abstractions should not depend on details
b. Abstractions should not depend on details. Details should depend on abstractions.

75. Structured Design

76. Dependency Inversion

77. Dependency Inversion

78. Depend on abstractions.

79. No variable should hold a pointer or reference to a concrete class
No variable should hold a pointer or reference to a concrete class. No class should derive from a concrete class. No method should override an implemented method of any of its base classes.

80. But, it’s impossible. For example, someone has to create the instances of the concrete class, and whatever module does that will depend on them.

81. And, it might not be a problem to depend on concrete but non-volitile classes.

82. DIP Violation

83. DIP

84. Question?

85. ISP Interface Segregation Principle

86. Door And, we need a timed door.

87. Timer

88. The first solution What are problems?

89. Not all varieties of Door need timing. Violation of LSP.

90. The interface of Door has been polluted with a method that it does not require. Fat Interface.

91. ISP Interface Segregation Principle Clients should not be forced to depend on methods that they do not use.

92. Multiple inheritance

93. Delegation

94. Question?

95. References

97. http://objectmentor. com/ http://objectmentor
→ Robert C. Martin