SOLID vilka är de 5 principerna för objektorienterad programmering

Solid solida geometriska figurer
träning
1

SOLID är en akronym som hänvisar till de fem principerna för objektorienterad design (OOD eller OOP). Det här är riktlinjer som utvecklare kan använda för att skapa programvara som är lätt att hantera, underhålla och utöka. Att förstå dessa begrepp gör dig till en bättre utvecklare och hjälper dig att undvika problem med programvaruhantering. Vad betyder det att vara en bra programmerare?

Alla med viss erfarenhet av programvaruprogrammering bedömer programvarukod skriven av andra, med bedömningsparametrar baserat på deras karriärväg.

Under min yrkeskarriär har jag känt många utvecklare och jag har sett tusentals rader kod och när jag behöver utvärdera utvecklarens skicklighet tittar jag främst på två faktorer:

  • Enkelhet i att läsa koden;
  • Hur sannolikt deras kod är att fungera och utvecklas över tiden.

Lyckligtvis finns det några grundläggande eller principer som gör det enkelt att bli bättre på kodning.

förkortningen SOLID står för:
S: principen om ett enda ansvar
O: öppen-stängd princip
L: Liskovs substitutionsprincip
I: Princip för segregering av gränssnitt
D: Princip för inversion av beroende

Låt oss börja med att fördjupa oss i den första SOLID-principen, nämligen

Enkeltansvarsprincip

En klass (eller modul) borde bara ha en anledning att förändra, att utvecklas.

Konceptet i sig är väldigt enkelt, men för att uppnå denna enkelhet kan implementeringsvägen vara mycket komplicerad. En klass borde bara ha en anledning att ändra.

Men varför? 

Varför är det så viktigt att bara ha en anledning att ändra?

