Bij het fragmentatie pattern heb je geen programma-flow meer. Voor iedere miniscule state wordt een class aangemaakt, waardoor je een enorme kerstboom krijgt waar niemand meer een flow in kan ontdekken. Het liefst wordt daarbij Reactive ingezet, zodat je flow verdwenen is tijdens het debuggen.
De classes en methods krijgen geen namen die herkenbaar zijn binnen het businessdomein dat je probeert te automatiseren, want dat is veel te hard-coded. Alle classes dienen abstracte namen te krijgen.
De classes moeten klein zijn en de methods hebben maximaal 10 coderegels, die allemaal een miniscule verantwoordelijkheid hebben. Daardoor is de herbruikbaarheid maximaal en dat doe je dan ook overal in de code, zelfs bij code die niets met het ontstaan van de class te maken heeft. Een wijziging in een class gaat daarmee maximaal andere ongerelateerde code raken.
Tevens heeft iedere class ook een bijbehorende interface, want een
concrete implementatie is yukkie en moet altijd een protocol worden. Je weet immers nooit of je nog een alternatieve implementatie zou willen maken.
Typisch heb je een hoop lege classes in je solution en dat vind je niet vies, want je weet maar nooit of je in de toekomst deze lege classes nog gaat vullen.
Overal moeten "principles" en design-patterns ingezet. Het liefst iedere maand nieuwe principles en patterns. Tegenwoordig zijn het Liskov Substitution Principle, Interface Segregation Principle, Flyweight pattern, Memento Pattern en Interpreter Pattern in de mode. Maar regelmatig moet je een nieuw pattern in de code toevoegen. Uitleg is verder niet nodig, want design-patterns zijn algemeen bekend.
</sarcasme>
Geen opmerkingen:
Een reactie posten