streamalism.org

1. Úvod

V tomto výučbe sa budeme zaoberať princípom segregácie rozhraní, jedným z princípov SOLID. Zastúpenie „I“ v slove „SOLID“ znamená segregácia rozhraní jednoducho tak, že by sme mali rozdeliť väčšie rozhrania na menšie.

Takto sa zabezpečí, že implementačné triedy nemusia implementovať nežiaduce metódy.

2. Princíp segregácie rozhrania

Prvýkrát tento princíp definoval Robert C. Martin ako: „Klienti by nemali byť nútení závisieť od rozhraní, ktoré nepoužívajú“.

Cieľom tohto princípu je: znížiť vedľajšie účinky používania väčších rozhraní rozdelením aplikačných rozhraní na menšie. Je to podobné ako s princípom jednej zodpovednosti, kde každá trieda alebo rozhranie slúži na jediný účel.

Kľúčom za princípom segregácie rozhrania je presný dizajn aplikácie a správna abstrakcia. Aj keď to vo fáze návrhu aplikácie bude vyžadovať viac času a úsilia a môže to zvýšiť zložitosť kódu, nakoniec dostaneme flexibilný kód.

Pozrime sa na niektoré príklady v ďalších častiach, kde sme porušili princíp, a potom problém napravíme správnym uplatnením princípu.

3. Ukážkové rozhranie a implementácia

Pozrime sa na situáciu, keď máme Platba rozhranie použité implementáciou Banková platba:

verejné rozhranie Platba {void initiatePayments (); Stav objektu (); Zoznam getPayments (); }

A implementácia:

verejná trieda BankPayment implementuje platbu {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...}}

Pre jednoduchosť ignorujme skutočnú obchodnú implementáciu týchto metód.

To je veľmi jasné - zatiaľ implementačná trieda Banková platba potrebuje všetky metódy v Platba rozhranie. To teda neporušuje zásadu.

4. Znečisťovanie rozhrania

Teraz, keď postupujeme vpred a pribúdajú ďalšie funkcie, je potrebné pridať a Úverová platba služby. Táto služba je tiež druhom služby Platba ale má ešte niekoľko operácií.

Na vývoj tejto novej funkcie pridáme nové metódy do Platba rozhranie:

verejné rozhranie Platba {// originálne metódy ... void intiateLoanSettlement (); void initiateRePayment (); }

Ďalej budeme mať Úverová platba implementácia:

verejná trieda LoanPayment implementuje platbu {@Override public void initiatePayments () {hodiť novú UnsupportedOperationException ("Toto nie je banková platba"); } @Override public object status () {// ...} @Override public List getPayments () {// ...} @Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...}}

Teraz, pretože Platba rozhranie sa zmenilo a bolo pridaných viac metód, všetky implementačné triedy musia teraz implementovať nové metódy. Problém je v tom, že ich implementácia je nežiaduca a môže viesť k mnohým vedľajším účinkom. Tu je Úverová platba implementačná trieda musí implementovať initiatePayments () bez akejkoľvek skutočnej potreby. A teda je porušená zásada.

Čo sa teda stane s našimi Banková platba trieda:

verejná trieda BankPayment implementuje platbu {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...} @Override public void intiateLoanSettlement () {throw new UnsupportedOperationException ("Toto nie je splátka pôžičky"); } @Override public void initiateRePayment () {hodiť novú UnsupportedOperationException ("Toto nie je splátka pôžičky"); }}

Všimnite si, že Banková platba implementácia teraz implementovala nové metódy. A keďže ich nepotrebuje a nemá pre nich logiku, je len hádzanie UnsupportedOperationException. Tu začneme porušovať zásadu.

V nasledujúcej časti uvidíme, ako môžeme tento problém vyriešiť.

5. Uplatňovanie zásady

V poslednej časti sme zámerne znečistili rozhranie a porušili princíp. V tejto časti sa pozrieme na to, ako pridať novú funkciu splácania pôžičky bez porušenia tejto zásady.

Rozoberme si rozhranie pre každý typ platby. Súčasná situácia:

Všimnite si v schéme triedy a s odkazom na rozhrania v predchádzajúcej časti, že postavenie() a getPayments () v oboch implementáciách sú potrebné metódy. Na druhej strane, initiatePayments () sa vyžaduje iba v Banková platbaa initiateLoanSettlement () a initiateRePayment () metódy sú iba pre Úverová platba.

Keď to urobíme, poďme rozdeliť rozhrania a použijeme princíp segregácie rozhraní. Teraz teda máme spoločné rozhranie:

verejné rozhranie Platba {Object status (); Zoznam getPayments (); }

A ďalšie dve rozhrania pre dva typy platieb:

verejné rozhranie Banka rozširuje Platbu {void initiatePayments (); }

verejné rozhranie Pôžička predlžuje Platbu {void intiateLoanSettlement (); void initiateRePayment (); }

A príslušné implementácie, počnúc Banková platba:

verejná trieda BankPayment implementuje banku {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...}}

A nakoniec, náš revidovaný Úverová platba implementácia:

verejná trieda LoanPayment implementuje pôžičku {@Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...} @Override public object status () {// ...} @Override verejný zoznam getPayments () {// ...}}

Teraz sa pozrime na nový diagram tried:

Ako vidíme, rozhrania neporušujú tento princíp. Implementácie nemusia poskytovať prázdne metódy. To udržuje kód čistý a znižuje pravdepodobnosť výskytu chýb.

6. Záver

V tomto tutoriáli sme sa pozreli na jednoduchý scenár, kde sme sa najskôr odchýlili od dodržiavania princípu segregácie rozhraní a videli sme problémy, ktoré táto odchýlka spôsobovala. Potom sme si ukázali, ako správne uplatniť zásadu, aby sa zabránilo týmto problémom.

V prípade, že máme do činenia so znečistenými starými rozhraniami, ktoré nemôžeme upraviť, môže sa nám hodiť vzor adaptéra.

Princíp segregácie rozhrania je dôležitým konceptom pri navrhovaní a vývoji aplikácií. Dodržiavanie tohto princípu pomáha predchádzať nafúknutým rozhraniam s viacerými zodpovednosťami. To nám nakoniec pomáha dodržiavať zásadu jedinej zodpovednosti.

Ako vždy, kód je k dispozícii na GitHub.