Till exempel, om det finns två olika orsaker till förändring, kan det tänkas att två olika team kan arbeta med samma kod av två olika skäl. Var och en måste implementera sin egen lösning, som i fallet med ett sammanställt språk (som C ++, C # eller Java) kan leda till moduler som är oförenliga med andra team eller andra delar av applikationen.

Ett annat exempel, om du använder ett tolkat språk kan du behöva testa samma klass eller modul av olika skäl. Detta innebär mer arbete, tid och ansträngningar för kvalitetskontroll.

Att identifiera en funktion som en klass eller modul ska ha är mycket mer komplicerad än att bara titta på en checklista för att köra tester. 

Men låt oss försöka tänka ur en mindre teknisk synvinkel, det vill säga, låt oss försöka analysera användaren av vår klass eller modul, det är vem som kommer att använda den. En grundläggande aspekt som vi alltid måste komma ihåg är att användarna av applikationen eller systemet vi utvecklar som betjänas av en viss modul kommer att vara de som begär ändringar i den. De som serveras kommer att be om att ändra klass eller modul. 

Några exempel på moduler och deras användning:

  • Underhållsmodul: användaren består av databasadministratörer och programvaruarkitekter.
  • Rapporteringsmodul: användaren består av kontorsanställda, revisorer och produktion.
  • Betalningsberäkningsmodul för ett lönesystem: användare kan inkludera advokater, chefer och revisorer.
  • Textsökningsmodul för ett bibliotekshanteringssystem: användare kan representeras av bibliotekaren eller av bibliotekets besökare och kunder.

Så om det första steget är att söka efter skådespelarna eller skådespelaren som har rollen som samtalspartner med modulen, kan det vara svårt att associera individer med alla roller. I ett litet företag kan en person spela flera roller medan det i ett stort företag kan vara flera personer som har en enda roll. 

Det verkar rimligare att identifiera roller snarare än människor eller användare.

Därför:

  • användaren av mjukvarusystemet definierar orsakerna till ändringen;
  • ett ansvar är en familj av funktioner som tillgodoser behoven hos en viss aktör, det vill säga av användaren av systemet;
  • skådespelarna blir användaren en källa till förändring för familjen av funktioner som måste tillgodose användarens behov;
  • utvecklingen av användarnas behov, styr utvecklingen av funktionalitet;

SOLID-principer

Låt oss se några exempel

Anta att vi har en bokklass som sammanfattar konceptet med en bok och dess funktionalitet.

klassbok {

    funktion getTitle () {

        returnera “A Great Book”;

    }

    funktion getAuthor () {

        återlämna “Alessandro Baricco”;

    }

    funktion nästa sida () {

        // nästa sida

    }

    funktion printCurrentPage () {

        eko "innehåll på aktuell sida";

    }

}

Detta är en mycket normal klass. Vi har en bok och klassen kan ge oss titeln, de kan ge oss författaren och de kan gå vidare. Slutligen kan den också skriva ut den aktuella sidan på skärmen. 

Det finns dock ett litet problem. 

Funderar du på de aktörer som är involverade i hanteringen av bokobjektet, vem kan de vara? 

Vi kan lätt tänka på två olika aktörer här: Bokhantering (som den bibliotekarie) Och Dataöverföringsmekanism (som hur vi vill leverera innehåll till användaren: på skärmen, grafiskt användargränssnitt, endast textanvändargränssnitt, kanske utskrift). 

Vi har därför två mycket olika aktörer som interagerar med klassen.

I ett nötskal blandas denna klass mellan:

  • affärslogik med 
  • presentationen 

detta kan vara ett problem eftersom det bryter mot principen om enskild ansvarsskyldighet (SRP). 

Hur kan vi ändra, hur kan vi förbättra den här koden för att respektera principen om ett enda ansvar?

Ta en titt på följande kod:

klassbok {

    funktion getTitle () {

        returnera “Oceano Mare”;

    }

    funktion getAuthor () {

        återlämna “Alessandro Baricco”;

    }

    funktion vänd sida () {

        // nästa sida

    }

    funktion getCurrentPage () {

        eko "innehåll på aktuell sida";

    }

}

gränssnittsskrivare {

    funktion printPage ($ sida);

}

klass StampaLibro implementerar skrivare {

    funktion printPages ($ sida) {

        echo $ sida;

    }

}

 

klass HtmlPrinter implementerar skrivare {

    funktion printPages ($ sida) {

        eko ' '. $ sida. '' ';

    }

}

Detta mycket enkla exempel visar hur man skiljer presentation från affärslogik, och i enlighet med SRP erbjuder det stora fördelar i flexibiliteten i vårt projekt.

Låt oss titta på ett annat exempel:

Ett exempel som liknar det ovan är när ett objekt kan spara och hämta sig från presentationen.

klassbok {

    funktion getTitle () {

        returnera “Oceano Mare”;

    }

    funktion getAuthor () {

        återlämna “Alessandro Baricco”;

    }

    funktion vänd sida () {

        // nästa sida

    }

    funktion getCurrentPage () {

        returnera "innehåll på aktuell sida";

    }

    funktion spara () {

        $ filnamn = '/ dokument /'. $ detta-> getTitolo (). '-'. $ detta-> getAuthor ();

        file_put_contents ($ filnamn, serienummer ($ detta));

    }

}

Som tidigare kan vi också här identifiera olika aktörer som Bokhantering (som den bibliotekarie) Och Uthållighet. När vi vill ändra hur vi går från sida till sida måste vi ändra den här klassen. Vi kan ha flera orsaker till förändring.

klassbok {

    funktion getTitle () {

        returnera “Oceano Mare”;

    }

    funktion getAuthor () {

        återlämna “Alessandro Baricco”;

    }

    funktion vänd sida () {

        // nästa sida

    }

    funktion getCurrentPage () {

        returnera "innehåll på aktuell sida";

    }

}

klass SimpleFilePersistence {

    funktion spara (Boka $ bok) {

        $ filnamn = '/ dokument /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filnamn, serienummer ($ bok));

    }

}

Att flytta uthållighetsoperationen till en annan klass kommer tydligt att skilja ansvar och vi kommer att kunna utbyta uthållighetsmetoder utan att påverka vår bokklass. Att till exempel implementera en DatabasePersistence-klass skulle vara trivialt, och vår affärslogik byggd kring bokoperationer kommer inte att förändras.

Fortsätt med att läsa den andra principen Öppen / Stängd ->

1 kommentar

Lämna en kommentar

Il tuo indirizzo email icke sarà pubblicato. I campi sono obbligatori contrassegnati *

liskov-principen
träning
Principen för Liskov-substitution, tredje SOLID-principen

Barnklasser ska aldrig påverka eller ändra typdefinitionerna för föräldraklassen. Konceptet med denna princip introducerades av Barbara Liskov i en grundton för konferensen 1987 och publicerades därefter i en artikel tillsammans med Jannette Wing 1994. Deras ursprungliga definition ...

google marknadsföringstrender
träning
Hur man använder Google Trends för marknadsföring i realtid

En av de största svårigheterna som företagen stött på 2020 var att förstå vilka produktsektorer som skulle diversifiera sin verksamhet: de flesta industrisektorerna har faktiskt drabbats av stora konsekvenser vilket gör det nästan omöjligt för företag att tränga in i dem, särskilt som en ny aktör. Mycket få tillverkningssektorer ...

strategi för affärsinformation
metoder
Strategier för framgångsrik Business Intelligence

Att bygga en framgångsrik strategi för din Business Intelligence utgår från en korrekt vision av målen. Vi ser nedan några grundläggande punkter. Bedömning av den nuvarande situationen Det skulle vara ett allvarligt misstag att underskatta denna aspekt. Att utvärdera den nuvarande situationen innebär att analysera processer, strukturer ...