Oriģinālliteratūra: “Principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details”.
Šis princips definē sekojošus noteikumus jeb likumus, kas būtu jāievēro:
- Augstākā līmeņa moduļiem nevajadzētu būt atkarīgiem no zemāka līmeņa moduļiem. Abiem moduļiem jābūt atkarīgiem no zināmām abstrakcijām.
- Abstrakcijām nav jābūt atkarīgām no detaļām. Detaļām jāzina par abstrakcijām.
Modernās sistēmās arhitektūra un klašu dizains ir veidots tā, lai augstāka līmeņa komponentes izmantotu zemāka līmeņa komponentes sava darba jeb problēmu apgabala risināšanai. Tas nodrošina zemāka līmeņa komponentēm ļauj būt atkārtoti izmantojamām, kas nozīmē, ka zemāka līmeņa komponentes jāveido tā, lai tām nebūtu informācijas un atkarība no augstāka līmeņa komponentēm jeb komponentes piedāvātās funkcionalitātes klientiem.
Savukārt šeit saskaramies ar nākamo problēmu, proti, kurš rūpēsies par augstākā līmeņa komponenšu atkārtotas izmantošanas iespējām? Ja augstākā līmeņa komponente ir tiešā veidā atkarīga no zemākā līmeņa komponentēs, tad ievērojami samazina augstākā līmeņa komponentes pielietošanu citās vietas un citās situācijās.
Šī principa galvenais mērķis ir atdalīt augstāka līmeņa komponenti no zināšanām par zemāka līmeņa komponentes detaļām un uzbūvi – tādā veidā radot labvēlīgus apstākļus augstākā līmeņa komponenti izmantot citās vietās vai situācijās.
Reālā dzīvē šī veida atdalīšana izskatās ļoti vienkārši un apmēram tiek realizēta sekojošā veidā:
- pirmkārt šāda veida atdalīšana sistēmās notiek fiziski – augstākā un zemākā līmeņa komponentes tiek novietotas dažādos moduļos vai bibliotēkās
- zemākā līmeņa komponentes uzvedība vai piedāvātā funkcionalitāte tiek reprezentēta kā interfeiss un parasti atrodas vai nu tajā pašā bibliotēkā, kur atrodas augstākā līmeņa komponente vai arī tiek izdalīta speciāla bibliotēka speciāli paredzēta šāda veida abstrakciju uzglabāšanai
- lai zemākā līmeņa komponente piedāvātu augstākā līmeņa komponentei nepieciešamo funkcionalitāti, tai ir jābūt atkarīgai no augstākā līmeņa komponentes, ja interfeiss ir definēts tajā modulī vai arī uz kādu speciāli izdalītu bibliotēku
- tādā veida atkarības saites tiek pagrieztas otrādāk jeb invertētas – augstākā līmeņa komponente vairs nav atkarīga no zemākā līmeņa komponentes.
Vēlāk jau runtime laikā tiek izmantoti daudzi dažādi patterni (Plugin, Dependency Injection, Service Locator), kādā veidā platforma vai sistēma piemeklē zemāka līmeņa komponentes nepieciešamajām augstākā līmeņa komponentēm.
Šim nolūkam, protams, var rakstīt savu ietvaru (angl. framework), bet .Net pasaulē jau eksistē daudz dažādas sistēmas un bibliotēkas, kas piedāvā izstrādātājiem jau gatavus risinājumus. Populārākās no dažām tikai: SpringFramework.Net, Microsoft Extensibility Framework (MEF), Enterprise Library Unity Block, StructureMap.
Citiem vārdiem sakot, Dependency Inversion Prnciple dažkārt jauc ar Inverse of Control principu, kas arī nav nejaušība. Abi šie principi eksistē un runā gandrīz par vienu un to pašu – kādā veidā efektīvāk atdalīt komponentes savā starpā, lai mazinātos nepieciešamās neatkarības saites un vienkāršotu kopējo sistēmas arhitektūru.
Šoreiz iztiksim bez nevienas koda rindiņas :)
Bet vispārīgi, ceru, ka princips tapa skaidrāks. Ja mēs redzam, ka lietām būtu jābūt nesaistītām, savstarpēji neatkarīgākām, tad šādos gadījumos starp abām komponentēm, starp kurām ir izcēlies kariņš un notiek vainīgo galvas skalošana, tiek definēts interfeiss, kas regulē abas puses: to, ko augstākā līmeņa komponente sagaida no zemākā līmeņa komponentes un ko zemākā līmeņa komponente var piedāvāt augstākā līmeņa komponentei.
Kā jau to pieminēju “Interface Segragation Principle” rakstā, interfeiss šeit nav domāts tikai ar klašu interfeisu. Interfeiss var būt arī cita klase, kas dod iespēju saviem klientiem iegūt vajadzīgo joy, piedāvājot tieši to funkcionalitāti, kas nepieciešama augstākā līmeņa darbībai.
Cerams, ka noderēs!
Pārējie raksti SOLID sērijā: