> Deciding whether and how to couple two pieces of code is a fine art in software development, and as such, it's a point of never-ending tension as systems are

> Deciding whether and how to couple two pieces of code is a fine art in software development, and as such, it's a point of never-ending tension as systems are designed and redesigned. To expand on the theory here: Specifically, this is a tension between coupling and cohesion. Coupling means dependencies between modules; cohesion means dependencies within a module. High cohesion reflects a module’s focus on just one responsibility, which really does need everything in the module to get done. > > Woah, increased coupling is always a bad thing, right!? Increased coupling is always a bad thing – all else being equal. But if increased coupling results in increased cohesion too, it may be worth it. Higher cohesion is better, and lower coupling is better. > All use is coupling. All reuse is additional coupling. A system with minimal coupling is a system without any abstraction or invocation. How do you know you don’t want such a system? Because it has very low cohesion. The duplicated parts all over your codebase will only be used by a few parts of their modules, rather than most of their modules. Note that cohesion is measured relative to the size of the module, not as an absolute count of connections. If you pointlessly extract the full body of a method to another differently-named method, you have increased the number of intra-module connections. But you have decreased cohesion, because the module is now bigger, yet your new method is only called once within the whole module.