Design Principles

1. Design Principles iwongu at gmail dot com

2. What is Object-Oriented design?

3. Dependency Management

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

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

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

8. Design SmellsThe odors of rotting software • It’s rigid. • It’s fragile. • It’s not reusable.

9. RigidityRigidity 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. FragilitySoftware 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. ImmobilityIt'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 designFirst and only version! void copy(FILE* in, FILE* out) { intch; 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 OOFirst 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. Software will become increasingly unstructured as it is changed.

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

19. UMLUnified 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. SRPSingle 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. OCPOpen-Closed Principle

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

40. But how?

41. Abstraction is the key.

42. enumShapeType { circle, square }; struct Shape { ShapeTypeitsType; }; struct Circle { ShapeTypeitsType; }; struct Square { ShapeTypeitsType; }; void DrawAllShapes(Shape* list[], int n) { for (inti = 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 (inti = 0; i < n; ++i) { Shape* s = list[i]; s->Draw(); }}

44. OCP ViolationIf 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 motivationbehind many of the heuristics and conventions.For example,

50. Make All Member Variables Private.