This document discusses object-oriented design principles. It emphasizes that encapsulation, polymorphism, and inheritance are key features of OO, but inheritance increases coupling. Composition and delegation are better alternatives to reduce coupling. Test-driven development helps ensure good design by providing feedback. Dependency injection and inversion reduce dependencies and coupling. The actor model is also recommended, where each actor has a single responsibility. Overall, the document stresses designing code to be readable, with low duplication and dependencies.

1. OO DESIGN
by Oleksii Fedorov

2. OBJECT ORIENTED PROGRAMMING

3. Most notable features:
Encapsulation (data kept with behaviour and hidden from
clients)
Inheritance (subclassing, inheriting all behaviour/data,
even private/protected behaviour/data)
Polymorphism (ability to substitute instances of one class
with instances of others)

4. HOW IMPORTANT THESE FEATURES ARE FOR
OO DESIGN?
Imagine, that given 100 points you want to distribute them
between these 3 features, and each number will represent
an importance of corresponding feature.

5. Encapsulation Polymorphism Inheritance
80 40 -20
Warning: this is my personal opinion

6. 80 + 40 - 20 = 100 :)

7. INHERITANCE INCREASES COUPLING
Subclass usually depends on some data or/and behaviour of
its superclass. Even worse: usually this is not public
behaviour/data.

8. BUT HOW DOES ONE GO WITHOUT
INHERITANCE?

9. COMPOSITION AND DELEGATION

10. COUPLING

11. WHY COUPLING IS BAD?

12. Imagine you need to change behaviour of class X.
You will have to change any other piece of code base, that
directly depends on this behaviour of class X.
More coupling you have, more changes will have to take
place, and probably, in totally unrelated parts of codebase.

13. Exponentially increases time required for change
Invites bugs

14. DEPENDENCY

15. HOW DOES ONE DEAL WITH IT?

16. DEPENDENCY INVERSION AND DEPENDENCY
INJECTION

17. class Answer
def rating
RatingCalculator.new.rating_for(comments, upvotes, downvotes)
end
end

18. AND WHAT THE PROBLEM WITH THIS CODE?

19. DEPENDENCY!

20. class Answer
def initialize(rating_calculator)
@rating_calculator = rating_calculator
end
def rating
@rating_calculator.rating_for(comments, upvotes, downvotes)
end
end

21. NOW YOU CAN HAVE MULTIPLE RATING
CALCULATOR SERVICES AND A/B TEST THEM
EASILY

22. COUPLE TO ABSTRACT INTERFACES INSTEAD
OF REFERENCING FOREIGN
CLASS/MODULE/PACKAGE OF YOUR SYSTEM

23. TEST DRIVEN DEVELOPMENT

24. HOW IS IT RELATED TO OO DESIGN?

25. PROVIDES SHORT FEEDBACK LOOP ON YOUR
DESIGN

26. If you have troubles writing test - your design is wrong
If you don't like how your test look like - your design is
wrong
If you have troubles making test green - your design is
wrong

27. UNIT TESTS AND INTEGRATION TESTS

28. INTEGRATION TESTS ARE SCAM!
Very slow => bad feedback loop
Exponential count of paths to test

29. UNIT TESTS JUST DOESN'T WORK. ARE
THEY?

30. Testing in isolation = providing fake objects and/or mocks
for all your dependencies
Mocks and fake objects can make your unit test green, but in
fact the code is broken, because one of the dependencies
has changed its behaviour or even public interface

31. CUT YOUR SYSTEM AT VALUE BOUNDARIES!
Instead of method call boundaries.

32. ACTOR MODEL

33. class RatingCalculator
def rating_for(comments, upvotes, downvotes)
# .. calculate rating somehow ..
end
end

34. actor RatingCalculator
comments, upvotes, downvotes, outbox = inbox.fetch
# .. calculate rating somehow ..
outbox.send(rating)
end

35. ALMOST ALWAYS HAS EXACTLY ONE SINGLE
RESPONSIBILITY
Since it receives message on inbox and doesn't really have
much space to have multiple responsibilities (and methods)

36. EASY TO UNIT TEST WITHOUT FAKE OBJECTS
AND MOCKS

37. # creating actor, but not starting it
rating_actor = RatingCalculator.new
# dependency injection of rating actor
answer_actor = Answer.new(answer_id, rating_actor)
answer_actor.start
render_actor = Render.new(answer_actor)
render_actor.run
expect(rating_actor.inbox)
.to include([comments, upvotes, downvotes, outbox])
# fake response from rating actor
outbox.send(3.5)
expect(render_actor).to render_rating(3.5)

38. WHEN THE CODE IS DONE?

39. It works!

40. It works!
It is readable (future me will not curse me for writing this
code)

41. It works!
It is readable (future me will not curse me for writing this
code)
It has no duplication
And it is as short as possible (while maintaining all of the
above)

42. CODE COMMENTS

43. BASICALLY A CODE SMELL

44. If code needs comment:
It is not readable
It fails to communicate intent

45. TO SUM IT UP

46. Inheritance is good only in very rare cases
Coupling and dependencies are not your friends, take
them under control with dependency inversion &
injection
TDD as a shortest feedback cycle for your OO design
Write code in such way, that you would thank yourself for
that in the future

47. THAT IS NOT ALL THERE ABOUT OO DESIGN
I recommend reading the book "Pragmatic Programmer:
From Journeyman to Master", it is very good one and has a
lot of references to other good resources

48. THANKS
Q & A