{
  "$type": "site.standard.document",
  "canonicalUrl": "https://jacob.blog/notes/cohesion-vs-coupling",
  "path": "/notes/cohesion-vs-coupling",
  "publishedAt": "2025-12-28T00:00:00.000Z",
  "site": "at://did:plc:ckthoyuvsmkp254fyuinyzb2/site.standard.publication/3mndm6tiamb26",
  "tags": [
    "software-engineering",
    "architecture"
  ],
  "textContent": "Cohesion refers to what the class (or module) can do. Low cohesion would mean that the class does a great variety of actions - it is broad, unfocused on what it should do. High cohesion means that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.\n\nAs for coupling, it refers to how related or dependent two classes/modules are toward each other. For low coupled classes, changing something major in one class should not affect the other. High coupling would make it difficult to change and maintain your code; since classes are closely knit together, making a change could require an entire system revamp.\n\nIn software and people organizations, good design has high cohesion and low coupling.\n\n> [!info] In short...\n>\n> High cohesion _within_ modules is good. You want code that changes together to live together.\n>\n> Low coupling _between_ modules is good. You don’t want changes in one module to cause changes in other modules.",
  "title": "Cohesion vs Coupling"
}