torsdag 19 februari 2009

Design Principles and Design Patterns fortsättning

Tyckte att det blev lite långrandigt så jag bestämde mig för att dela upp min sammanställning av Bob Martins - "Design principles and Design Patterns".

Nu blir det hur man kan hantera beroenden moduler i en applikation.
Packet Cohesion Priniciples
Tre sätt att resonera runt hur man ska förpacka sina moduler
  • The Release Reuse Equivalency Priciple (REP) - REP kopplar ihop releasehantering med återanvändning. De klasser som behövs för att kunna skapa en release av en modul ska grupperas tillsammans och därmed återanvändas tillsammans. Det gör det smidigt tex för en kund att veta att det har hänt tillräkligt med koden för att det ska vara idé att uppdatera även om han/hon bara är intresserad av en liten delmängd av de funktioner som kommer med releasen.
  • The Common Closure Principle (CCP) - Klasser som ändras tillsammans bör förpackas tillsammans. Om man befinner sig i utvecklingsfasen så vill man inte hantera många olika moduler och hålla koll på vilka andra moduler som man är beroende och hur vida de modulerna ändrats på ett sätt som kräver ändring i den egna modulen. Därför minimerar man antalet moduler som behöver uppdateras för en releasecykel.
  • The Common Reuse Principle (CRP) - Klasser som inte används tillsammans ska inte förpackas tillsammans. Varför ska man behöva uppdradera ett operativsystem bara för att få tillgång till en funktion? Förpacka därför bara det som används tillsammans för att inte tvinga på användaren en större förändring än nödvändigt.
De tre principerna ovan utesluter varandra. REP och CRP gör livet lite lättare för de som vill återanvända kod. CCP tenderar till att ge stora moduler medans CRP ger små. Som tur är vilken princip man väljer att förpacka modulerna inte skrivna i sten. Medans man utvecklar kanske man väljer att använda CCP och sedan när modulerna kanske man går mot något som är lättare för användarna av modulerna att använda som REP eller CRP.

The Packet Coupling Principles
De tre kommande principerna styr hur relationerna mellan olika modulerna ska fungera.
  • The Acyclic Dependencies Principle (ADP) - Ganska enkel och självklar. Modulerna ska inte ha cykliska relationer, tex Modul A -> Modul B -> Modul C -> Modul A. Tänk dig att ha dataproviders som är beroende på GUI. Ha någon som håller koll på att cykliska relationer inte smyger sig in i applikationen.
  • The Stable Dependencies Principle (SDP) - SDP säger att man ska försöka att rikta sina beroenden mot det som är stabilt. Vad är då stabilt? Det som är svårt att förändra av olika skäl kan sägas vara stabilt. Den viktigaste faktorn för att en modul är stabil är att den har många andra moduler som är beroende på den. Ska man ändra i modulen så får man ändra på många andra ställen. Herr Martin ställer upp en enkel formel för att beräkna om en modul är stabil eller ej.
    Ca = Inkommande beroenden (klasser utanför modulen som är beroende på modulen i fråga)
    Ce = Utgående beroenden (klasser som är beroende på andra klasser utanför modulen)
    I = Instabilitet - Beräknas I = Ce / (Ca + Ce)
    Så med formeln ovan kan vi säga att SDP betyder: Din modul ska ha högre beroenden än de den har sina beroenden på. Men ska alla moduler vara stabila? Självklart inte, vi vill ju att våra program ska kunna följa med ovärldens krav utan stora arbetsinsatser.
  • The Stable Abstractions Principle (SAP) - SAP är svaret på problemet som uppstår med SDP där det blir svårare och svårare att utföra förändringar desto fler beroenden modulen har. SAP säger att stabila moduler ska vara abstrakta, alltså inte ha någon implementation. Det ger oss frihet att förändra byta ut implementation utan att påverka modulen som alla andra beror på. Alltså ska de mest stabila modulerna vara abstrakta. Herr Matrin råkar ha en liten formel på att mäta detta också:
    Nc = Antalet klasser i modulen
    Na = Antalet abstrakta klasser/interface
    A = Abstrakthet(?) A = Na/Nc

    Om man jämnför A med den tidigare I så bör de följa varandra. En modul med högt I bör också ha ett högt N och en modul med lågt I bör ha lågt N.

    Det finns en ideallinje som I och A följer och man kan räkna på hur långt ifrån denna ideallinje en modul ligger med hjälp av följande formel:
    D = (A + I - 1) / sqrt(2) (ger ett värde mellan 0 - 0.7 ungefär) där värden närmare noll är bättre.

    Naturligtvis är detta bara beräkningar och inget man ska se som absoluta fakta. Men har man gjort värdena kan man välja att tro på dem eller säga att man har gjort val som gör dem missvisande. Men då har man ett värde att resonera runt vilket förmodligen är något bättre än att bara gissa.
Resten av dokumentet handlar om designpatters som jag tror alla är representerande i GOF bok som heter Design Patterns.

Inga kommentarer:

Skicka en kommentar