Ganska ofta träffar jag utvecklare som inte har hört talas om SOLID-principerna (vi . — Transl.) eller objektorienterad programmering (OOP), eller har hört talas om dem, men använder dem inte i praktiken. Den här artikeln beskriver fördelarna med OOP-principer som hjälper utvecklaren i hans dagliga arbete. Vissa av dem är välkända, andra inte så mycket, så artikeln kommer att vara användbar för både nybörjare och erfarna programmerare.
Påminnelse: för alla Habr-läsare - en rabatt på 10 000 rubel när du anmäler dig till någon Skillbox-kurs med hjälp av Habr-kampanjkoden.
Skillbox rekommenderar: Pedagogisk onlinekurs .
TORRA (upprepa inte dig själv)
En ganska enkel princip, vars kärna framgår av namnet: "Upprepa inte dig själv." För en programmerare innebär detta behovet av att undvika duplicerad kod, samt möjligheten att använda abstraktion i sitt arbete.
Om det finns två repeterande avsnitt i koden bör de kombineras till en metod. Om ett hårdkodat värde används mer än en gång är det värt att konvertera det till en offentlig konstant.
Detta är nödvändigt för att förenkla koden och göra den lättare att underhålla, vilket är huvudmålet med OOP. Du bör inte överanvända facket heller, eftersom samma kod inte kommer att passera verifiering med både OrderId och SSN.
Inkapslande förändringar
De flesta företags mjukvaruprodukter utvecklas ständigt. Det betyder att ändringar måste göras i koden, den behöver stödjas. Du kan göra ditt liv enklare genom att använda inkapsling. Detta gör att du kan testa och underhålla din befintliga kodbas mer effektivt. .
Om du skriver i Java, alltså .
Öppen/stängd princip
Denna princip kan lätt kommas ihåg genom att läsa följande uttalande: "Programvaruenheter (klasser, moduler, funktioner, etc.) bör vara öppna för förlängning, men stängda för modifiering." I praktiken innebär det att de kan tillåta att sitt beteende ändras utan att ändra källkoden.
Principen är viktig när ändringar i källkoden kräver kodrevision, enhetstestning och andra procedurer. Kod som följer principen öppen/stängd ändras inte vid förlängning, så det är mycket färre problem med den.
Här är ett exempel på kod som bryter mot denna princip.
Om du behöver ändra något i det kommer det att ta mycket tid, eftersom alla delar av koden som har en koppling till det önskade fragmentet måste ändras.
För övrigt är öppenhet-stänghet en av principerna för SOLID.
Single Responsibility Principle (SRP)
En annan princip från SOLID-setet. Den säger att "det finns bara en orsak som orsakar en förändring i klass." Klassen löser bara ett problem. Det kan ha flera metoder, men var och en av dem används bara för att lösa ett vanligt problem. Alla metoder och egenskaper bör endast tjäna detta.
Värdet med denna princip är att den lossar kopplingen mellan den enskilda mjukvarukomponenten och koden. Om du lägger till mer än en funktionalitet i en klass introduceras en relation mellan de två funktionerna. Således, om du ändrar en av dem, finns det en stor chans att förstöra den andra, som är kopplad till den första. Och detta innebär ökade testcykler för att identifiera alla problem i förväg.
Dependency Inversion Principle (DIP)
Ovan är ett kodexempel där AppManager är beroende av EventLogWriter, som i sin tur är nära kopplat till AppManager. Om du behöver ett annat sätt att visa en notifiering, oavsett om det är push, SMS eller e-post, måste du byta AppManager-klass.
Problemet kan lösas med DIP. Så istället för AppManager begär vi en EventLogWriter, som kommer att anges med hjälp av ramverket.
DIP gör det möjligt att enkelt ersätta enskilda moduler med andra genom att byta beroendemodul. Detta gör det möjligt att ändra en modul utan att påverka de andra.
Sammansättning istället för arv
Det finns två huvudsakliga sätt att återanvända kod: arv och sammansättning, som båda har sina egna fördelar och nackdelar. Vanligtvis är den andra att föredra eftersom den är mer flexibel.
Komposition ger dig möjlighet att ändra beteendet för en klass under körning genom att ställa in dess egenskaper. Vid implementering av gränssnitt används polymorfism, vilket ger en mer flexibel implementering.
Even Effective Java av Joshua Bloch rekommenderar att man väljer komposition framför arv.
Barbara Liskov Substitution Principle (LSP)
En annan princip från SOLID verktygslåda. Den anger att subtyper måste vara utbytbara mot supertypen. Det vill säga att metoder och funktioner som fungerar med en superklass ska kunna fungera utan problem med dess underklasser.
LSP är förknippat med både principen om ett ansvar och principen om delat ansvar. Om en klass tillhandahåller mer funktionalitet än en underklass, kommer den senare inte att stödja en del av funktionaliteten, vilket bryter mot denna princip.
Här är en kod som motsäger LSP.
Area(Rektangel r)-metoden beräknar arean av en rektangel. Programmet kommer att krascha efter att ha kört Square eftersom Square inte är en rektangel här. Enligt LSP-principen ska funktioner som använder referenser till basklasser kunna använda objekt av härledda klasser utan ytterligare instruktioner.
Denna princip, som är en specifik definition av en undertyp, föreslogs av Barbara Liskov i en konferens keynote 1987 med titeln "Dataabstraktion och hierarki", därav dess namn.
Interface Separation Principle (ISP)
Ännu en SOLID princip. Enligt den ska ett gränssnitt som inte används inte implementeras. Att följa denna princip hjälper systemet att förbli flexibelt och lämpligt för refaktorisering när ändringar görs i driftslogiken.
Oftast uppstår denna situation när gränssnittet innehåller flera funktioner samtidigt, och klienten behöver bara en av dem.
Eftersom att skriva ett gränssnitt är en svår uppgift, kommer det att vara en utmaning att ändra det efter att arbetet är klart utan att gå sönder.
Fördelen med ISP-principen i Java är att alla metoder måste implementeras först, och först därefter kan de användas av klasser. Därför gör principen det möjligt att minska antalet metoder.
Programmering för gränssnittet, inte implementeringen
Allt här framgår av namnet. Att tillämpa denna princip leder till skapandet av flexibel kod som kan fungera med alla nya implementeringar av gränssnittet.
Du bör använda gränssnittstypen för variabler, returtyper eller metodargumenttypen. Ett exempel är att använda SuperClass snarare än SubClass.
Det är:
List numbers= getNumbers();
Men inte:
ArrayList numbers = getNumbers();
Här är en praktisk implementering av det som diskuterats ovan.
Delegationsprincipen
Ett vanligt exempel är metoderna equals() och hashCode() i Java. När det är nödvändigt att jämföra två objekt delegeras denna åtgärd till motsvarande klass istället för klienten.
Fördelen med principen är att det inte finns någon duplicering av kod och det är relativt enkelt att ändra beteende. Det gäller även evenemangsdelegering.
Alla dessa principer gör att du kan skriva mer flexibel, vacker och pålitlig kod med hög sammanhållning och låg koppling. Naturligtvis är teori bra, men för att en utvecklare faktiskt ska använda den inhämtade kunskapen krävs övning. När du har bemästrat OOP-principerna kan ditt nästa steg vara att lära dig designmönster för att lösa vanliga problem med mjukvaruutveckling.
Skillbox rekommenderar:
- Praktisk kurs .
- Tillämpad onlinekurs .
- Tvåårig praktisk kurs .
Källa: will.com