Принцип інверсії залежностей в деталях 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Принцип інверсії залежностей в деталях



У протиставленні поганому дизайну, гарний дизайн архітектури повинен бути гнучким, стійким, і пристосованим до повторного використання. Чим нижче взаємозв'язок компонентів додатка один з одним, тим вища гнучкість і мобільність всієї програми в цілому. Програми, що характеризуються високим коефіцієнтом мобільності, дозволяють застосовувати свої компоненти знову і знову для вирішення однотипних задач. Це веде до зниження дублювання коду. Такі програми складаються з великого набору досить дрібних компонентів, кожен з яких виконує малу частину роботи, але виконує її якісно. Дрібні компоненти набагато простіше тестувати, реалізовувати і супроводжувати.

Якщо ви дотримуєтеся принцип інверсії залежностей, то ваш код більш пристосований до змін і менше залежить від контексту виконання. Вірно і зворотне твердження. Якщо ваш додаток є хорошим прикладом вдалого дизайну архітектури, то він, в тій чи іншій мірі, дотримується принципу інверсії залежностей.

Суть принципу
1. Модулі верхнього рівня не повинні залежати від модулів нижнього рівня. Обидва типи модулів повинні залежати від абстракцій;
2. Абстракція не повинна залежати від реалізації. Реалізація повинна залежати від абстракції.

Традиційні методи розробки (наприклад, процедурне програмування) мають тенденцію до створення коду, в якому високорівневі модулі, як раз, залежать від низькорівневих. Це відбувається через те, що одна з цілей цих методів розробки - визначення ієрархії підпрограм, а отже і ієрархії викликів усередині модулів (високорівневі модулі викликають низькорівневі). Саме це є причиною низької гнучкості і закостенілості дизайну. При правильному використанні, ГО методики дозволяють обійти це обмеження.

Розглянемо приклад програми, яка копіює в файл дані, введені з клавіатури.

У нас є три модулі (у даному випадку це функції). Один модуль (іноді його називають сервіс) відповідає за читання з клавіатури. Другий - за виведення у файл. А третій високорівневий модуль об'єднує два низькорівневих модуля з метою організації їх роботи.


Наш модуль copy може виглядати приблизно так.
while (($ data = readKeyboard ())! == false)
{
writeFile (". / filename", $ data);
}
Низькорівневі модулі readKeyboard і writeFile володіють високою гнучкістю. Ми легко можемо використовувати їх у контексті відмінному від функції copy. Проте сама функція «copy» не може бути повторно використана в іншому контексті. Наприклад, для відправки даних з файлу системного оброблювача логів.
Використовуючи принцип інверсії залежностей, можна зробити модуль copy незалежним від об'єктів джерела і призначення даних. Для цього необхідно виробити абстракції для цих об'єктів, і зробити модулі залежними від цих абстракцій, а не один від одного.


interface IReader
{
public function read ();
}

interface IWriter
{
public function write ($ data);
}
Модуль copy повинен покладатися тільки на вироблені абстракції і не робити ніяких припущень з приводу індивідуальних особливостей об'єктів вводу / виводу.
while (($ data = $ reader-> read ())! == false)
{
$ Writer-> write ($ data);
}
Приблизно таким чином виглядає використання нашого модуля користувачем.
$ Copier = new copier ();

/ / Копіювання даних з клавіатури в файл
$ Copier-> run (new keyboardReader (), new fileWriter ('. / Filename'));

/ / Надсилання даних з файлу системного оброблювача логів
$ Copier-> run (new fileReader ('. / Filename'), new syslogWriter ());
Тепер модуль copy можна використовувати в різних контекстах копіювання. Зміна поведінки модуля-копіювальника досягається шляхом асоціації його з об'єктами інших класів (але які залежать від тих же абстракцій).
Незважаючи на простоту виконаних нами дій ми отримали дуже важливий результат. Тепер наш код володіє наступними якостями:
• модуль може бути використаний для копіювання даних в контексті відмінному від даного;
• ми можемо додавати нові пристрої введення / виведення не змінюючи при цьому модуль copy.
Таким чином, знизилася крихкість коду, підвищилася його мобільність і гнучкість.

Повторне використання коду

Повторне використання коду (англ. code reuse) - методологія проектування комп'ютерних та інших систем, що полягає в тому, що система (комп'ютерна програма, програмний модуль) частково або повністю повинна складатися з частин, написаних раніше компонентів і / або частин іншої системи. Повторне використання - основна методологія, яка застосовується для скорочення трудовитрат при розробці складних систем.

