Clean Code - Component Cohesion

Wat zit er precies in een component? Uit welke onderdelen bestaat een component? En wat zijn de krachten wat deze onderdelen samenbrengen? De onderdelen zijn de functies. De krachten die deze functies bij elkaar brengen wordt cohesian genoemd.

Classes zijn de eerste laag van cohesion voor functies. De enige zichtbare onderdelen van een class zijn de publieke functies. De data van een class wordt altijd verborgen gehouden.
Classes zijn een verzameling van functies die allemaal opereren op dezelfde data.

Net als functies kunnen classes ook samenhangend (cohesive) zijn. Soms horen classes bij elkaar en soms niet. De kracht van class cohesion bepaald in welk component een class behoort.

Het doel van een goede componentstructuur is om ze onafhankelijk van elkaar de deployen.

Common Closure Principle

Components zijn altijd onderdeel van 1 layer (ui, middleware, data), niet meerdere. In andere woorden, components do'nt cross boundaries. Als een requirement verandert of toegevoegd wordt, dan is het doel om per layer 1 component aan te passen. Dit principe wordt het Common Closure Principle genoemd: als een requirement verandert dienen er zo min mogelijk componenten te worden aangepast. De classes die gegroepeerd zitten in een component moeten dicht bij elkaar zitten voor de dezelfde soort aanpassingen. De classes die voor dezelfde redenen worden aangepast worden verzameld en de classes die voor andere redenen worden veranderd worden gescheiden. Dit principe lijkt sterk op get Interface Segration Principle. Dit principe gaat over het groeperen van functies in classes. Het Common Closure Principle gaat over het groeperen van classes in componenten. Het woord closure in dit principe gaat er over dat de classes in het component zijn gesloten voor dezefde soort veranderingen. Deze veranderingen zijn vergelijkbaar met de verantwoordelijkheden van het Single Responsibilty Principle.

De classes in een component dienen allemaal dezelfde actor. De classes zijn gesloten voor elke ander actor.

Het doel van een applicatie is om een systemen te maken die meerdere actors dient. Deze systemen bestaan uit lagen die business rules scheiden van details. De lagen bestaan vervolgens weer uit componenten en elk component bestaat weer uit classes die de actor dienen van dat component.

Common Reuse Principle

Groepeer de classes die gezamenlijk gebruikt worden en scheid de classes die niet samen worden gebruikt. In andere woorden. Als een component wordt gebruikt, moeten alle classes binnen dat component gebruikt worden. Als classes niet worden gebruikt, scheidt deze dan. Dit lijkt dus zeer sterk op het Interface Segregation Principle. ISP verteld ons dat je classes moet mijden die afhankelijk zijn van functies die je niet gebruikt. Het CRP zegt dat je classes moet mijden in een component die je niet gebruikt. Voor beide principes geldt: als je een method/class gebruikt, dan worden alle methods/classes gebruikt.