Datascope Systems Ltd.
How to write meaningful code
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
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.
RFID Facade example
Class has more than 1 responsibility, but only one reason to change.
Open-Closedprinciple
Open-Closedprinciple
Modules should be open for extension but closed to modification
Barbara-Liskov substitution principle
x(O) = y(O) if Y is type of T, and T is derived from X a subtype of X
Interface Segregation Principle
Interface Segregation Principle
Let’s imagine we have an interface which is pretty much the same as a sub-repository
This is how saving/loading supposed to look like
And Boooooom, at some point business requires only read-only settings
Interface Segregation Principle
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
Solution: split into two interfaces
Interface Segregation Principle
Dependency InversionPrinciple
Dependency InversionPrinciple
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…)
Examples
Time to go Real…
Let’s be interactive
DeliveryCollectionHelper vs POLA and SRP
ФабричноЛоггеровыйКартинкоДоставочноСервисныйХелпер
Factory OR DI?
ЗависимостиИнжектируемаяСинглтоноФабрика
Let’s apply some refactoringGet rid of unnecessary dependencies and apply SRP. Lowering Law, Internal Coupling,Descriptors and Views (Logical diff), Refactoring stages
OCP
Unnecessary coupling (Class contains two services), horizontal dependencies, try to avoid that
Strategy and Factory
Strategy and Factory
Strategy is ready, but still something is wrong??? Proper Factory
Usage of Factory and Strategies example
Test is pretty damn simple
What`s wrong here?
Class usage example:
Class definition (object will goes down to service layer):
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.
Demeter law in action
What about up/down casting through explicit operator? Hide SP’s - Sort of ACL
Right way of doing it (this is service layer)
Testability problem. Action chain solution
Action chain usage
ISP in action
ISP in action
DI in action
DI in action (diff between DIP andDependency Injection)
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
DI in action (report example)
Dependency diagram you want to achieve:
DI in action (report example)Reports side effect (two reports 99% equals)
This is how it looks like in practice:
Report application layer
Report Collector in action
My LSP mistake in Quilt project
Software Development is amazing!