4 ms·
Beyond coupling and cohesion: strategies for un-fucking yourself
- haskellandchill 5y agoThis is on the right track but came out very light on meaningful impact. See David Parnas to add more substance: https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/ https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us...
- optymizer 5y agoIt's an easily digestable resource with clear examples. I'd forward it to our junior engineers. Something irked me about this sentence though: > I contend that these three axes: colocation, domain interdependence, and practical interdependence, form a basis that covers Coupling, Cohesion, DRYness, and the Wrong Abstraction, as well as some other things too. Seeing as the author is mainly rehashing themes from the GoF book, albeit with more modern examples (e.g microservices and npm dependencies), I would maybe phrase that a bit more humbly. To me, Wrong Abstraction is just the Single Responsibility Principle stated differently (which the author doesn't mention - not even as Separation of Concerns). _I contend_ that one could derive all other rules and patterns from this one principle.
- iovrthoughtthis 5y agowhat do you think of "code that changes together, stays together" for explaining the SRP? i've found minimising shotgun changes to bey favourite and most productive guiding light when refactoring.
- cloogshicer 5y agoI think this is a very well written article with great examples. However, I would give the same criticism as I would to the SRP (Single Responsibility Principle): What exactly is a "reason to change"? In my experience, it is rarely as clear as in the examples that were given. This vagueness of the SRP has always bothered me. In my opinion, this problem invalidates (or at least weakens) the entire SOLID concept and many of the Gang of Four patterns with it.
- iovrthoughtthis 5y agomy understanding is that a "reason to change" is entirely context dependent, so difficult to make concrete. what are you seeking to understand as a result of knowing precisely what a "reasons to change" is?
- cloogshicer 5y ago> my understanding is that a "reason to change" is entirely context dependent, so difficult to make concrete. Agreed. The problem is that the SRP mandates that you make decisions based on this vaguely defined concept.
- mrloba 5y agoThis is is the crux. It's possible to justify any and all designs using the single responsibility principle / separation of concerns. I've seen plenty of bad designs rationalized this way. Answering your question (or "what is _one_ thing?") is often called an art, and seems to be learned through experience. Though I do wonder if it's possible to teach as well. So far in this industry we teach it using rules of thumb and "principles", but it doesn't seem to work very well.
- deleted 5y ago[deleted]
- alttab 5y agoCoupling, Cohesion, and Encapsulation. That's the way I learned it. The Dryness or single responsibility principle I think boils down to encapsulation.
- danuker 5y agoHow do you tell whether a dependence relation comes from the domain, or exclusively practical (unintentional)? Is it as simple as "whether the use cases imply the dependence"? How does this relate to "reasons to change"?
- banq 5y agoit is about microservice/DDD domain/DDD boundedcontext/DDD aggregates