Beyond coupling and cohesion: strategies for un-fucking yourself | Hacker News Reader

Beyond coupling and cohesion: strategies for un-fucking yourself

jesseduffield.com

108 pointsgenericlemon2412 comments

I 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.

my 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?

> 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.

This 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.

It'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.

what 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.

How 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"?

Coupling, Cohesion, and Encapsulation. That's the way I learned it. The Dryness or single responsibility principle I think boils down to encapsulation.

I think DRY is the fundamental axiom of reasonable coding. Everything else naturally derives if you religiously follow it.

My only issue is it does not play so well with microservices.

Or tests. I prefer my tests DAMPer.

it is about microservice/DDD domain/DDD boundedcontext/DDD aggregates

This 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-us...

Reply on news.ycombinator.com