Om te beginnen wil ik zeggen dat ik het artikel nogal matig vind. Ik hoop dat het boek beter is.
Laat ik eens heerlijk kort door de bocht gaan en proberen de principes in één zin op te sommen (ja; dit is behoorlijk ongenuanceerd, maar het is in elk geval wel duidelijk. Corrigeer me alsjeblieft als ik de plank missla bij de samenvatting van een sectie.). Daarna zal ik er mijn [als altijd nederige] mening over geven.
Principe 1: Schrijf code die precies doet wat nodig is en niets meer, refactoren kan later altijd nog.
Voorbeeld: Gebruik van unit tests
Dit is natuurlijk hèt credo van het Extreem Programmerende volk. Ik heb er persoonlijk nooit veel aan gedaan dus ik kan er geen waardeoordeel over vellen. Ik kan me wel voorstellen dat het in een grootschalig project met een lange levensduur een nuttig stuk gereedschap kan zijn.
Verder vind ik het voorbeeld niet echt veel aan het principe illustreren; het laat alleen zien dát je kan unit testen met een bestaand framework. Ja woepie, als we overtuigd waren geweest van het nut van unit tests dan hadden we daar zelf ook wel iets voor kunnen schrijven.
Principe 2: Separation of concerns is goed!
Voorbeeld: Scheiding van `business-' en presentatielogica in een webscript.
Dit is natuurlijk iets wat we met de paplepel ingegoten krijgen als informaticastudenten, en wat anders in de praktijk met schade en schande wel geleerd wordt. En zoniet, dan wordt het wel aan iedere PHP hacker verteld die op GoT een vraag komt stellen.
Een beetje intrappen van een open deur, maar goed, het kan blijkbaar niet vaak genoeg gezegd worden.
Principe 3: Separation of concerns is goed!
Voorbeeld: Scheiding van domain logic en persistentielogica.
Misschien ligt het aan mij, maar ik zie niet echt het verschil in boodschap tussen dit en het vorige principe; er wordt alleen een ander voorbeeld gegeven.
Oh, en dat separation of concerns goed was wisten we natuurlijk al.
Principe 4: Je bent zelf verantwoordelijk voor libraries die je van het internet af plukt.
Voorbeeld: Een opsomming van libraries die van Java naar .NET geport worden
Gôh. En ik maar denken dat ik door het gebruik van een library de makers zou kunnen verplichten met mij mee te coden en te bugfixen.
Sorry. Het gebruik van sarcasme is natuurlijk een teken van zwakte. Maar ik zie eerlijk gezegd niet in waarom dit een `principe van software development' zou moeten zijn.
Een ècht principe zou geweest zijn: `Hergebruik zoveel mogelijk software'. Of het een goed principe is, kan ter discussie staan. Maar blijkbaar vindt de schrijver zo'n principe iets te sterk uitgedrukt, dus zeg hij in plaats daarvan:
`Als je software hergebruikt, dan moet je goed opletten wat voor software je daarvoor uitkiest!'
Als ik ooit een sine qua non gehoord heb...
Principe 5: Schrijf je programma zodat het uitbreidbaar is zonder opnieuw te compilen
Voorbeeld: Instantiëer klassen met een factory in plaats van direct (en daarbovenop: lees de te instantiëren klassen uit een configuratiefile!)
Bij deze samenvatting heb ik een beetje op mijn tenen moeten staan, omdat het voorbeeld het grootste deel van de sectie in beslag neemt; maar ik neem aan dat de schrijver zoiets heeft bedoeld. Of misschien ook niet; hoewel de eerste paar regels over een meer algemeen soort uitbreidbaarheid gaan, neigt het behoorlijk naar out-of-the-box uitbreidbaarheid.
Hoe dan ook; in principe is het geen heel slechte zaak om een systeem af te leveren dat de eindgebruiker (of beter, de applicatiebeheerder van de eindgebruiker) aan kan passen zonder dat deze daarbij een compiler nodig heeft (nog afgezien van het `bezwaar' dat daarvoor de source bijgeleverd moet worden, ieks, daar gaat ons intellectueel eigendom!). Op die manier is het mogelijk om een product aan te passen zodat het beter in een bepaald bedrijf past, of het uit te breiden met eigen of 3rd party functionaliteit.
En laten we wel wezen, reflectie (of introspectie) is gewoon een heel erg makkelijke manier om uitbreidbaarheid en onderhoudbaarheid te realiseren zonder code-duplicatie. Dat wil zeggen, als je iets (een klasse, of methode, of resource, of wat dan ook) op een bepaalde plek in de code beschikbaar maakt, dan kan de rest van het systeem middels introspectie uitvinden wat er precies beschikbaar is; dit scheelt je de moeite om nog extra case analysis uit te voeren op de specifieke gevallen.
En laten we wel wezen, bij het schrijven van een unit test library is introspectie ook best nuttig, en bij een persistentiemanager ook. Zoals je misschien wel kan raden ben ik een behoorlijke fan van introspectiefactiliteiten, omdat ze erg losse koppelingen mogelijk maken. Ik ben het met Soultaker eens dat introspectie niet de essentie van losse koppeling en concern separation is, maar verdomd makkelijk om te hebben is het toch wel.
Zoals ik het zie: het artikel (en volgens extrapolatie, het boek) is een ode aan onderhoudbaarheid van software, met een paar praktische technieken die je daarvoor kunt gebruiken. Tja. Niet heel vernieuwend, maar het kan natuurlijk altijd nuttig zijn voor programmeurs die hun brood verdienen met de behandelde talen.
:strip_icc():strip_exif()/u/59957/got-icon.jpg?f=community){kind=icon}
:strip_exif()/u/11775/SoulTaker.gif?f=community)
Zoals een andere lezer ook al opmerkte staat dat haaks op de principes achter een statisch getypeerde taal als C#: "No compile checking anymore. We can just as wel go back to VB6 that way!".:strip_exif()/u/31626/eend.gif?f=community)
Ik hou zelf ook van een zo clean mogelijk ontwerp zonder allerlei... dit kan ooit wel eens handig zijn.. zaken.