OOD - Object orientated design

This is my slides that I used within the last backend developers meetup - https://www.meetup.com/Cape-Town-Backend-Developers/

This presentation covers sections from Sandi Metz's - Practical Object-Oriented Design in ruby. This presentation comes with a small workshop that focuses on refactoring some poorly written legacy code.

We start by looking at the dependencies and by managing them correctly it will cascade a series of changes that will eventually change the way we interact with the code and the way the code interacts with the system.

1. OO D

2. We want to do our best work.

3. We want our work to have meaning

4. We want to have fun along the way

5. Two major themes being Design and Messages over objects 

6. Design 

7. Failures of OOD might look like failures of coding technique but they are actually failures of perspective . 

8.  Source: Pablo Picasso - Buffalo Art

9. Design is not an assembly line where similarly trained workers construct identical widgets; it’s a studio where like-minded artists sculpt custom applications. Design is thus an art, the art of arranging code. 

10. How does Design affect us? 

11. 

12.  Per spec tive.

13. Unfortunately, something will change. 

14. The customers didn’t know what they wanted. 

15.  They didn’t say what they meant.

16. You didn’t understand their needs. 

17. You’ve learned how to do something better. 

18. Even applications that are perfect in every way are not stable. 

19. The application was a huge success, now everyone wants more. 

20. Change is unavoidable . It is ubiquitous , omnipresent , and inevitable . 

21.  Source: http://more-sky.com/

22. Dependency 

23. Object-oriented design is about managing dependencies. 

24.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

25.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

26.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

27.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

28.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

29. Your goal is to model your application, using classes, such that it does what it is supposed to do right now and is also easy to change later . 

30.  1 class Gear 2 attr_reader :chainring , :cog , :rim , :tire 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @rim = rim 7 @tire = tire 8 end 9 10 def gear_inches 11 ratio * Wheel .new( rim , tire ). diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

31.  Dependency injection

32.  1 class Gear 2 attr_reader :chainring , :cog , :wheel 3 def initialize( chainring , cog , wheel ) 4 @chainring = chainring 5 @cog = cog 6 @wheel = wheel 8 end 9 10 def gear_inches 11 ratio * wheel. diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , Wheel.new( 26 , 1.5 )). gear_inches

33.  Dependency aversion

34.  1 class Gear 2 attr_reader :chainring , :cog , :wheel 3 def initialize( chainring , cog , rim , tire ) 4 @chainring = chainring 5 @cog = cog 6 @wheel = Wheel.new( rim , tire ) 8 end 9 10 def gear_inches 11 ratio * wheel. diameter 12 end 13 # ... 14 end 15 16 Gear .new( 52 , 11 , 26 , 1.5 ). gear_inches

35.  Order Dependency

36. 1 class Gear 2 attr_reader :chainring , :cog , :tire 3 def initialize( args ) 4 @chainring = args[: chainring ] 5 @cog = args[: cog ] 6 @wheel = args[: wheel ] 7 end 8 9 def gear_inches 10 ratio * wheel.diameter 11 end 12 # ... 13 end 14 15 Gear .new( 16 :cog => 11 , 17 :chainring => 52 , 18 :wheel => Wheel .new( 26 , 1.5 )). gear_inches

37. Is your code too coupled to your tests? 

38. Tools for design 

39. S ingle Responsibility, O pen-Closed, L iskov Substitution, I nterface Segregation, and D ependency Inversion. DRY (Don’t Repeat Yourself) Law of Demeter ( LoD )  Principles

40. The so-called Gang of Four ( Gof ) Skinny models - Service objects  Patterns

41. Design is more the art of preserving changeability than it is the act of achieving perfection 

42.  Virtual World

43. You will never know less than you know right now. 

44. Keep your code TRUE 

45. Transparent The consequences of change should be obvious in the code that is changing and in distant code that relies upon it Reasonable The cost of any change should be proportional to the benefits the change achieves Usable Existing code should be usable in new and unexpected contexts Exemplary The code itself should encourage those who change it to perpetuate these qualities 

46. Challenge - https://gitlab.com/LegendaryRob/WizSys 

47. Example 

48. 

49. Sandi Metz “Sandi is the author of Practical Object-Oriented Design in Ruby, and most recently 99 bottles. She has thirty years of experience working on large object-oriented applications. She’s spoken about programming, object-oriented design and refactoring at numerous conferences including Agile Alliance Technical Conference, Craft Conf, Øredev, RailsConf, and RubyConf . She believes in simple code and straightforward explanations, and is the proud recipient of a Ruby Hero award for her contribution to the Ruby community. She prefers working software, practical solutions and lengthy bicycle trips (not necessarily in that order). Find out more about Sandi at sandimetz.com . 

50. Why this book? 

51. Design What are design principles What are design Patterns When should I design? How does one design ? OO vs FP Single Responsibility What belongs to a class? How do I organize my code? Why does SR matter? Code Introspection How to write change tolerant code Data vs Behavior When to design and when to replicate? Dependencies What is coupling? is it good or bad? How to inject Dependencies How to isolate dependencies Seeing hidden dependencies Which direction should we interact with them Interfaces Public vs Private Responsibilities of interfaces Intention Context independence Messages over objects Developing trust LoD What is this? why is it important What happens if I break the law? How to avoid violations Duck Typing Understanding the quacks Trusting ducks by choosing them wisely Finding hidden ducks Documentation Sharing Code Static vs Dynamic Typing Inheritance Where to use it? Drawing up relationships What happens when you misapply inheritance Creating abstract classes Template Method Pattern Superclasses and Subclasses