Найпоширеніший випадок повторного використання коду - бібліотеки програм. Бібліотеки надають загальну досить універсальну функціональність, яка покриває обрану предметну область. Приклади: Бібліотека функцій для роботи з комплексними числами, бібліотека функцій для роботи з 3D-графікою, бібліотека для використання протоколу TCP / IP, бібліотека для роботи з базами даних. Розробники нової програми можуть використовувати існуючі бібліотеки для вирішення своїх завдань.

Повторне використання коду за межами одного проекту практично неможливо, якщо у вас немає розробленого проектного каркаса [framework]. У різних проектах різні набори сервісів, що і ускладнює повторне використання об'єкта.

Розробка проектного каркаса віднімає багато сил і часу. Але навіть якщо з якихось причин ви не створили собі подібної системи, існує декілька прийомів заохочення повторного використання коду.

Framework-системи

Вступ

Що таке framework-система? Навіщо вона Вам потрібна? У чому вона Вам може допомогти? А в чому ні? У цьому документі я спробую дати відповіді на ці питання.

Інтернет технології за останні десять років зробили дуже великий крок вперед, ставши полігоном для ведення бізнесу та електронної комерції. Розвиток глобальної мережі спричинило за собою розвиток інтернет-додатків. Якщо раніше сайти були не більше ніж «оголошеннями на заборі», то тепер це повноцінні програми, здатні виконувати завдання по автоматизації збору даних, обробки даних та надання інформації.

Перед сучасними web-розробниками постає дуже широкий спектр завдань. Це ефективна робота з реляційними базами даних, зберігання і обробка даних у форматі XML, побудова гнучких систем відображення інформації та багато іншого. Така множина завдань робить старі методи розробки додатків вкрай неефективними. Це призводить до думки про необхідність наявності спеціального інструментарію для web-розробника, який допоможе йому у вирішенні часто виникаючих проблем і завдань.

Отже, що таке framework?

Коли людина вирішує якесь завдання багато разів поспіль, він вчиться вирішувати її швидко і ефективно! З точки зору web-програмування, framework-система (CMF-система) це платформа, що дозволяє вирішувати завдання, які постійно виникають при створенні інтернет-додатків. Не варто думати, що CMF-система - це просто набір модулів для вирішення різнотипних завдань, яких в Інтернеті безліч. Framework-система це щось більше. Це:
• Термінологія, яка дозволяє розробникам говорити лаконічно про дуже складні речі;
• Набір архітектурних стандартів, які система накладає на інтернет-додатки. Це знімає з розробників необхідність придумувати все з нуля і дозволяє більш ефективно використовувати код повторно;
• Модулі для вирішення завдань «першої необхідності», що дозволяють почати розробку з порожнього місця, не винаходячи нічого свого.

Framework-система для web-розробника відіграє таку ж роль, як саквояж з інструментами для монтажника. Навіть якщо монтажник зможе виконати свою роботу без свого саквояжа, він витратить більше часу, а якість виконаної роботи буде на порядок нижче. Аналогічна ситуація спостерігається в процесі створення інтернет-додатків.

CMF і CMS

Розглядаючи поняття framework-системи, не можна обійти стороною, поняття системи управління контентом. Дуже часто поняття CMF (Content Management Framework) плутають з поняттям CMS (Content Management System). Це невірно, тому що це принципово різні речі.

CMF-системи не можна порівнювати з CMS-системами! Це головне правило, яке дуже часто порушують розробники при обговоренні питань пов'язаних з розробкою та використанням CMF-систем. CMF і CMS різні поняття, незважаючи на їх схожість.

CMS-система - це набір модулів для швидкого створення сайтів. На відміну від CMF, CMS-система - це є завершений продукт, який орієнтований, в першу чергу, не на програмістів, а на користувачів не знайомих з премудростями створення інтернет-додатків. CMS-система (дуже часто її називають «движок сайту») дозволяє за лічені години створити сайт або портал який складається з обмеженого набору готових модулів (новини, гостьова книга, форум). В більшості своїй, CMS-системи створюються без урахування їх подальшого зростання. Підсумок - відсутність жорсткої внутрішньої архітектури системи. Це істотно ускладнює процес супроводження проекту.

Якщо вам достатньо можливостей CMS-системи, то, швидше за все, Ви будете задоволені. Однак якщо перед Вами постане питання про зміну дизайну або розширення можливостей програми, то, в більшості випадків, Вам доведеться вдатися за допомогою до кваліфікованих програмістів. І, можливо, навіть їм буде не просто розібратися в цій CMS-системі. Прочитавши наступний параграф, Ви зрозумієте, чому в цьому абзаці так багато «можливо» і «швидше за все».

