The SOLID Principles of OO Design
THIS IS A SAMPLE PART OF THE SOLID CHAPTER
The SOLID acronym represents some important principles of object-oriented programming and design.
It stands for:
- S - Single Responsibility Principle
- O - Open Closed Principle
- L - Liskov Substitution Principle
- I - Interface Segregation Principle
- D - Dependency Inversion Principle
This chapter examines each of these principles in term and relates them back to how they help to keep software soft.
The Single Responsibility Principle (SRP)
Any given class should do one well-defined thing, and only that one well-defined thing.
To put in another way, if a class has more than one responsibility, it will have to change whenever any one of it’s responsibilities change. If there’s more than one reason to change a class, its likely that the Single Responsibility Principle has been violated.
As an example, consider an OrderManager class that is responsible for: calculating the total order amount, debiting a credit card, and updating the order status in the database. Clearly this is a violation of SRP. Instead, a cleaner implementation could be to split out each responsibility into three separate classes: OrderTotalsCalculator, CreditCardCharger, and OrderRepository. Now each class only needs to change if it’s responsibility changes.
Why SRP?
SRP is important to keeping software soft because:
- A class that conforms to SRP only needs to be changed when the thing it’s responsible for changes
- Each class now has fewer lines of more highly-related code, so it should be easier for a developer to understand in its entirety
- More individual source code files (e.g. one for each responsible class) should result in fewer merge conflicts
- Testability is likely to be better and the related test code more highly focussed and cohesive
Without SRP there is greater fear (and potentially higher regression test costs) when changing any given part of the system.
Customer: “We want to change the way order totals are calculated.” Development Team: “No problem, give us the new business rules, we’ll write some tests then go and change the OrderCalculator, we don’t have to worry about breaking the database because that’s in a separate place”.