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:
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
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:
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:
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:
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 ->
Ercole Palmeri
Förutsägande underhåll revolutionerar olje- och gassektorn, med ett innovativt och proaktivt förhållningssätt till anläggningsförvaltning.…
UK CMA har utfärdat en varning om Big Techs beteende på marknaden för artificiell intelligens. Där…
Dekretet "Gröna hus", formulerat av Europeiska unionen för att förbättra energieffektiviteten i byggnader, har avslutat sin lagstiftningsprocess med...
Casaleggio Associatis årsrapport om e-handel i Italien presenteras. Rapport med titeln "AI-Commerce: gränserna för e-handel med artificiell intelligens"....
