10 principer för objektorienterad programmering som varje utvecklare bör veta

Jag stöter ganska ofta på utvecklare som inte har hört talas om SOLID-principerna (vi berättade detaljerat om dem här. — Anm.) eller objektorienterad programmering (OOP), eller har hört talas om dem men inte använder dem i praktiken. I den här artikeln beskrivs fördelarna med OOP-principerna som hjälper utvecklare i deras dagliga arbete. Vissa av dem är välkända, andra är mindre kända, så artikeln kommer att vara användbar både för nybörjare och erfarna programmerare.

Påminnelse: Till alla läsare av "Habr" — rabatt på 10 000 rubel vid registrering till vilken kurs som helst på Skillbox med rabattkoden "Habr".

Skillbox rekommenderar: Utbildningskurs online Java-utvecklare.

DRY (Don’t Repeat Yourself)

En ganska enkel princip, vars innebörd framgår av namnet: "Upprepa dig inte". För en programmerare innebär detta att undvika duplicerad kod samt möjligheten att använda abstraktion i sitt arbete.

Om det finns två upprepande sektioner i koden, bör de slås samman till en metod. Om ett fast värde används mer än en gång, bör det omvandlas till en offentlig konstant.

Detta görs för att förenkla koden och göra dess underhåll enklare, vilket är syftet med OOP. Man bör dock inte missbruka sammanslagning, eftersom samma kod inte klarar tester både med OrderId och med SSN.

Inkapselförändringar

Programvaruprodukterna hos de flesta företag utvecklas ständigt. Det innebär att koden måste ändras och stödjas. Man kan förenkla sitt liv genom inkapsling. Detta gör det möjligt att testa och underhålla den befintliga kodbasen mer effektivt. Här är ett av exemplen.

Om du skriver i Java, ska du som standard tilldela private till metoder och variabler.

Öppen/stängd princip

Denna princip är lätt att komma ihåg genom att läsa följande uttalande: "Programvaruenheter (klasser, moduler, funktioner etc.) bör vara öppna för utvidgning men stängda för förändring". I praktiken innebär detta att de kan tillåta att deras beteende ändras utan att ändra källkoden.

Principen är viktig när förändringar i källkoden kräver att den granskas, genomgår enhetstestning och andra procedurer. Kod som följer den öppna/stängda principen ändras inte vid utvidgning, vilket gör att man får färre problem med den.

Här är ett kodexempel som bryter mot denna princip.

Om det behövs några ändringar i den, kommer det att ta mycket tid eftersom alla kodavsnitt som har kopplingar till det nödvändiga fragmentet måste ändras.

Förresten, öppenhet-stängdhet är en av principerna i SOLID.

Principen om enskild ansvarighet (SRP)

En annan princip från SOLID-setet. Den säger att "det finns bara en anledning till att en klass kan ändras". En klass löser bara en uppgift. Den kan ha flera metoder, men var och en av dem används endast för att lösa den övergripande uppgiften. Alla metoder och egenskaper ska endast tjäna detta syfte.

Värdet av denna princip är att den minskar kopplingen mellan enskilda mjukvarukomponenter och koden. Om man lägger till mer än en funktionalitet i en klass, introducerar det en koppling mellan två funktioner. Således, om man ändrar en av dem, finns det stor risk att förstöra den andra, som är kopplad till den första. Det innebär en ökning av testcykler för att upptäcka alla problem i förväg.

Principen om beroendeinversion (DIP)

Exemplet ovan visar koden där AppManager är beroende av EventLogWriter, som i sin tur är nära kopplad till AppManager. Om ett annat sätt behövs för att visa en avisering, vare sig det är en push, SMS eller e-post, måste klassen AppManager ändras.

Problemet kan lösas med hjälp av DIP. Istället för AppManager, begär vi EventLogWriter, som kommer att introduceras genom ramverket.

