SOLID Principles AANUG Meeting #11

Denne blog post er både for lige at komme igang med at blogge, fortælle lidt om AANUG og så også for lige at repetere det jeg lige har lært :)
Aftenens AANUG blev (forsøgt) optaget på video, og videoen kan findes på http://qik.com/video/2911338
Lyden er nok ikke lige så fantastisk, men den er der.
Desuden blev der taget et par få billeder som kan findes lige nedenunder.

Martins slides samt eksempler ryger op på http://www.aanug.dk eller hans blog http://www.unitofwork.dk inden så længe.

Så meget forstod jeg af SOLID Principperne, Yay

SRP – Single Responsibility Principle
Keep it simple stupid.
Klasser skal helst kun have eet formål.
En god måde at følge det på er ved at beskrive hvad ens klasses formål er, og hvis den sætning man får skrevet indeholder “og”, skal man simpelthen splitte klassen op i flere klasser der hver har et mindre “ansvar”.

OCP – Open Closed Principle
Skrive kode så det er muligt at tilføje funktionalitet uden at redigere i klassen.
Fx. gennem polymorfi, som er et pænt ord for nedarvning bland klasser og interfaces.

LSP – Liskov’s Substitution Principle
Faktisk er jeg ikke helt med på hvad forskellen mellem LSP og OCP er, de siger begge noget af det samme, nemlig at man skal holde sig fra for mange dependencies.
Men LSP vejer måske mere hen imod at en klasse med en metode der tager imod en anden klasse som parameter skal implementere et interface med så få krav som muligt, men stadig nok til at klassen ikke fejler når man eksekverer koden.
Det var lige lovligt kryptisk, beklager.

ISP – Interface Segregation Principles
Igen, dette princip ligner en del SRP, og betyder at man skal holde sig fra store interfaces, simpelthen dele det ud på mange små interfaces, og så opbygge større interfaces ved at arve fra de mindre. På den måde bliver det mere specifikt fx. hvilke klasser en metode tager imod.
Personligt synes jeg det gør koden meget mere læsbar, såfremt man navngiver sine interfaces ordentligt!

DIP – Dependency Inversion Principle
Dependencies der strækker sig ud over det hele i eet stort ederkoppenet er ikke super godt for.. noget.
Så DIP siger at man skal holde “highlevel” klasser for sig selv, og ligeså med “lowlevel”, de skal nærmest være ligeglade med hvad der sker udenfor dem selv.
Hvis man holder antallet af dependencies nede er risikoen for at noget fejler, efter man har ændret noget et andet sted ikke nær så stor.

Jeg har lidt problemer med at skille principperne fra hinanden, da jeg synes et par af dem ligner hinanden ret meget til forveksling, om det er meningen på en måde skal jeg ikke kunne sige.

SOLID er en videreudvikling af de grundlæggende OOP principper, og hvis brugt rigtigt skulle det give bedre navngivning, samt flere klasser og dermed bedre læsbarhed.

Men som sagt er dette bare lige min tolkning af aftenens møde, så hvis der er noget jeg har misforstået, må folk meget meget gerne lige smide en kommentar og rette mig :)

Her er lige et par billeder..

Næste møde @meget tæt på telenor om Linq
Det kan vi li :)