A few days ago I was debating some architectural changes with one of the developers in the team Im currently working in. I had to make it apparent to him what values it would give to our project if we adheared to the single Responsibility Principle.
After giving the theory behind the principle ago we hadn’t really progressed. However he gave me an idea that made it possible to convey the importance of the stated principle.
Imaging we have a class that hold the outside temperature and that same class can communicate via radio with the nearest weather station.
This class is used in an observer pattern, so some where in our application other parts will be updated (I.e the screen reflects the latest changes in temperature)
Our class has three states
valueAccepted
communicating
idle
valueAccepted is set whenever we get a new temperature reading and reverted to idle and the temperature reading is invalidated by the first read thereafter.
communicating is the state when we are communicating with the weather station.
After testing the first pilot of the code it’s realized that everything works 100% as expected and every one is happy.
So far so good but the class has at least two reasons to change. The communication protocol with the weather station changes or the temperature functionality changes.
To see why this might be a problem let’s change the communicatio protocol slightly. The only change is that every time we sent a command we need to accept a value. This causes one of the developers in our team to sent the object into valueAccepted state.
He thereafter tests that the radio communicatio works again and since the only change had to do with the radio funtionality no one thinks of testing the temperature reading before the new versio is released.
Shortly after it’s realized that the temperature readings are invalid during radio communication.
Had the single responsibility principle not been violated the radio communication would never have been able to alter the temperature flow.
Failing fast to learn a lot 