DIP gör det möjligt att problemfritt byta ut enskilda moduler mot andra, genom att ändra beroendemodulen. Det gör det möjligt att ändra en modul utan att påverka de andra.

Komposition istället för arv

De två huvudmetoderna för att återanvända kod är arv och komposition, och båda har sina fördelar och nackdelar. Vanligtvis föredras den andra eftersom den är mer flexibel.

Komposition möjliggör förändring av klassens beteende under körning genom att ställa in dess egenskaper. Vid implementering av gränssnitt används polymorfism, vilket ger en mer flexibel implementation.

Även "Effective Java" av Joshua Bloch rekommenderar att man föredrar komposition framför arv.

Principen om Barbara Liskovs substitutionsprincip (LSP)

Ännu en princip från SOLID-verktygen. Den säger att underklasser ska kunna ersätta sin superklass. Det vill säga metoder och funktioner som arbetar med superklassen måste kunna fungera utan problem med dess underklasser.

LSP är kopplad både till principen om enhetligt ansvar och principiell delning av ansvar. Om en klass erbjuder mer funktionalitet än en underklass, kommer den senare inte att stödja vissa funktioner, vilket bryter mot denna princip.

Här är en kodsnutt som bryter mot LSP.

Metoden area(Rectangle r) beräknar arean av Rectangle. Programmet kommer att krascha efter att ha kört Square, eftersom Square här inte är en Rectangle. Enligt principen LSP bör funktioner som använder referenser till bas-klasser kunna använda även objekt av underklasser utan ytterligare instruktioner.

Denna princip, som är en specifik definition av underklass, föreslogs av Barbara Liskov 1987 vid en konferens där hon hållit en huvudföreläsning med titeln "Databasfrågor och hierarkier" - därav namnet.

Principen om interface-separation (ISP)

Ytterligare en princip från SOLID. Enligt den bör ett interface som inte används inte implementeras. Att följa denna princip hjälper systemet att förbli flexibelt och redo för refactoring när förändringar görs i logiken.

Denna situation uppstår ofta när ett interface innehåller flera funktionaliteter, men kunden behöver bara en av dem.

Eftersom det är en komplex uppgift att skriva ett interface, kommer det att bli problematiskt att ändra det efter att det slutförts utan att bryta något.

En fördel med ISP-principen i Java är att man först måste implementera alla metoder, och först därefter kan de användas av klasser. Därför ger principen möjlighet att minska antalet metoder.

Programmering för interface, inte implementation

Här är det tydligt från namnet. Tillämpningen av denna princip leder till skapandet av flexibel kod som kan fungera med vilken ny implementation av ett interface som helst.

Man bör använda interface-typ för variabler, returtyper eller argumenttyp i metoden. Exempel — användning av SuperClass istället för SubClass.

Det vill säga:

List numbers = getNumbers();

Och inte:

ArrayList numbers = getNumbers();

Här är en praktisk implementation av det som nämnts ovan.

Delegationsprincipen

Ett vanligt exempel är metoderna equals() och hashCode() i Java. När två objekt ska jämföras, delegeras denna åtgärd till den aktuella klassen istället för klienten.

Fördelen med principen är avsaknaden av kodduplicering och relativt enkel förändring av beteende. Den är också tillämpbar på händelsedelegation.

Alla dessa principer gör det möjligt att skriva mer flexibel, vacker och pålitlig kod med hög koppling och låg beroende. Självklart är teorin bra, men för att utvecklaren verkligen ska börja använda de förvärvade kunskaperna, behövs praktik. Nästa steg efter att ha behärskat OOP-principerna kan vara att studera designmönster för att lösa vanliga problem inom mjukvaruutveckling.

Skillbox rekommenderar:

• Praktisk kurs «Mobilutvecklare PRO».
• Tillämplig onlinekurs Dataanalytiker på Python.
• Tvåårig praktisk kurs «Jag är PRO Webbutvecklare».

Källa: habr.com