Вищесказане відноситься до «чистих» CMS-систем. Тобто до CMS-систем, які написані з нуля на порожньому місці. На щастя, ніхто не заважає використовувати вигоди обох типів систем. Останнім часом в Інтернеті почали з'являтися CMF / CMS-системи. Ці системи являють собою CMS-систему, створену на фундаменті framework'а. Вигоди очевидні. Детермінована внутрішня архітектура, яка в більшості випадків документована і розвинені механізми абстракції, які не залежать від CMS-утворюючих модулів. Супроводжувати проект, створений на основі CMF / CMS-системи, на порядок простіше, ніж проект, створений на основі «чистої» CMS-системи. Це пояснюється тим, що в першому випадку, при створенні CMS-системи, програмістам доводиться виконувати ряд вимог, які диктує framework. Завдяки цьому CMS-система набуває яскраво виражену архітектуру, як і всі додатки створюються за допомогою CMF-системи.

Якщо CMS-система являє собою закінчений продукт, то CMF-система - це набір інструментів, за допомогою яких, можна створити абсолютно будь-який продукт, зокрема і CMS-систему. Так як framework-система - це набір інструментів, то для її використання потрібні програмісти, які можуть з цими інструментами працювати. З цим пов'язаний ще один момент, характерний для CMF - навчання персоналу для роботи з CMF-системою.

Продукти CMF-системи (додатки, написані на її основі) відрізняються індивідуальністю та високим рівнем адаптації до конкретної ситуації, тому що вони є програмними рішеннями, призначеними для вирішення конкретного кола завдань у конкретному контексті. За допомогою CMF можна створювати будь-які інтернет-додатки, починаючи гостьовими книгами, закінчуючи інтернет-магазинами і веб-сервісами.

Маючи фахівців, які знають архітектуру використовуваної CMF-системи, стає можливим, відносно легко, розширювати можливості системи, проводити аудити безпеки і т.д.

Архітектура CMF-системи

У попередніх розділах вже було сказано дуже багато про архітектуру. Вам може здатися, що архітектурні стандарти абсолютно не потрібні. Але необхідно розуміти, що подібна «диктатура» не має на меті обмеження програміста у прийнятті рішень. Навпаки це зроблено для забезпечення максимальної гнучкості архітектури та можливості її безболісної зміни. Безумовно, в жертву таким якостям доводиться приносити простоту та прозорість системи.

Питання архітектури дуже складні за своєю суттю, і навіть багато фахівців не можуть сказати за п'ять хвилин нічого зрозумілого із приводу якихось конкретних рішень. Але, незважаючи на таку велику контекстну залежність архітектури від типу додатка, існують добре вивчені і перевірені варіанти вирішення архітектурних проблем. Ці варіанти рішення носять назву «шаблони проектування» (Design Patterns). У тому чи іншому вигляді шаблони проектування можуть бути застосовані у всіх додатках. Виявлення оптимальних реалізацій шаблонів становить невід'ємну частину роботи над framework-системою (я б сказав, що справжня framework-система просякнута духом патернів проектування).

Шаблони проектування існують для всіх основних типів завдань, що виконуються CMF-системою. Рішення цих завдань вимагають продуманої стандартизації (зрозуміло, в рамках проекту). Таких завдань декілька:
• Обробка запиту ІС 1);
• Організація предметної області ІВ;
• Організація подання ІС;
• Організація допоміжних підсистем;

Завдання, які я виділив, занадто умовні, що б вважати їх формальним списком завдань framework-системи. Цей список наведений, що б Ви могли зрозуміти, в яких напрямках розробники концентрують свої зусилля.

Обробка запиту

Підсистема обробки запиту зіставляє запит клієнта з дією, що виконується системою. Запити до системи можуть бути досить «різношерстими». Вони відрізняються як по вигляду, так і за смисловим навантаженням. Це залежить від типу додатка. Самі механізми зіставлення і їх дії можуть змінюватися під час супроводження проекту. Ці вимоги диктують розробникам CMF-системи необхідність створення зручного механізму аналізу та обробки запитів. У разі якщо розробники справляються зі своїм завданням, то додатки, побудовані на базі їх framework-системи, будуть красивими і легко запам'ятовуються адресами кшталт «http://www.server.com/news/2005-02-03» замість «http: / / www.server.com/index.php?module=news&action=show&date=2005-02-03». Безумовно, краса запиту не єдине якість, якого домагаються розробники. Гнучкі механізми зіставлення запиту з дією грають дуже важливу роль, так це дуже зміна частина системи.



Поделиться:


Последнее изменение этой страницы: 2016-04-23; просмотров: 352; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 35.173.233.176 (0.181 с.)