Boken Design Patterns av Gang of Four har varit och är required reading för utvecklare av alla slags system. Tanken är bländande - best practices abstraherade och nerkokade till en bukett av pärlor att plocka ur när man bygger sin applikation (ursäkta ett något utflippat bildspråk ("bukett av pärlor"?)).
Problemet uppstår när vi vanliga dödliga börjar gå loss i denna bukett. Exemplen är legio på när ett ordinärt order-lager-inköps-system (substituera mot valfri vanilla-applikation) blir en orgie i patterns.
Många av de mer basala patternsarna (heter det så?) är inte så svåra att knö in i ditt system. Kanske lite Composite, lite Delegate osv. Man får blodad tand. Lite Decorator ovanpå det här (lite krystat i order-lager-inköps-systemet, men what-the-heck).
The mother-of-all-patterns-you-don't-need: Factory ligger sen nära till hands. Och vad är en Factory utan en FactoryManager (som gärna ska instansiera sig från XML).
Rätt vad det är så har man slutat bygga systemet och börjat "The Race of Patterns". Det gäller att få med så många som möjligt. Flest patterns när man dör vinner.
Har vid tillfälle suttit med underhåll av ett system som var byggt på detta vis. En ordinär web request routades genom dispatchers, handlers och delegates så att inte ett öga var torrt. Detta ledde också till att (som ni kanske gissat) 80% av applikationen bestod av infrastruktur för att stödja alla dessa design patterns. Själva business-logiken var gömd långt inne i nån handler nånstans och det var i princip omöjligt (ok, nu tar jag i lite) att avgöra var man skulle hamna för ett givet anrop.
Att fixa buggar och lägga till funktionalitet blev också lite av en bygg-deploy-starta-håll-för-ögonen-övning eftersom man säkert som amen i kyrkan glömt att haka in sin nya handler i nån obskyr XML-fil.
Missförstå mig rätt - patterns rockar, men bara då dom verkligen behövs. Alltför ofta är det ingen som gör en rimlighetsanalys innan man tillför en eller ett par extra nivåer av indirection för att stödja ett till pattern - och kunna bocka av det i boken Design Patterns.
Saturday, November 17, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment