Conclusion – Architectural Principles
The core idea is to depend on abstractions. Interfaces are pure contracts, which makes them more flexible than abstract classes. Abstract classes are still helpful, and we explore ways to leverage them in the book.Depending on implementations (classes) creates tight coupling between classes, which leads to a system that can be harder to maintain. The cohesion between your dependencies is essential in whether the coupling will help or hurt you in the long run. Don’t discard concrete types everywhere mindlessly.
In this chapter, we covered many architectural principles. We began by exploring DRY, KISS, and separation of concerns principles before learning about the SOLID principles and their importance in modern software engineering. By following those principles, you should be able to build better, more maintainable software.As we also covered, principles are only principles, not laws. You must always be careful not to abuse them so they remain helpful instead of harmful. The context is always essential; internal tools and critical business applications require different levels of tinkering. The key takeaways from this chapter are:
- Don’t over-engineer your solutions (KISS).
- Encapsulate and reuse business logic (DRY).
- Organize elements around concerns and responsibilities (SoC/SRP).
- Aim at composability (OCP).
- Support backward compatibility (LSP).
- Write granular interfaces/contracts (ISP).
- Depend on abstractions and invert the dependency flow (DIP).