When designing software applications, it is imperative that the application supports the requirements. The ability to align requirements to implementation for complex systems is not a skill that is taught in school. No single developer can have a holistic understanding of a complex system. The parts of the complex system that are not understood are ripe for requirements gaps and bugs.
The SOLID principles are simple to understand, yet surprisingly difficult to follow. The principles strive for focused, maintainable and testable objects. In contrast, code encountered in the wild frequently reveals bloated God classes. Addressing requirements through God classes is tempting because it allows the author to skip the design phase of the Software Development Life Cycle and jump right to implementation. A downside to this approach is that engineers new to the project will need to read and understand every single line of the God class before making changes. Additive changes to the God class will increase its complexity. Over time, the class will become extremely difficult to understand and maintain and will start yielding requirements gaps and bugs. If the same greenhorn engineers were presented with a codebase designed with SOLID principles in mind, they should quickly identify their desired point of change due to the single responsibility principle and have a less difficult time understanding the code.
This sample Spring Boot and Mockito-based project for a cake store was developed following SOLID principles. Without knowing how to program, one could likely locate the section of the code containing the logic for validating orders at the cake store. Since the order validation logic is co-located, this class can be linked to its corresponding story requirement in a project tracking tool like JIRA. The corresponding automated tests can be linked to the story requirement as well, ensuring basic test coverage.
Software applications designed following the SOLID principles are easily testable. Developers can verify code by creating automated unit and integration tests for the requirements. Since these automated tests generally take seconds to execute, functionality can be verified on demand. Tech-savvy stakeholders are pleased to see successful automated unit and integration test results, as they can help to gauge real-time development progress. It does not take too much effort to teach an interested stakeholder how to run unit tests.
Having requirements traceability and basic test coverage is meaningful to all parties on a software project because they aid in verifying the application. Software designed with SOLID in mind makes this traceability task easier to perform. Software designed with God classes will yield untestable and complex code that will hinder requirements traceability. Consider pursuing SOLID design for your next software project.