Antipatterns: Generic Genericness

 
02 oktober 2009

Omschrijving
Na gedesillusioneerd te zijn geraakt bij de starheid van software van eerdere projecten wordt het idee opgevat om zaken meer generiek te gaan oppakken. Dit wordt echter doorgevoerd tot in het extreme. Generic structuren worden afgewisseld met reflection en andersom. Het framework kan zomaar gecompileerde componenten inladen, als er maar aan bepaalde conventies voldaan is. Er wordt extreem veel ‘vanzelf’ opgelost en het framework wordt binnen no-time topzwaar en onoverzichtelijk.

Symptomen
(Extreem) veel gebruik van reflectie, zeer veel run-time plumbing, extreme ontkoppeling zodat de samenhang niet duidelijk is. Een topzwaar framework dat steeds meer uitzonderingen voor specifieke zaken moet ondersteunen (om het ‘generiek’ te houden). Generieke classes die over-geparameteriseerd specifiek gemaakt worden.

Oplossingen

  • Generiek omzetten naar specifiek.
  • Opdeling in modules die expliciet maken wat ze doen.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags:


Reacties (3)

  • Hoi Andries,

    Het gaat hier niet om de programmeerconstructie “Generics” zoals we de type-parameteriseringsconstructies in Java of Dotnet vaak aanduiden. Wat ik bedoel is dat de software zelf zodanig generiek wordt opgezet zodat het daadwerkelijke geautomatiseerde domein niet meer terug te vinden is in de software.

    Denk aan een klassenaam “Table” met een collectie “Rows”. Of een class “Parent” met een geassocieerde “Child” class.

    Het is bij goed onderhoudbare software belangrijk om het beestje bij de naam te noemen en zaken die specifiek zijn ook expliciet bij de naam te noemen. Als je alles configureerbaar maakt is het vaak niet meer duidelijk wat de software eigenlijk doet.

    Geplaatst op 05 oktober 2009 om 18:47 Permalink

    • Andere manier om het duidelijk te maken: het Java/.NET framework is al een generiek framework met generieke namen in een generiek class library (en zelfs met generics :-). Als je dan bang bent om te specifieke namen in je software te gebruiken, kun je hem misschien beter niet schrijven: dat is nog veel generieker. De waarde van je software zit juist in die specifieke werking.

      Reeds bestaande frameworks + programmeurs + tijd is een generieker startpunt dan elk generiek framework dat je kunt schrijven. En het resultaat is waarschijnlijk handiger in gebruik, beter onderhoudbaar, maakt gebruik van de laatste inzichten, etc.

      Configuratie van een reeds gerealiseerde applicatie/framework is daarin alleen een goed alternatief als je weinig, maar relevante configuratie nodig hebt. M.a.w. als die gerealiseerde applicatie gericht is op een domein en ook voor dat domein ingezet wordt.

      Geplaatst op 06 oktober 2009 om 10:16 Permalink

  • Andries Nieuwenhuize schreef:

    Hoi André,

    Dit verhaal komt zelf ook een beetje generic over. Ik wil het er wel mee eens zijn maar ik kan me er niets (concreets) bij voorstellen. Het lijkt me dat per definitie een generic oplossing taken opsplitst, eenduidig definieert en daarmee de complexiteit reduceert.

    Zoals – abstract gesproken – taak a en b op te splitsen zijn in
    a = c, d en
    b = c, e kunnen we vervolgens c generic definiëren en in a en b aanroepen, concreet maken en gebruiken. Hebben a en b niets gemeen, dan hoef je ook niet generic te zijn.

    Generics is m.i. niets meer dan een handig abstractiemechanisme. Ik kan me op het moment even niet concreet voorstellen hoe je dat kunt misbruiken. Misschien dat iemand een voorbeeldje kan geven van een over-generic (maar wel realistisch) stukje code?

    Geplaatst op 05 oktober 2009 om 9:59 Permalink