Design Principper
Når man taler om objekt design er der en række principper man bør forsøge at overholde i høj grad som muligt. Overholdelse af disse principper giver en lang række fordele, som både kan vise sig inden, under og efter udviklingen af et system.
Et par af de mest gængse principper er:
- Encapsulation: Indkapsling af det der ændre sig. - Hold udførsel/body af metoder, værdier o.l. skjult, så omkringliggende klasser ikke baseres på dette indhold, da ændringer vil gøre disse klasser udygtige i deres arbejde.
- Low Coupling: Få bindinger mellem klasser – så få bindinger mellem klasser, så ændringer eller udskiftningen af en klasse, ikke skader for meget omkringliggende kode.
- High Cohesion: Høj sammenhørighed i klasserne. – lad én klasse håndtere én ting. Placer ikke ansvaret for flere ting i en klasse.
Der findes som sagt andre principper, og der er skrevet en mængde rigtig god litteratur om emnet. Med en fælles nævner kan man sige at disse principper hver især beskriver et princip for hvordan man opnår den bedste beskyttelse af variation.
Denne beskyttelse af variation, på engelsk bruges ”protected variations” er grundprincippet, som de andre principper alle er arter af. Det at beskytte det der variere i et program, opfattes som det mest essentielle til godt OO design (gælder også ikke-OO design).
Patterns er ikke noget farligt og super avanceret at komme i gang med. Alle kan forstå patterns og OO design
Hvis du læser de tre nævnte principper, kan du se at de faktisk alle forholder sig til at beskytte variation, på den ene eller den anden måde: indkapsling, svage bindinger, sammenhørighed. Grunden til at det er så essentielt at beskytte variation, skal findes i at Software altid er en evigt foranderlig størrelse.
Det skal ændres: fordi kunden ikke er tilfreds, fordi det skal modificeres til at i møde komme nye krav, holdes ved lige, bruges på en ny platform eller noget helt andet, for blot at nævne nogle få eksempler. – der findes MANGE flere, og du er helt sikkert stødt på nogen af dem, hvor du har skullet re-scope et projekt. – men disse principper er ikke kun nyttige når et projekt er færdigt, eller næsten færdigt og skal ændres eller opdateres.
Design principperne kan og bør bruges allerede inden man overhovedet har sat sig til rette med kode-hatten på. I det stadig af projektet planlægger man hvordan programmet skal sammensættes, f.eks. med et modelleringsværktøj som UML.
Videre er principperne også med til at gøre koden langt lettere at forstå for udvikleren, i takt med at hun får gjort dele af systemet færdigt og oplever hvordan koden er optimal og har sammenhørighed. Så principperne og den tankegang de giver for udviklingsprocessen er gældende hele vejen igennem projektet.
Derfor kan vi rent faktisk bruge disse principper til at effektivisere vores udviklingsproces.
Design Patterns
Med tiden er disse principper blevet afprøvet og erfaret til en sådan grad, at begrebet design patterns er opstået. Design patterns er udviklers erfaring med design principper, samlet under forskellige navne, som beskriver det koncept/begreb det enkelte design pattern omhandler. Igen er disse patterns er afgrad af forskellige måder af beskytte variation på.
Vist grafisk, kunne forholdet se sådan her ud.
Ofte er et design pattern rettet mod et meget specifikt problem i designet. Det kunne være et pattern der afhjalp en problemstilling med kommunikation over et netværk, et pattern der afhjalp problemer med ofte udskiftelig skatteberegningskomponenter fra Told og Skat eller et pattern der gør det lettere at få et MovieClip i Flash til at indeholde og tilpasse sig data på en server.
Et pattern er ikke konkret kode, og derfor kunne man måske finde et pattern der kunne bruges i alle tre af de før nævnte eksempler. Patterns er et højere niveau af tankegang, eller som nogen siger ”50.000 foot view of the program”.
Hvis jeg her skal prøve at sammenfatte et par formuleringer om patters:
- Patterns er afprøvede OO erfaringer, som er samlet under navngivne koncepter/begreber.
- Patterns giver dig ikke konkret kode, men i stedet generelle løsninger til design problemer.
- Patterns bliver ikke opfundet, men opdaget.
- De fleste patterns er møntet mod forhold der har med forandring i software at gøre.
- De fleste patterns giver mulighed for dele af et program kan ændre sig, uden konsekvens for omkringliggende kode.
- Patterns giver et fælles ordforråd med andre udviklere, og gør det lettere at forstå andres arbejde, samt at dele sit eget.
Patterns er ikke noget farligt og super avanceret at komme i gang med. Alle kan forstå patterns og OO design. Det er ikke noget man kan eller ikke kan. Alle kan lære at designe gode og fornuftige løsninger. Til gengæld vil man ofte føle sig rustet til at designe noget langt mere avanceret end det man gjorde tidligere. – men det må man jo så tage med
Det var en kort intro til design patterns og OO design principper.