Často se setkávám s vývojáři, kteří neslyšeli o principech SOLID (my . — pozn. red.) nebo o objektově orientovaném programování (OOP), nebo slyšeli, ale nepoužívají je v praxi. V tomto článku jsou popsány výhody OOP principů, které pomáhají vývojáři v jeho každodenní práci. Některé z nich jsou dobře známé, jiné méně, takže článek bude užitečný jak nováčkům, tak zkušeným programátorům.
Připomínáme: pro všechny čtenáře „Habra“ — sleva 10 000 korun při přihlášení na jakýkoli kurz Skillbox s promo kódem „Habr“.
Skillbox doporučuje: Vzdělávací online kurz .
DRY (Don’t Repeat Yourself)
Poměrně jednoduchý princip, jehož podstata je jasná z názvu: „Nepořádej se“. Pro programátora to znamená potřebu vzdálit se od duplicitního kódu a také možnost využívat v práci abstrakci.
Pokud v kódu existují dvě opakující se části, měly by být sloučeny do jedné metody. Pokud je pevně stanovená hodnota používána více než jednou, měla by být převedena na veřejnou konstantu.
To je potřeba, aby se zjednodušil kód a usnadnila jeho údržba, což je hlavním úkolem OOP. Není dobré ani přehánět se slučováním, protože stejný kód neprojde kontrolou jak s OrderId, tak se SSN.
Inkapsulace změn
Softwarové produkty většiny společností neustále vyvíjejí. To znamená, že do kódu je třeba zavádět změny a udržovat ho. Usnadnit si život lze pomocí inkapsulace. To umožní efektivněji testovat a udržovat stávající základnu kódu. .
Pokud programujete v Javě, pak .
Princip otevřenosti/zavřenosti
Tento princip lze snadno zapamatovat, pokud si přečtete následující tvrzení: „Softwarové entity (třídy, moduly, funkce atd.) by měly být otevřené pro rozšiřování, ale uzavřené pro změny“. V praxi to znamená, že mohou umožnit měnit své chování bez úpravy zdrojového kódu.
Princip je důležitý, když úpravy ve zdrojovém kódu vyžadují provedení jeho revize, modulového testování a dalších procedur. Kód, který se podřizuje principu otevřenosti/zavřenosti, se při rozšíření nemění, a proto s ním je mnohem méně problémů.
Zde je příklad kódu, který tento princip porušuje.
Pokud bude potřeba něco změnit, zabere to spoustu času, jelikož je třeba změnit všechny části kódu, které souvisejí s požadovaným fragmentem.
Mimochodem, otevřenost-zavřenost je jedním z principů SOLID.
Princip jediné odpovědnosti (SRP)
Další princip ze sady SOLID. Říká, že "existuje pouze jeden důvod, proč by se třída měla měnit". Třída řeší pouze jeden úkol. Může mít několik metod, ale každá z nich se používá pouze k vyřešení společného úkolu. Všechny metody a vlastnosti by měly sloužit pouze tomu.
Hodnota tohoto principu spočívá v tom, že oslabuje vazbu mezi jednotlivými komponenty softwaru a kódem. Pokud přidáte více než jednu funkčnost do třídy, zavádí to vazbu mezi dvěma funkcemi. Pokud tedy změníte jednu z nich, existuje velká šance, že zkazíte druhou, která je s první spojena. To znamená zvýšení počtu testovacích cyklů, abyste předem odhalili všechny problémy.
Princip inverze závislostí (DIP)
Výše byl uveden příklad kódu, kde AppManager závisí na EventLogWriter, který je zase úzce spojen s AppManagerem. Pokud potřebujete jiný způsob, jak zobrazit oznámení, ať už je to push, SMS nebo email, je třeba změnit třídu AppManager.
Problém může být vyřešen pomocí DIP. Místo AppManageru žádáme EventLogWriter, který bude zaveden pomocí frameworku.
DIP umožňuje bez problémů měnit jednotlivé moduly jinými, změnou modulu závislosti. To umožňuje měnit jeden modul, aniž by to ovlivnilo ostatní.
Kompozice místo dědičnosti
Hlavními způsoby opětovného využití kódu jsou dva — dědičnost a kompozice, přičemž každý má své výhody a nevýhody. Obvykle se dává přednost druhému, protože je flexibilnější.
Kompozice umožňuje měnit chování třídy za běhu nastavením jejích vlastností. Při implementaci rozhraní se používá polymorfismus, který umožňuje flexibilnější implementaci.
Dokonce i "Effective Java" od Joshuy Blocha doporučuje dávat přednost kompozici před dědičností.
Princip substituce Barbary Liskov (LSP)
Další princip z nástroje SOLID. Týká se toho, že podtypy by měly být zaměnitelné za nadtyp. To znamená, že metody a funkce, které pracují s nadtřídou, by měly být schopny bez problémů fungovat i s jejími podtřídami.
LSP souvisí jak s principem jediné odpovědnosti, tak s principem rozdělení odpovědnosti. Pokud třída poskytuje více funkcionality než podtřída, poslední nebude podporovat některé funkce, což porušuje tento princip.
Zde je úsek kódu, který porušuje LSP.
Metoda area(Rectangle r) počítá plochu obdélníku. Program spadne po vykonání třídy Square, protože Square zde není obdélník. Podle principu LSP by funkce, které používají odkazy na základní třídy, měly být schopny používat objekty odvozených tříd bez dalších instrukcí.
Tento princip, který je specifickým definováním podtypu, byl navržen Barbarou Liskov v roce 1987 na konferenci v hlavním referátu s názvem „Abstrakce dat a hierarchie“ — odtud jeho název.
Princip rozdělení rozhraní (ISP)
Další princip SOLID. Podle něj by nemělo být implementováno rozhraní, které není používáno. Dodržování tohoto principu pomáhá systému zůstat flexibilním a vhodným pro refaktoring při změnách v logice.
Nejčastěji se tato situace vyskytuje, když rozhraní obsahuje několik funkcionalit, a přitom klient potřebuje pouze jednu z nich.
Protože napsání rozhraní je složitý úkol, po dokončení práce bude problém jej změnit, aniž by se něco porušilo.
Výhodou principu ISP v Javě je, že nejprve je třeba implementovat všechny metody, a až potom mohou být využity třídami. Tento princip tedy umožňuje snížit počet metod.
Programování pro rozhraní, nikoli implementaci
Z názvu je to jasné. Uplatnění tohoto principu vede k vytvoření flexibilního kódu, který dokáže pracovat s jakoukoli novou implementací rozhraní.
Měl by být použit typ rozhraní pro proměnné, návratové typy nebo typ argumentu metody. Příklad - použití SuperClass místo SubClass.
To znamená:
List numbers = getNumbers();
A ne:
ArrayList numbers = getNumbers();
Tady je praktická implementace toho, co bylo výše řečeno.
Princip delení
Běžný příklad — metody equals() a hashCode() v Javě. Když je potřeba porovnat dva objekty, tato akce se deleguje příslušné třídě místo klientské.
Výhodou tohoto principu je absence duplicity kódu a relativně snadná změna chování. Je také aplikovatelný na delegaci událostí.
Všechny tyto principy umožňují psát flexibilnější, krásnější a spolehlivější kód s vysokou kohézností a nízkou vazbou. Samozřejmě, teorie je dobrá, ale aby se vývojář skutečně naučil používat nabyté znalosti, je potřeba praxe. Dalším krokem po osvojování principů OOP může být studium návrhových vzorů pro řešení běžných problémů vývoje softwaru.
Skillbox doporučuje:
- Praktický kurz .
- Aplikovaný online kurz .
- Dvouroční praktický kurz .
Zdroj: habr.com
