Bog’liqlik Inversiyasi tamoyili
Prinsiplar +1 06.08.2023 293

 Bog'liqlik Inversiyasi tamoyili - Wikipedia

Yuqori darajadagi modullar past darajadagi ilovalarga bog'liq bo'lmasligi kerak.

"SOLID" tamoyillarining beshinchisi. Ushbu tamoyil yuqori darajadagi orkestrlash komponentlari o'zlarining bog'liqliklari tafsilotlarini bilishlari shart emasligini bildiradi.

Misol tariqasida, bizda veb-saytdagi metama'lumotlarni o'qiydigan dastur borligini tasavvur qiling. Biz asosiy komponent veb-sahifa tarkibini yuklab olish uchun komponent, so'ngra metama'lumotlarni o'qiy oladigan komponent haqida bilishi kerak deb taxmin qilamiz. Agar biz qaramlik inversiyasini hisobga oladigan bo'lsak, asosiy komponent faqat bayt ma'lumotlarini oladigan mavhum komponentga, keyin esa bayt oqimidan metama'lumotlarni o'qiy oladigan mavhum komponentga bog'liq bo'ladi. Asosiy komponent TCP/IP, HTTP, HTML va boshqalar haqida bilmaydi.

Bu tamoyil murakkab, chunki u tizimning kutilayotgan bog'liqliklarini (shuning uchun nomini) «invertatsiya qilish» kabi ko'rinishi mumkin. Amalda, bu, shuningdek, alohida orkestrlash komponenti mavhum turlarning to'g'ri bajarilishini ta'minlashi kerakligini anglatadi (masalan, oldingi misolda, metadata o'quvchi komponentini hali ham HTTP faylni yuklab oluvchi va HTML meta tegini o'quvchi bilan ta'minlashi kerak). Keyin bu Boshqaruvning Inversiyasi va Qaramlik in'ektsiyasi kabi naqshlarga to'g'ri keladi.

Shuningdek qarang:

The Dependency Inversion Principle
Prinsiplar +1 06.08.2023 293

The Dependency Inversion Principle on Wikipedia

High-level modules should not be dependent on low-level implementations.

The fifth of the 'SOLID' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies.

As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.

This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, something must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as Inversion of Control and Dependency Injection.

See also: