![]() Unfortunately, I've seen many people follow the incorrect understanding of the SRP with blind faith. From another angle, I see the SRP as a natural consequence of DDD principles: it's unsafe to have a model that is shared across bounded contexts. While the SRP is true, it's sometimes hard to apply proactively as who (or which group) is the "ultimate owner" of something can be squishy and take time to become clear, especially if you're building a system from scratch with many stakeholders. It was the exact thing that Uncle Bob was talking about. And guess what? One object belonged to Operations and one belonged to (you guessed it) Finance. It really drove me crazy! Several times I tried to treat them uniformly with the same code and it inevitably failed. The objects were one-to-one with a lot of apparent duplication. There was another version of that object that was used for paying the drivers. It was operational in nature - you'd assign a driver, arrival and departure times for shipping locations, etc. I worked on a Transportation Management System and we had an object that represented truck movements. While I don't need to apply it everyday, the SRP does align with my experience. This is very different than the way I have seen most people apply the SRP. The hours calculation cannot be shared: that piece of code should have a Finance version and an Operations version, despite the fact that that violates our DRY and cohesion sensibilities. Calculating hours is simple math that everyone should agree on, right? One executive requests a change to that code and it breaks the other's business rule. ![]() Uncle Bob uses an example (in writing and talks) where the CFO and COO both depend on the code that calculates employee hours. If that isn't true you have to break it up. The principle actually means that the code in a given module has to be owned by one and only one ultimate business owner (or functional unit). The SRP is a license to sometimes forgive yourself for what feels like breaking cohesion. We know this: a function should have a single, well, function. Have you ever held your nose while naming a function something like "ImportData AndLoadIntoDatabase". There's a different rule of thumb around that: a function should only do one thing. So the module should only do one thing, right? No. And then the name seems to suggest that the module should have a "single responsibility". The principle has often been framed as "each software module should have one and only one reason to change". When coupled with blind faith this can engender overly simplistic thinking and design mistakes. Unfortunately, this particular principle is often misunderstood. The Single Responsibility Principle (SRP) is the first of the SOLID design principles that have been highly influential in software engineering since they were introduced by Robert Martin ("Uncle Bob") in 2000.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |