ProHoster > Blog > internetové správy > 10 princípov objektovo orientovaného programovania, ktoré by mal poznať každý vývojár
10 princípov objektovo orientovaného programovania, ktoré by mal poznať každý vývojár
Pomerne často sa stretávam s vývojármi, ktorí nepočuli o princípoch SOLID (my podrobne o nich hovoril tu. — Preklad) alebo objektovo orientované programovanie (OOP), alebo ste o nich počuli, ale v praxi ich nepoužívate. Tento článok popisuje výhody princípov OOP, ktoré pomáhajú vývojárovi v jeho každodennej práci. Niektoré z nich sú dobre známe, iné nie toľko, takže článok bude užitočný pre začiatočníkov aj skúsených programátorov.
Pripomíname vám:pre všetkých čitateľov Habr - zľava 10 000 rubľov pri registrácii do akéhokoľvek kurzu Skillbox pomocou propagačného kódu Habr.
Pomerne jednoduchý princíp, ktorého podstata je jasná už z názvu: „Neopakuj sa“. Pre programátora to znamená nutnosť vyhnúť sa duplicitnému kódu, ako aj možnosť využiť pri svojej práci abstrakciu.
Ak sú v kóde dve opakujúce sa časti, mali by sa spojiť do jednej metódy. Ak sa pevne zakódovaná hodnota použije viackrát, oplatí sa previesť ju na verejnú konštantu.
Je to potrebné na zjednodušenie kódu a jeho ľahšiu údržbu, čo je hlavným cieľom OOP. Nemali by ste zneužívať ani spojenie, pretože rovnaký kód neprejde overením s OrderId aj SSN.
Zapuzdrenie zmien
Softvérové produkty väčšiny spoločností sa neustále vyvíjajú. To znamená, že je potrebné vykonať zmeny v kóde, je potrebné ho podporovať. Pomocou zapuzdrenia si môžete uľahčiť život. To vám umožní efektívnejšie testovať a udržiavať vašu existujúcu kódovú základňu. Tu je jeden príklad.
Tento princíp si možno ľahko zapamätať prečítaním si nasledujúceho výroku: „Softvérové entity (triedy, moduly, funkcie atď.) by mali byť otvorené pre rozšírenie, ale zatvorené pre modifikácie.“ V praxi to znamená, že môžu dovoliť zmenu svojho správania bez zmeny zdrojového kódu.
Princíp je dôležitý, keď zmeny zdrojového kódu vyžadujú revíziu kódu, testovanie jednotiek a iné postupy. Kód, ktorý sa riadi princípom otvorený/zatvorený, sa pri rozšírení nemení, takže je s ním oveľa menej problémov.
Tu je príklad kódu, ktorý porušuje túto zásadu.
Ak v ňom potrebujete niečo zmeniť, bude to trvať veľa času, pretože sa budú musieť zmeniť všetky časti kódu, ktoré majú spojenie s požadovaným fragmentom.
Mimochodom, otvorenosť-uzavretosť je jedným z princípov SOLID.
Princíp jednotnej zodpovednosti (SRP)
Ďalší princíp zo sady SOLID. Uvádza, že „existuje len jedna príčina, ktorá spôsobuje zmenu v triede“. Trieda rieši len jeden problém. Môže mať niekoľko metód, ale každá z nich sa používa len na riešenie bežného problému. Všetky metódy a vlastnosti by mali slúžiť len tomuto.
Hodnota tohto princípu je v tom, že uvoľňuje spojenie medzi jednotlivými softvérovými komponentmi a kódom. Ak do triedy pridáte viac ako jednu funkciu, vytvorí sa vzťah medzi týmito dvoma funkciami. Ak teda zmeníte jednu z nich, je veľká šanca, že zničíte druhú, ktorá je spojená s prvou. A to znamená zvýšenie testovacích cyklov s cieľom identifikovať všetky problémy vopred.
Princíp inverzie závislosti (DIP)
Vyššie je uvedený príklad kódu, kde AppManager závisí od EventLogWriter, ktorý je zase úzko spojený s AppManager. Ak potrebujete iný spôsob zobrazenia upozornenia, či už push, SMS alebo e-mail, musíte zmeniť triedu AppManager.
Problém je možné vyriešiť pomocou DIP. Takže namiesto AppManager požadujeme EventLogWriter, ktorý bude zadaný pomocou frameworku.
DIP umožňuje jednoduchú výmenu jednotlivých modulov za iné zmenou modulu závislostí. To umožňuje zmeniť jeden modul bez ovplyvnenia ostatných.
Zloženie namiesto dedičstva
Existujú dva hlavné spôsoby opätovného použitia kódu: dedenie a zloženie, pričom oba majú svoje výhody a nevýhody. Zvyčajne sa uprednostňuje druhý, pretože je flexibilnejší.
Kompozícia vám dáva možnosť zmeniť správanie triedy za behu nastavením jej vlastností. Pri implementácii rozhraní sa používa polymorfizmus, ktorý poskytuje flexibilnejšiu implementáciu.
Dokonca aj Effective Java od Joshuu Blocha radí uprednostniť kompozíciu pred dedičnosťou.
Barbara Liskov substitučný princíp (LSP)
Ďalší princíp zo sady nástrojov SOLID. Uvádza, že podtypy musia byť zameniteľné za nadtyp. To znamená, že metódy a funkcie, ktoré pracujú s nadtriedou, by mali byť schopné bez problémov pracovať s jej podtriedami.
LSP sa spája so zásadou jednotnej zodpovednosti a zásadou spoločnej zodpovednosti. Ak trieda poskytuje viac funkcií ako podtrieda, potom podtrieda nebude podporovať niektoré funkcie, čo porušuje tento princíp.
Tu je časť kódu, ktorá je v rozpore s LSP.
Metóda area(Rectangle r) vypočítava plochu obdĺžnika. Po vykonaní Square sa program zrúti, pretože tu nie je štvorec obdĺžnik. Podľa princípu LSP by funkcie, ktoré používajú odkazy na základné triedy, mali byť schopné používať objekty odvodených tried bez ďalších inštrukcií.
Tento princíp, ktorý je špecifickou definíciou podtypu, navrhla Barbara Liskov v roku 1987 v kľúčovom prejave konferencie s názvom „Abstrakcia údajov a hierarchia“, odtiaľ pochádza aj jeho názov.
Princíp oddelenia rozhrania (ISP)
Ďalší pevný princíp. Podľa nej by sa nemalo implementovať rozhranie, ktoré sa nepoužíva. Dodržiavanie tohto princípu pomáha systému zostať flexibilný a vhodný na refaktoring, keď sa vykonajú zmeny v prevádzkovej logike.
Najčastejšie k tejto situácii dochádza, keď rozhranie obsahuje niekoľko funkcií naraz a klient potrebuje iba jednu z nich.
Keďže napísanie rozhrania je náročná úloha, zmeniť ho po dokončení práce bez toho, aby ste niečo porušili, bude výzvou.
Výhodou princípu ISP v Jave je, že všetky metódy musia byť najskôr implementované a až potom ich môžu používať triedy. Preto princíp umožňuje znížiť počet metód.
Programovanie pre rozhranie, nie implementáciu
Všetko je tu jasné už z názvu. Uplatnenie tohto princípu vedie k vytvoreniu flexibilného kódu, ktorý dokáže spolupracovať s akoukoľvek novou implementáciou rozhrania.
Pre premenné, návratové typy alebo typ argumentu metódy by ste mali použiť typ rozhrania. Príkladom je použitie SuperClass namiesto SubClass.
To jest:
Vypísať čísla= getNumbers();
Ale nie:
Čísla ArrayList = getNumbers();
Tu je praktická implementácia vyššie uvedeného.
Princíp delegovania
Bežným príkladom sú metódy equals() a hashCode() v jazyku Java. Keď je potrebné porovnať dva objekty, táto akcia sa deleguje na zodpovedajúcu triedu namiesto klientskej triedy.
Výhodou princípu je, že nedochádza k duplicite kódu a je relatívne jednoduché zmeniť správanie. Platí to aj pre delegovanie podujatia.
Všetky tieto princípy vám umožňujú písať flexibilnejší, krajší a spoľahlivejší kód s vysokou súdržnosťou a nízkou väzbou. Samozrejme, teória je dobrá, ale na to, aby vývojár skutočne využil nadobudnuté vedomosti, je potrebná prax. Keď si osvojíte princípy OOP, ďalším krokom môže byť naučiť sa návrhové vzory na riešenie bežných problémov s vývojom softvéru.