Poměrně často se setkávám s vývojáři, kteří o principech SOLID neslyšeli (my . - Transl.) nebo objektově orientované programování (OOP), nebo slyšeli, ale v praxi je nepoužívejte. Tento článek popisuje výhody principů OOP, které vývojáři pomáhají v jeho každodenní práci. Některé z nich jsou známé, jiné tolik ne, takže článek bude užitečný jak pro začátečníky, tak pro již zkušené programátory.
Připomínáme: pro všechny čtenáře "Habr" - sleva 10 000 rublů při zápisu do jakéhokoli kurzu Skillbox pomocí propagačního kódu "Habr".
Skillbox doporučuje: Vzdělávací online kurz .
SUCHÝ (neopakujte se)
Poměrně jednoduchý princip, jehož podstata je zřejmá již z názvu: "Neopakuj se." Pro programátora to znamená nutnost vyhnout se duplicitnímu kódu a také možnost využívat v práci abstrakci.
Pokud jsou v kódu dvě opakující se části, měly by být spojeny do jedné metody. Pokud je pevně zakódovaná hodnota použita více než jednou, vyplatí se ji převést na veřejnou konstantu.
To je nezbytné pro zjednodušení kódu a jeho snadnější údržbu, což je hlavní úkol OOP. Sjednocení byste také neměli zneužívat, protože stejný kód neprojde kontrolou s OrderId a SSN.
Změna zapouzdření
Softwarové produkty většiny společností se neustále vyvíjejí. To znamená, že kód je potřeba změnit, je potřeba ho udržovat. Zapouzdřením si můžete usnadnit život. To vám umožní efektivněji testovat a udržovat stávající kódovou základnu. .
Pokud tedy píšete v Javě .
Princip otevřenosti / blízkosti
Tento princip lze snadno zapamatovat přečtením následujícího prohlášení: "Softwarové entity (třídy, moduly, funkce atd.) by měly být otevřené pro rozšíření, ale uzavřené pro úpravy." V praxi to znamená, že mohou dovolit změnu svého chování bez změny zdrojového kódu.
Princip je důležitý, když změny zdrojového kódu vyžadují revize, testování jednotek a další postupy. Kód, který se řídí principem otevřeno/uzavřeno, se při rozšíření nemění, takže je s ním mnohem méně problémů.
Zde je příklad kódu, který tuto zásadu porušuje.
Pokud v něm potřebujete něco změnit, zabere to spoustu času, protože budete muset změnit všechny části kódu, které mají souvislost s požadovaným fragmentem.
Mimochodem, otevřenost-uzavřenost je jedním z principů SOLID.
Princip jednotné odpovědnosti (SRP)
Další princip ze sady SOLID. Říká, že "existuje pouze jeden důvod, který vede ke změně třídy." Třída má jediný úkol. Může mít několik metod, ale každá z nich se používá pouze k řešení společného problému. Všechny metody a vlastnosti by měly sloužit pouze k tomu.
Hodnota tohoto principu spočívá v tom, že uvolňuje spojení mezi jediným softwarem a kódem. Přidání více než jedné funkce do třídy zavádí vztah mezi těmito dvěma funkcemi. Pokud tedy změníte jednu z nich, existuje velká šance zkazit druhou, související s první. A to znamená zvýšení testovacích cyklů, aby se všechny problémy identifikovaly předem.
Princip inverze závislosti (DIP)
Výše uvedené je příklad kódu, kde AppManager závisí na EventLogWriter, který zase úzce souvisí s AppManager. Pokud potřebujete jiný způsob zobrazení oznámení, ať už je to push, SMS nebo e-mail, musíte změnit třídu AppManager.
Problém lze vyřešit pomocí DIP. Místo AppManageru tedy požadujeme EventLogWriter, který bude vložen pomocí frameworku.
DIP umožňuje snadnou výměnu jednotlivých modulů za jiné změnou modulu závislostí. To umožňuje změnit jeden modul, aniž by to ovlivnilo ostatní.
Složení místo dědictví
Dva hlavní způsoby opětovného použití kódu jsou dědičnost a složení, z nichž každý má své výhody a nevýhody. Druhý je obvykle preferován, protože je flexibilnější.
Composition vám dává možnost změnit chování třídy za běhu nastavením jejích vlastností. Při implementaci rozhraní se používá polymorfismus, který poskytuje flexibilnější implementaci.
Dokonce i "Effective Java" Joshua Bloch radí upřednostňovat kompozici před dědičností.
Barbara Liskov substituční princip (LSP)
Další princip ze sady nástrojů SOLID. Uvádí, že podtypy musí 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ů pracovat s jejími podtřídami.
LSP souvisí jak s principem jednotné odpovědnosti, tak s principem oddělení odpovědnosti. Pokud třída poskytuje více funkcí než podtřída, podtřída nebude podporovat některé funkce, což porušuje tento princip.
Zde je část kódu, která je v rozporu s LSP.
Metoda area(Rectangle r) vypočítá plochu obdélníku. Po provedení Square se program zhroutí, protože zde Square 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 specifickou definicí podtypu, navrhla Barbara Liskov v roce 1987 na konferenci nazvané „Data Abstraction and Hierarchy“ – odtud jeho název.
Princip oddělení rozhraní (ISP)
Další SOLID princip. Rozhraní, které se nepoužívá, by se podle něj nemělo implementovat. Dodržování tohoto principu pomáhá systému zůstat flexibilní a refaktorovatelný při provádění změn v logice práce.
Nejčastěji tato situace nastává, když rozhraní obsahuje více funkcionalit najednou a klient potřebuje pouze jednu z nich.
Vzhledem k tomu, že psaní rozhraní je složitý úkol, po dokončení práce bude problém jej změnit, aniž by došlo k porušení.
Výhodou principu ISP v Javě je, že všechny metody musí být nejprve implementovány a teprve poté je mohou třídy používat. Princip proto umožňuje snížit počet metod.
Programování pro rozhraní, nikoli implementace
Zde je vše jasné z názvu. Použití tohoto principu vede k flexibilnímu kódu, který může pracovat s jakoukoli novou implementací rozhraní.
Měli byste použít typ rozhraní pro proměnné, návratové typy nebo typ argumentu metody. Příkladem je použití SuperClass spíše než SubClass.
Tj:
Seznam čísel= getNumbers();
Ale ne:
ArrayList čísla = getNumbers();
Zde je praktická implementace toho, co bylo řečeno výše.
Princip delegování
Běžným příkladem jsou metody equals() a hashCode() v Javě. Když je třeba porovnat dva objekty, je tato akce delegována na příslušnou třídu namísto třídy klienta.
Výhodou principu je, že nedochází k duplicitě kódu a lze poměrně snadno změnit chování. Platí to i pro delegování akce.
Všechny tyto principy vám umožňují psát flexibilnější, krásnější a spolehlivější kód s vysokou soudržností a nízkou vazebností. Teorie je samozřejmě dobrá, ale aby vývojář začal získané znalosti skutečně využívat, je potřeba praxe. Dalším krokem po zvládnutí 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 .
- Dvouletý praktický kurz .
Zdroj: www.habr.com