Coupling: Difference between revisions

Latest revision as of 08:43, 13 October 2024

manufactured concern to protect developers (or appease managers) who are afraid of refactoring and would rather maintain a pile of hacks
- seems particularly prevalent in the web ecosystem but also leaking outside of it
so-called coupling is actually a good thing, as everything can automatically benefit from improvements in the shared code
- we do not need to predict the future if it's easy to make changes to the codebase, which should be the case anyway
when shared code does not support your use case, change it so that it does
- unit tests should be in place to ensure existing use cases remain supported
- tangled conditional logic, as ever, can be avoided via polymorphism
there is always the option of inlining shared code that isn't fit for purpose

@@ Line 1: / Line 1: @@
 * manufactured concern to protect developers (or appease managers) who are afraid of refactoring and would rather maintain a pile of hacks
 ** seems particularly prevalent in the web ecosystem but also leaking outside of it
-* coupling is actually a good thing, as everything can automatically benefit from improvements in the shared code
+* so-called coupling is actually a good thing, as everything can automatically benefit from improvements in the shared code
 ** we do not need to predict the future if it's easy to make changes to the codebase, which should be the case anyway
 * when shared code does not support your use case, change it so that it does