Reviewing Clean Architecture - SOLID

Whenever I implement a service, I consider how I can construct those service to be more efficient. Getting the code complex, it is more important to decide the struct of the software. We should reuse the codes involved in each as a module. And it should be easy to add a feature in that software.

But, many developer suffer what make those things difficult. In my case, when a service get a little complicated, it become difficult to read my code even I writing. So I wondered how can I clean up those things in my code.

So I read a book, Clean Architecture by Rovert.C Martin. I will make several reviews about this book.

SOLID

SOLID is a acronym about Object Oriented Programming. That refers what method is recommended to link each class and separate boundary of a class from others. Here is the summary.

• SRP(The Single Responsibility Principle)

  A class should have one, and only one, reason to change.

• OCP(The Open-closed Principle)

  You should be able to extend a classes behavior, without modifying it

• LSP(The Liskov Substitution Principle)

  Derived Classes must be substitutable for their base classes.

• ISP(The Interface Segregation Principle)

  Make fine grained interfaces that are client specific.

• DIP(The Dependency Inversion Principle)

  Depend on abstractions, not on concretions.

Notice that the SOLID is not only about OOD, but about Archtiecture and extension of OOD.

SRP

SRP is involved in modifying code. It's saying that if the class should be modified, that reason should be one. 'Reason' could be a little ambiguous. Think the reason as a entites involved in the class.

This book introduce a salary application using by several department of a company. If the class has all methods for them, and a method is involved in other different methods using each department. If a department request edit the logic of the method, and developer modify it without acknowledging ohter departments. It could be make some issue for other departments.

I think SRP is a principle for the boundry of the class's role.

OCP

OCP is also involved in modifying code and extension. I want to emphasize Extension. If there is a request for adding feature in software, how much your code be modified? This book says, 'ideally 0(zero)'.

So, OCP is literally Open-closed Principle. It should be open to extend some feature your software, but close to modifying persisting code. It result in that the software can be more free to extend, but not be affected the software by those processes.

LSP

I think LSP is saying about Reusing. The books is express LSP is the guide to using interface and introduce violation case LSP.

Application API for mediating the taxi driver and clients, and a taxi company miss api guide but the company is very powerful in this market. So developers for this application decide to make a exception code for this case. It makes the code more complex and complicated. LSP is preventing the software from this.

Actually, I need a help for understanding this LSP, so I referenced a blog. That blog says LSP is like a Polymorphism. Polymorphism is also involved in inheritance. The class which inherit a parent-class or a interface should implement specfication of super class. LSP is accepted as same or extended version of the Polymorphism.

ISP

ISP suggest that the code not using the fraction of module should not depend on that module. If that module's feature which is not relevant with software code is modified, the software should be recompiled.

So, ISP says the interface should be segregated by the user(code) using method in interface. The interface don't have to those all method. Each code is just dependent on Interface. But it doesn't matter each interface implementation integrate one class.

To be simple, think of transition dependency. Transition Dependency means that if A module is dependent on B module and B module is dependent on C module, so A module is dependent on C module. But if some feature of C is not relevent on A's feature, the dependency is just bully. So C just take away the features, or A should find other module.

DIP

DIP says, high-level policy implementing code should not depend on low-level specification implementing code. Because low-level implementing code is volatile. And, this book tell that the source code dependency should depend on abstract, not specification. It can make the service more flexible.

But in my experience, if that code for business logic can be regarded as a High-level policy implementing code, it become more volatile than low-level specification implementing code. I try to take DIP at other point. I guess that the hint will be in 'volatile'. Anyone agree that something that will be modified at several times can't be reliable. Maybe what the DIP say is that point.

Interestingly, the book introcude Abstraction Factory. To keep DIP, the software core class, Application, must not depend on some volatile class like Service. But the instance of Service class should be made to run the software. So application use factory pattern for this reason. Application just call method to make service instance, and using that instance through Service Interface. Application don't have to get direct dependency on service code.

So, The book says. Source Code Dependency is inversed from control of flow. That is why we call this case, Dependency Inversion.

Conclusion

As a user of Javascript, I have thought I am far from Object Oriented Programming. But already until several years ago, Javascript have adopted Class syntax, and many people have moved to using Typescript. Even without those reason, SOLID is important to make software concrete and well-structured. I plan to apply those principles in my projects.

Reference

• Principles Of OOD
• Inpa Blog: 완벽하게 이해하는 LSP (리스코프 치환 원칙)
• Clean Architecture