This document discusses several software design principles and patterns including SOLID principles, POLA, Demeter Law, and the Dependency Inversion Principle. It provides examples of applying these principles through code snippets and descriptions of refactoring classes to better adhere to principles like the Single Responsibility Principle, Open/Closed Principle, Interface Segregation Principle, and Liskov Substitution Principle. The document also demonstrates applying strategies, factories, dependency injection, and the Demeter Law to improve code design, testability, and adherence to object-oriented design best practices.

1. Datascope Systems Ltd.
How to write meaningful code

2. Bullet Points
 SOLID
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Inversion Of control
• Dependency Inversion Principle
 POLA
 Demeter Law
 Lowering Principle
 Live project example

3. Single Responsibility
principle
 The class has only one reason to change!
 Repository – is that a good example? What if
persistence mechanism for saving/retrieving business entities will be
changed separately? CQRS!
 Facade pattern for interacting with printing
subsystem.

4. RFID Facade example
Class has more than 1 responsibility, but only one reason to change.

5. Open-Closed
principle

6. Open-Closed
principle
 Modules should be open for extension but
closed to modification

7. Barbara-Liskov substitution
principle
x(O) = y(O) if Y is type of T,
and T is derived from X a subtype of X

8. Interface Segregation
Principle

9. Interface Segregation
Principle
Let’s imagine we have an interface which is pretty
much the same as a sub-repository

10. This is how saving/loading supposed to look like
And Boooooom, at some point business requires only
read-only settings
Interface Segregation
Principle

11. Load probably will be similarly to that then …
And start from here we have breach ISP.
Client should not depend on any method he is not using
Interface Segregation
Principle

12. Solution: split into two interfaces
Interface Segregation
Principle

13. Dependency Inversion
Principle

14. Dependency Inversion
Principle
 Example of inversion of control in DB is a
many to many relation. Order has no idea of
OrderDetails existence. As long as you have
a magic word
 1) using i.e C#
 2) import i.e. Java
 3) include i.e C,C++
You have an arrow pointing from you (you are
depend on smth…)

15. Examples
Time to go Real…

16. Let’s be interactive

17. DeliveryCollectionHelper vs
POLA and SRP
ФабричноЛоггеровыйКартинкоДоставочноСервисныйХелпер

18. Factory OR DI?
ЗависимостиИнжектируемаяСинглтоноФабрика

19. Let’s apply some refactoring
Get rid of unnecessary dependencies
and apply SRP. Lowering Law, Internal Coupling,
Descriptors and Views (Logical diff), Refactoring stages

20. OCP
Unnecessary coupling
(Class contains two
services), horizontal
dependencies, try to avoid
that

21. Strategy and Factory

22. Strategy and Factory

23. Strategy is ready, but still something
is wrong??? Proper Factory

24. Usage of Factory and Strategies example

25. Test is pretty damn simple

26. What`s wrong here?
Class usage example:
Class definition (object will goes down to service layer):

27. Demeter law in action
• Each unit should have only limited knowledge about other units:
only units "closely" related to the current unit.
• Each unit should only talk to its friends; don't talk to strangers.
• Only talk to your immediate friends.

28. Demeter law in action

29. What about up/down casting through
explicit operator? Hide SP’s - Sort of ACL

30. Right way of doing it
(this is service layer)

31. Testability problem.
Action chain solution

32. Action chain usage

33. ISP in action

34. ISP in action

35. DI in action

36. DI in action (diff between DIP and
Dependency Injection)

37. DI in action (more complicated example)
What if you need sort of magnet objects like reports,
user roles, email generators etc.
So, how to invert arrows ?
How to get rid of using, import etc in target class

38. DI in action (report example)
Dependency diagram you want to achieve:

39. DI in action (report example)
Reports side effect
(two reports 99% equals)
This is how it looks like in practice:

40. Report application layer

41. Report Collector in action

42. My LSP mistake in Quilt project

43. Software Development is amazing!