5 ms·
This runs the risk of being reductionist to the point of useless. Is akin to the idea of "do one thing," or "single responsibility." The danger is these all f
by taeric 3y ago
This runs the risk of being reductionist to the point of useless. Is akin to the idea of "do one thing," or "single responsibility."
The danger is these all fail to grow. Or, rather, for them to work, you have to force the growth on either side.
Consider, you are using a writer to write data. How much can you write before it has to slow down? How do you signal broken data connections? How do you resume a previously stopped writer? How do you stop a writer?
Most of these do not have universal answers. But it gets worse. The main abstraction there was the symbolic byte. How do you convert your code's data to bytes? Is that stable? As in not changing.
So, you can have choke points of small interfaces to connect things. But to make that work, you have a lot to do on both sides.
- stinkbutt 3y agoits a misconception that single responsibility is about doing one thing. in fact the principle allows for a system to do many things, but the idea is that it should only serve a single actor.
- taeric 3y agoI assert it is misguided to cling to any view of these as a fundamental truth. They are modeling tools. As such, use them for their usefulness. Don't chase truths with them, at they are tools, not truths.
- stinkbutt 3y agoi agree, and its important that we understand what the tools were designed to do before we use them
- whstl 3y agoCalling it a misconception is not really fair. The "serve a single actor" is a recent revision of the principle by Uncle Bob, from a 2018 book, AFAIK. That's almost 20 years too late (if going by the sources I can find). I can't find mentions of "actors" or similar terms in Agile Software Development or Clean Code. Pretty much every pre-2018 literature says that SRP relates to modules "[having a] single reason to change", or "[not having] too many responsibilities". The examples are always fuzzy and imprecise, but in the books the principle essentially boils down to class/method size. There are no examples in Clean Code or ASD relating to this new meaning, nor mentions of "actors" or "stakeholders", and until recently there's rarely any article contradicting the original meaning of SRP. This revisionism seems to come first from backlash from part of the programming community, and also an adaptation of the more recent "one team per microservice" rule. But the damage of almost 20 years of SRP being taught the way it was in the past was already done.
- whynotmaybe 3y agoFrom Wikipedia, Uncle Bob made a book in 2017 and one in 2019. Do you know which one you're referring to? 2017. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0134494166. 2019. Clean Agile: Back to Basics. Prentice Hall. ISBN 978-0135781869.
- whstl 3y agoIt's the 2017 one, thanks for the correction.
- paulddraper 3y agoThe principal is correct: "the bigger the interface, the weaker the abstraction." But perhaps you feel there is an second implicit, prescription: "Your abstractions should be strong." And that's not necessarily true. To every thing there is a season. Excessive abstraction is astronaut architecture. --- The principal is a good one. The bigger the interface, the weaker the abstraction. That's not to say big interfaces are bad or inappropriate. It's just to say they aren't strong abstractions, so don't expect them to be.
- taeric 3y agoTotally fair. I am riffing off the idea that stronger is better. Weaker is worse. Fairly common framing, I thought But in the spirit, how is a single method "stronger?" Usable in more places, maybe? Often hides too much, such that it really can't be used everywhere. Describes more things? Well, yeah? But not in meaningful way. At this level of "abstraction," a car is indistinguishable from a bike. Certainly fair for some contexts. Not many relevant ones, though. And it is that last, that I think sticks. What is the most you can stick to an abstract set of capabilities? That will give you the most utility. It does mean the cost of implementation raises. But that is realistic?
- Makhini 3y agoIt's principle, not principal.
- yegle 3y agoThe standard solution to this problem is a so called "interface smuggling". You can implement more advanced interface types of the initial interface does not provide the required abstraction, and then do type switch at runtime and gradually switch your code to use the newer interface. The name of this technique is from https://utcc.utoronto.ca/~cks/space/blog/programming/GoInterfaceSmuggling https://utcc.utoronto.ca/~cks/space/blog/programming/GoInter...
- Too 3y agoA bit like duck typing.
- ben0x539 3y agoDoesn't that frequently run into other code that well-intentionedly wraps a value of the original interface adding new functionality but not passing through the newer interface, because it simply can't account for all interface smuggling that might be going on? Does sophisticated Go code just not use decorator types like I've run into?