Този въпрос ме накара да мисля за ефективни начини за прилагане на ЗНП в някои софтуерни системи, с които съм работил. Осъзнах също, че е необходимо да се мисли за това как и кога да се използват нови методи, особено ако те се нуждаят от нови начини на мислене. AOP, което беше споменато по-рано в тази статия, просто и представлява нов подход. Бих искал да поговорим малко за това как ефективно, по мое мнение, като се използват AOP. Също така да разгледаме някои от най-новите постижения в AOP, които могат да улеснят нейното разбиране.
Примери ще бъдат използвани аспект-ориентиран език Java. В момента има няколко програмни езици с аспект, ориентирани към изпълнение. Сред тях AspectC ++ и дори AspectL, т.е. аспект ориентирана реализация на Lisp. 1
Преглед на концепциите за AOP
За да се разбере тази дискусия на AOP, трябва да знаете няколко концепции. Основната концепция - точка на свързване (присъединят точка). Тази концепция, че всички програмисти са запознати и за които няма име. Точката за връзка е "точно определен момент по време на програмата." 3 Има много видове точки на свързване, например, наричаме или връщане метод, който може да бъде конвенционален нулиране или генерирането на изключения.
В AOP е необходимо да се намери начин да се идентифицират точките на свързване в програмата. В AspectJ да се опише една или повече точки на свързване се използват pointcut (точка на прекъсване). Pointcut е израз, описващ множеството от точки за свързване. Pointcut може да се разглежда като искане за кода, който се връща на набор от точки на съединенията.
При избора на набор от съединения за тяхното механизъм точки се предоставя съвети (препоръка). Съветите са изпълним код, който работи, когато точката на свързване по време на изпълнение. точки на свързване, pointcuts и съвети са предназначени за изпълнение на динамичните характеристики на софтуера. съвети механизъм променя характеристиките на изпълнимия код.
примери AOP
А сега да разгледаме примери, при които може да се използва и AOP, където тя се използва. Някои примери са взети от производствените системи, а други - от процеса на експлоатация и развитие. Нека започнем с няколко примера за разработчици.
проследяване на изпълнението
Това е невероятно колко разработчици поставете оператори за извеждане в кода за различни отстраняване на грешки или следи от програмата. Тази информация е наистина важно за дебъгерите. Но тази дискусия не е свързана с изучаването на дебъгерите. Разбира се, има сериозни основания за създаване на програма за проследяване на текст. Настоящият набор от инструменти AspectJ развитие (AJDT) в Eclipse е прекрасен пример за един от аспектите, който реализира изпълнението на следа програма. Един пример е описан подробно в референтен Eclipse система. Тя може да се намери в "Ръководство за програмиране AspectJ».
В примера има малък Java-базирано приложение с класове, представляващи двуизмерни форми, като кръгове и квадрати. Прилагането също до метод, който създава две среди и площади и извеждане на техните свойства, такива като площ, периметър, и разстоянието между центровете. След стартиране на програмата изхода данни трябва да съответства на Фигура 1.
Фигура 1. Тези форми на програма
Помислете за действителната последователност може да се позове на методи по два начина. В първия подход може да бъде в началото на всеки метод за вмъкване на код, който показва съобщение с името на метода и класа, както и фактът, че се обадите на този метод. Това трябва да се направи за всеки метод. Вторият подход е да се създаде един от аспектите на извършване на същата операция. При този подход, промяна на кода на приложението не се изисква.
Пример следа включва множество версии на програмата за използване на размерите следи. Помислете за най-новата версия. За други версии, вижте. В "Ръководство за програмиране AspectJ».
Решението за надежден механизъм за проследяване се състои от две файлове. Първият файл - абстрактен аспект. Този аспект е подобен на абстрактен клас, където някаква част от кода е оставено на програмистите изпълняват в извлечен клас, или, в този случай, получени аспект. Резюме аспект нарича Трейс, има няколко стандартни методи за производство на входните и изходните послания на метода или конструктора и за форматиране на изходни данни. Ако не се използват въпросите, тези методи са в един клас е помощник, и се използват за показване на информацията от проследяването. Проследяване също така позволява на програмистите да определят вида на трасето, като зададете свойства TRACELEVEL. Има три нива: няма съобщения, съобщения, които не са структурирани и съобщения, структурирани да се покаже вложени разговори.
Проследяване определя три pointcut: две бетон и един абстрактен (виж фиг 2 ..). Всеки аспект, който подобрява аспект Трейс, трябва да представи извлечение pointcut, MyClass. Назначаване pointcut е да изберете класовете за обекти, които съдържат точки на свързване трябва да се препоръчва. Това позволява на разработчиците да решават кои класове трябва да бъдат включени в данните за извеждаща следи.
Фигура 2. Pointcut в проследяване аспект
Pointcut myConstructor избира точка за свързване в началото на конструктор за всеки обект в MyClass класните избран. Точката за връзка всъщност е дизайнер на тялото. myMethod подобен myConstructor, но избира изпълнението на всеки от методите в избрания клас. Моля, имайте предвид, че прилагането на метода на ToString е пропуснат, тъй като той се използва в код съветите на.
код, предоставен от страна на съвета е доста проста. Има код съвети (препоръки), за да бъде поставена преди всяка точка за свързване, както и съвети, извършени след точката на свързване. Това е показано на фигура 3.
Фигура 3. Pointcut в проследяване аспект
За да използвате аспект Трейс е необходимо да се разшири и да се осигури точното изпълнение на абстрактен pointcut. Фигура 4 показва пример програма тяло един аспект TraceMyClasses. Pointcut използва, за да изберете само тези обекти, които са копия на TwoDShape, кръг или квадрат. Основният метод определя TRACELEVEL, изпълнение и следа програма инициализира и започва основен метод за пример.
Фигура 4. специфичен аспект на следа
Фигура 5 показва част от изходните данни за този пример. Моля, имайте предвид, че информацията за всички обекти. Тази част от метода ToString на всеки обект. Rointcut (крайната точка) публикува myClasses възразят съвет (препоръка), което го прави лесно да се добави информация за обекта.
Фигура 5. Пример следа изход
Какви са предимствата на подхода AOP за проследяване в сравнение с ръчен вложка проследяване код на правилните места? Има няколко предимства.
- Всички изходния код, свързани с проследяване на връзката се съхранява на едно място (две измерения);
- следа код е лесно да поставите и извадите. За този дизайн аспекти се отстраняват от конфигурацията;
- Трейс код може да бъде добавен към всяко място, дори и когато се добави към целевата класа на нови методи. Това елиминира програмни грешки. Когато премахнете измерение от конфигурацията на дизайна може да бъде сигурен, че всички следи код е отстранена и нищо не липсва;
- Получават многократна употреба аспект, който може да се използва и подобрени.
Договор или защитен програмиране
Когато създавате библиотека широко използване не може да бъде сигурен, че истинността на аргументите предадени на метода. Необходимо е да се провери аргументите преди обработващата логика на всеки метод. Това е пример за защитна програмиране. Предполага се, че всички грешки се обработват грациозно.
Създаване на величина, която да провери всички аргументи в общите методи. Първо изграждане pointcut (раздели точки). Ние използваме най-pointcut MyClass от предходния пример и добавете pointcut да изберете дизайнери, които изискват аргументи за проверка и дистанционен способ, който не е предназначен за нулева стойност. Фигура 6 показва набор от необходимо pointcut. Имайте предвид, че втората pointcut определя като цел pointcut например TwoDShape. Това означава, че pointcut избира обекти в междуселищни разговори само на метода.
Фигура 6. Pointcut (раздели точки), за да се провери аргумент
И накрая, трябва да добавите подходящите съвети (препоръки). За простота, ние се получи известие за откриване на невалиден аргумент, а след това, ако theconstructor, промяна на реалните стойности на нула и да се игнорира техниката за междуградски разговор при предаване на нулева стойност. Фигура 7 показва две такива елементи съвети.
Фигура 7. Елемент съвети (препоръки) за проверка на аргументи
Когато се опитате да извършите следното изречение:
Кръгът c3 = нов кръг (3.0,2.0, -2.0);
в програмата получава следното съобщение:
Съобщението за грешка може да направи много повече, ако съдържат името на брой и източник файл точната линия, но този пример е, да не го прави.
В големи проекти, където много класове и използват множество интерфейси, проблеми код, които прилагат аргумент проверка, могат да се организират в отделна папка. Мога да си представя няколко начина за организиране аспекти лесното им идентифициране и поддръжка. При създаване на система за битови нужди могат да ползват конфигурация на вътрешната структура, за да се създаде система за външни клиенти - конфигурация, включваща аспекти. Eclipse AJDT го прави лесно да се създаде нова конфигурация структури.
Аспекти и дизайн модели
Jan / AODPs / Можете да изтеглите кода, който реализира GOF.5 група шаблони. 5 Lesetski Николай (Николай Lesiecki) също пише за дизайн модели за IBM developerWorks уеб-сайт. 6 В статията си осигурява по-пълно описание в сравнение с тази статия.
Помислете за един много прост пример за стандартен адаптер шарка в AspectJ.
Фигура 8 показва диаграма на Unified език за моделиране (UML) за адаптер шаблон. В този модел, искането за нуждите на клиента и обслужването е създаден за тази цел. Може да има много доставчици на услугата, и всеки от тях може да има различно име услуга или всякакви нестандартни изисквания, които трябва да бъдат изпълнени от молещата страна. Добър обектно-ориентиран дизайн показва, че искането на услугата е капсулиран в мишена интерфейс, програмата интерфейс и, ако е необходимо, адаптер, който играе ролята на посредник между клиента и услугата (в диаграмата го Adaptee).
Фигура 8. модел адаптер
Подходът за използване на адаптера изглежда разумно и целесъобразно. Но какво да се прави в случай на остарялата система, които не са проектирани за работа с шаблони или адаптери? Разработчиците на тези системи не осъзнават възможността за бъдещи промени. Повиквания могат да бъдат разпръснати из заявлението. Как да се приложи нова и подобрена услуга? Без аспекти, може да се наложи да се възстанови оригиналната система код, за всички обаждания към услугата изглежда, разработване и изпълнение на адаптер адаптер модел. В зависимост от количеството на старата служба нарича това може да бъде доста досаден задача. Разглобяването и усъвършенстване - достойна цел, но лукса не може винаги. Трябва да е доволен от освобождаването на кода, това е най-доброто, което може да се направи за кратко време.
В този случай, можете да създадете AOP версия на адаптер модел, веднага решава проблема и ви позволява да направи крачка напред към по-организирани и по-добре проектирана система.
Фигура 9 показва един прост клиент, който използва услугата. Service връща разстоянието от една точка до сегашната Client обекта.
Фигура 9. Обикновено клиент
за интерфейса на услугата описва един-единствен метод:
Нов доставчик подобрено обслужване има метод с малко по-различно име, както и други параметри. Неговият интерфейс:
Ние трябва да създадем адаптер, който се намира между старите разговори услуги, получава съответните аргументи за новата услуга е нова услуга, и се връща на резултатите на клиента. Клиентът не се променя. Аспект изисква за това е показано на Фигура 10.
Фигура 10. адаптер аспект да се позове на нова услуга
Обърнете внимание на аспект простота. Декларирам pointcut за идентифициране на всяко повикване useService оригиналната услуга. След това използвайте съветите (препоръка) наоколо, за да замени на призива на новото повикване услуга след изваждането от клиента информация на обаждащия се изисква.
Този подход има своите предимства и недостатъци. На първо място, с помощта на този един прост аспект можете да направите промени в целия код приложение. Възможно е също така да се капсулират съотношение за повикване на услуги от едно място. Сега, ако новата услуга ще бъде заменен от нов, трябва да промените само кода аспект. Това е предимство за по-надеждна система.
Основният недостатък е, че старата клиентът все още остава в системата, дори ако то не се използва. Ако времето позволява, (което изглежда, че няма никога) е най-вероятно, че трябва да се върна и да се възстанови оригиналната система код, за да използвате стандартния модел адаптер. Най-малкото, което може да промени първоначалната услуга метод useService в кода, който връща сляпо стойност, като например 0.0, защото този метод никога няма да се обади.
Прилагане на професионално ниво
До момента имаме счита ясно ограничени, но полезни примери за прилагане на ЗНП. Възниква въпросът, колко добре този метод везни. Накратко описва и се отбележи, добре познат пример. По-подробна дискусия ще изисква писмено друга статия.
Може би някои от вас са запознати с рамка Спринг, 7 е инфраструктура приложение, което подпомага развитието на корпоративни приложения. Рамката за пролетния осигурява пластове рамка J2EE за изграждане на сложни корпоративни приложения. AOP е една от основните технологии използвани през пролетта. През пролетта, общността е разработила собствена реализация аспект ориентирани, което ви позволява да се прилага за кодиране комплекс логика по време на работа, а не по време на компилация, както и в AspectJ. Но ако има функции за интегриране лесно да включи AspectJ в рамката за пролет.
В момента пролет се използва в много организации за създаване на бизнес приложения, които са по-добре проектирани и изисква по-малко време, за да се развива. В моя преценка, това е отличен пример за това как да се прилагат аспекти на реални проблеми. 8
Какво можете да правите по-нататък?
По мое мнение, в бъдеще, AOP ще бъде част от инструментариума на софтуерните разработчици. Аз не знам дали ще стигнем до точката, където ние ще създадем система, която използва AOP като основен механизъм за проектиране, но мисля, че ще се намерят начини за подобряване аспекти на използването на съществуващите обектно-ориентирани проекти. Може ускори процеса няколко секунди.
На първо място, е необходимо стандарт стабилна прилагането на ЗНП. Този процес вече е започнал. AspectJ 5 версия съчетава двата най-популярни AOP езика Java - AspectJ и AspectWerkz. Също така да помогне за изпълнението на стандарта и на други езици, например C ++.
На второ място, необходимостта от разработване на показатели за доказване на ефективността на AOP на отделни системи. Например, дали повторното изпълнение на дизайнерски модели с помощта на AOP-добре стандартни обектно-ориентирани модели? В някои случаи е по-добре моделите, а в някои - не? Какво трябва да създавате индекси за информация относно тези показатели и да ги развива? прост подход по време, когато обект инженерство (или каквото сте избрали), системата се счита за добра (), преминал. Необходимо е да се създаде един проект и изпълнение решения въз основа на емпирични данни. 9
На трето място, е необходимо да се продължи да се разработят инструменти, които поддържат AOP. Имам удоволствието да съобщя, че новата AJDT за Eclipse предоставя отлична набор от инструменти. Тези инструменти се подобри подкрепата, необходими за ефективното и ефикасно използване на аспекти. Инструментите трябва да поддържат и нова технология, която използва аспекти.
Аспекти трябва да се поддържат. Те все още не са се превърнали в част от основните приложения, но с всеки изминал ден става по-близо до това. Аз препоръчвам да се запознаят с аспектите и да ги проучи внимателно.
бележки
GOF Група 3 - Ерих Гама (Ерих Гама), Ричард Хелм (Ричард Хелм), Ралф Джонсън (Ралф Джонсън) и Джон Vlissides (Йоан Vlissides), пише моделите на дизайна на книгата. Това семенната книга за шаблони за дизайн;
7 Ако читателите използват AOP, искам да споделя своя опит и да предоставят данни за моите научни AOP показатели, моля свържете се с мен.
Свързани статии