Вікіпедія

Аспектно-орієнтоване програмування: відмінності між версіями

Інтерактивний перегляд історії
[неперевірена версія][неперевірена версія]
← Попереднє редагуванняНаступне редагування →
Вилучено вміст Додано вміст
ВізуальнийВікірозмітка
Maksshal (обговорення | внесок)
15 редагувань
мНемає опису редагування
Maksshal (обговорення | внесок)
15 редагувань
мНемає опису редагування
Рядок 3:
 
==Мета створення==
Сучасні програмні системи часто вирішують величезну кількість надскладних завдань, що потребуєпотребують хороших інженерних навичок від їх розробників та надійності інструментальних засобів розробки. При зростанні складності таких систем зростає і програмний код, розробнику стає все важче охопити всі деталі реалізації системи. При підтримці великих програмних засобів зростає час знаходження та виправлення помилки, ускладнюється додавання нових характеристик, оскільки стає все важче визначити наскільки зміни вплинуть на систему, чи не внесуть додаткові помилки та дефекти. Для вирішення таких завдань застосовують різноманітні інженерні засоби, як от багатофункціональні [[Інтегроване Середовище Розробки|середовища розробки]], [[Шаблони проектування програмного забезпечення|шаблони проектування]], готові програмні [[Фреймворк|каркаси]] тощо.
<br />
Часто згадуваним недоліком [[Об'є́ктно-орієнто́ване програмува́ння|об’єктно-орієнтованого]] підходу є неможливість локалізації наскрізної функціональності в одному класі<ref>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.4987&rep=rep1&type=pdf</ref>. Як приклад такоютакої функціональності часто називають необхідність ведення журналів подій, керування винятковими ситуаціями, перевіркаперевірку прав доступу. Код, що відповідає за дану функціональність, часто розкиданий по різних класах. Це, з одного боку, не дозволяє сконцентрувати увагу на основній бізнес-логіці класу і ускладнює читання коду. З іншого боку, ускладнюється внесення змін у методи роботи наскрізної функціональності, що не завжди можна виправити правильним використанням інтерфейсів чи шаблонів проектування. Наразі аспектно-орієнтований підхід часто використовують для реалізації вищенаведених прикладів, проте, як зауважують деякі автори<ref>http://www.ibm.com/developerworks/ru/library/j-aopwork15/</ref>, на цьому сфера застосування аспектно-орієнтованого підходу не обмежуються, оскільки він може бути використаний для проектування будь-яких систем, що містять наскрізну функціональність.
<br />
В результаті наявності зайвої перехресної функціональності розроблюваний модуль містить заплутаний код, що задовольняє різні програмні вимоги. Негативні властивості такого коду<ref>http://www.nbuv.gov.ua/portal/natural/pitu/2009_2/content/archive/40-47.pdf</ref>:
* Розкиданий код. Оскільки наскрізна функціональність зачіпає багато модулів системи, то й виклики цієї функціональності будуть розкидані по всій системі. Наприклад, якщо програма містить засоби моніторингу продуктивності роботи з базою даних, то й виклики цієї функціональності будуть розміщені всюди, де потрібно працювати з базою даних. Наявність розкиданого коду має негативний вплив на проектування та реалізацію системи;
* Важкість відслідковування призначення модуля, оскільки він містить одночасно функціональність для задоволення різних вимог;
* Складність або неможливість повторного використання модуля у програмах з іншою наскрізною функціональністю;
* Велика ймовірність помилок. Наявність коду для реалізації функціональності різного роду в одному модулі може призвести до того, що жодне із завдань не отримає достатньої уваги розробника;
* Важкість супроводу. Якщо з’являєтьсяз'являється необхідність у зміні наскрізною функціональності, така зміна зачіпає багато модулів системи, що в кінцевому рахунку може призвести до проблем сумісності.
Для вирішення завдання локалізації наскрізної функціональності була розроблена методологія аспектно-орієнтованого програмування (АОП). Основні ідеї АОП були сформульовані ідеологом методології Г.&nbsp;Кінжалесом<ref>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.4987&rep=rep1&type=pdf</ref>. Він також розробив найбільш популярну надбудову мови програмування [[Java]] для роботи з аспектами – [[AspectJ]].
Наразі її часто використовують для реалізації наведених прикладів, проте, як зауважують деякі автори, на цьому сфера застосування аспектно-орієнтованого підходу не обмежуються, оскільки він може бути використаний для проектування будь-яких систем, що містять наскрізну функціональність.
 
==Основні поняття==
До основних понять аспектно-орієнованого програмування належать<ref>http://www.nbuv.gov.ua/portal/natural/pitu/2009_2/content/archive/40-47.pdf</ref>:
* Аспект (aspect) -— модуль або клас, який реалізує наскрізну функціональність. Аспект змінює поведінку іншого коду, застосовуючи поради в точках з'єднання, визначених деяким зрізом;
* Порада (advice) -— додаткова логіка -, код, який повинен бути викликаний з точки з'єднання. Порада може бути виконана до, після або замість точки з'єднання;
* Точка з'єднання (join point) -— точка в виконуваній програмі (виклик методу, створення об'єкта, звернення до змінної), де слід застосувати пораду;
* Зріз (pointcut) -— набір точок з'єднання. Зріз визначає, чи підходить дана точка з'єднання до заданої поради;
* Впровадження (introduction) -— зміна структури класу та/або зміна ієрархії успадкування для додавання функціональності аспекту в чужорідний код;
* Мета (target) -— об'єкт, до якого будуть застосовуватися порадапоради;
* Переплетення (weaving) -— зв'язування об'єктів з відповідними аспектами (можливоможливе на етапі компіляції, завантаження або виконання програми).
==Переваги використання==
Аспектно-орієнтований підхід розглядає програмну систему як набір модулів, кожен з яких виражає особливість функціонування системи. При проектуванні системи розробник вибирає модулі так, щоб кожен із них реалізовував певну функціональну вимогу. Натомість в рамках об'єктно-орієнтованого підходу реалізація деяких вимог до програми часто не може бути локалізована в окремому модулі, в результаті чого код, що відображає такі функціональні завдання, буде знаходитись у різних модулях (наприклад, код ведення журналу подій).<br />
Рядок 32 ⟶ 31:
* Загальне число операторів в програмі;
* Загальне число операндів в програмі.
Друга найбільш інформативна група оцінок складності програм –— метрики складності потоку управління програм. Як правило, за допомогою цих оцінок оперують або щільністю управляючихкерівних переходів усередині програм, або взаємозв'язками цих переходів.
<br />
В результаті проведених досліджень на основі розробки системи авторизації з використанням аспектно-орієнтованого підходу встановлено, що метрики коду в цілому на 10–40% нижче ніж в ООП реалізації, що позитивним чином впливає на систему, оскільки на кожну метрику (ресурс) буде витрачено менше часу.
 
==Способи застосування==
Використання аспектно-орієнтованого підходу не вимагає повністю відмовитись від об’єктно-орієнтованої реалізації, оскільки його можна впроваджувати лише частково. Більше того, такий підхід ефективно доповнює об’єктнооб'єктно-орієнтований код. Як показують дослідження аспектно-орієнтованих програм<ref>http://www.jot.fm/issues/issue_2010_01/article2.pdf</ref>, близько 2% їх коду пов’язанапов'язана з специфічними механізмами мови аспектно-орієнтованого програмування (наприклад, AspectJ); 12% - з базовими механізмами; 86% є об’єктнооб'єктно-орієнтованим.
<br />
Саме тому існують роботи по вдосконаленню програмних каркасів (frameworks) за допомогою технології аспектів<ref>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2696&rep=rep1&type=pdf</ref>. Об’єктноОб'єктно-орієнтований програмний каркас містить компоненти, що становлять ядро функціонування та компоненти, що містять додаткову функціональність. При використанні фреймворку стандартна функціональність розширюється за допомогою наслідування. Застосування аспектно-орієнтованого підходу дозволяє, з одного боку, розділити на окремі модулі наскрізну функціональність ядра, з іншого боку –— легко додавати функціональність використовуючи аспекти ядра.
<br />
Ефективно можна застосовувати аспектно-орієнтоване програмування для оптимізації шаблонів проектування<ref>http://www.ibm.com/developerworks/ru/library/j-aopwork5/</ref>. Першою значною перевагою є здатність локалізувати код шаблону проектування в одному аспекті або парі тісно пов’язанихпов'язаних аспектів (на відміну від мови Java, де код шаблону може бути розкиданим по багатьом класам). Можливість бачити весь код в одному місці має ряд суттєвих переваг:
* Читачі коду можуть легше зрозуміти шаблон, якщо він весь знаходиться в одному місці;
* Розробники можуть використати зрозумілі назви для опису аспекту, що дозволить іншим розробникам легше зрозуміти шаблон.;▼
* Якщо виникла необхідність змінити реалізацію шаблону, це можна зробити в одному місці, замість того, щоб шукати реалізацію по всій системі;.
▲* Розробники можуть використати зрозумілі назви для опису аспекту, що дозволить іншим розробникам легше зрозуміти шаблон.
Дослідження використання аспектно-орієнтованого підходу проводилися в різних галузях. Наприклад, при розробці мобільних Java-ігор можна оптимізувати керування ігровим екраном, створення ігрових персонажів, завантаження і відображення малюнків тощо<ref>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9134&rep=rep1&type=pdf</ref>. Крім того, за допомогою точок з’єднанняз'єднання можна впроваджувати необов’язковунеобов'язкову функціональність, наприклад відображення фонових зображень лише на пристроях певного типу.
<br />
Запропоновані методи застосування аспектно-орієнтованого підходу для розробки [[Багатоагентна система|багатоагентних систем]]<ref>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66.1702&rep=rep1&type=pdf</ref>, де [[Інтелектуальний агент|агент]] – автономна програмна одиниця, що при виконанні завдання реагує на навколишнє середовище та спілкується з іншими програмами-агентами (наприклад, програми купівля товарів в [[Інтернет|Інтернеті]]). В даному випадку аспекти можна застосувати для проектування кількох платформ комунікації агентів, додаткових можливостей навчання, різних ролей та протоколів взаємодії.
 
==Недоліки==
Отримано з https://uk.wikipedia.org/wiki/Аспектно-орієнтоване_програмування