To me the modem example above always seemed like a case for the interface segregation principle rather than SRP, but that's besides the point.
In the part you called out regarding the Rectangle
, I think you're just misinterpreting it. Martin is using the Rectangle as an example of a shared library. If the GraphicalApplication
requires a new method or change in semantics in the Rectangle
class, then that affects the ComputationalGeometryApplication
since they both "link" to the Rectangle
library. He's saying it violates SRP because it is responsible for defining rendering bounds and also an algebraic concept. Imagine if the GraphicalApplication
changed from DirectX to OpenGL where the y-coordinate is inverted. You may want to change some things around on the Rectangle
to facilitate this, but you're then potentially causing changes in ComputationalGeometryApplication
.
In my work, I try to follow the SOLID principles and TDD, and I've found that SRP makes writing tests for classes simple and also keeps the classes focused. Classes that follow SRP are typically very small, and this reduces complexity both in code and dependencies. When stubbing out classes, I try to make sure a class is either "doing one thing", or "coordinating two (or more) things". This keeps them focused and makes their reasons for change only dependent on the one thing they do, which to me is the point of SRP.