[HN Gopher] Beyond coupling and cohesion: strategies for un-fuck...
___________________________________________________________________
Beyond coupling and cohesion: strategies for un-fucking yourself
Author : genericlemon24
Score : 69 points
Date : 2021-08-09 18:39 UTC (4 hours ago)
(HTM) web link (jesseduffield.com)
(TXT) w3m dump (jesseduffield.com)
| alttab wrote:
| Coupling, Cohesion, and Encapsulation. That's the way I learned
| it. The Dryness or single responsibility principle I think boils
| down to encapsulation.
| avip wrote:
| 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.
| danuker wrote:
| 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"?
| haskellandchill wrote:
| 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...
| cloogshicer wrote:
| 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.
| optymizer wrote:
| 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.
___________________________________________________________________
(page generated 2021-08-09 23:01 UTC)