У рачунарству, аспектно-оријентисано програмирање (АОП) је патентиранаU.S. Patent 6,467,086 парадигма програмирања која има за циљ да повећа модуларност дозвољавајући издвајање механизмом крос-сечење проблема. То чини додавањем додатног понашања на постојећем коду без мењања самог кода, уместо одвојено наводећи који код је модификован преко "поинткат" спецификације, као што су "лог све функције позива када име функција почиње са 'сет' ". Ово омогућава понашања која нису у средишту пословне логике (као што улоговање) да се дода у програму без пренатрпавања језгра кода на функционалности. АОП формира основу за аспектно оријентисан развој софтвера.
АОП обухвата методе и алате који подржавају модуларизацију забринутости на нивоу изворног кода за програмирање, док се "аспект оријентисан развој софтвера" односи на читаве инжењерске дисциплине.
Аспект-оријентисано програмирање подразумева разбијање програмске логике у различитим деловима (тзв. бриге, уједињене области функционалности). Скоро све програмске парадигме подржавају одређени ниво груписања и енкапсулације забринутости у посебне, независне ентитете пружајући апстракције (нпр. функције, процедуре, модули, класе, методе) које могу да се користе за спровођење, апстракција и компоновања ових проблема. Неки проблеми "пресецају" више апстракције у програму, и пркоси овом облику имплементације. Ови проблеми се називају укрштена забринутост или хоризонтална забринутост.
Пријављивање илуструје попречно сечење забринутости зато што стратегија пријављивања нужно утиче на сваки пријављени део система. Пријављивање на тај начин пресеца све пријављене класе и методе.
Све АОП имплементације имају неке прожимајуће изразе који енкапсулирају сваку забринутост на једном месту. Разлика између имплементације лежи у моћи, сигурности и употребљивости конструкције предвиђених. На пример, пресретачи који уређују начин да пресретну изразе ограниченог облика прожимајућег, без много подршке типа безбедности или отклањања грешака. АспектЈ има велики број таквих израза и сажима их у специјално одељење, један аспект. На пример, један аспект може променити понашање основног кода (нон-аспект део програма) применом савета (додатна понашања) на различитим придружењем поена (тачака у програму) наведеним у квантификацији или упитима који се зову "поинткат" (да детектује да ли је дати придружити тачка матцхес). Један аспект такође може да направи бинарне-компатибилне структурне промене на другим класама, као додавање чланова или родитеља.
Историја АОП има неколико директних претходнице А1 и А2: рефлексија и метаобјектни протоколи, субјектно-оријентисано програмирање, састав филтера и адаптивно програмирање. . presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).
Gregor Kiczales и његове колеге у Xerox PARC су развили експлицитни концепт АОП, а затим ово са АспектЈ АОП проширење на Јави. Истраживачки тим IBM води приступ алата преко приступа дизајна језика и 2001. године предложио је Хипер / Ј и забринутост манипулације окружења, који нису видели широку примену. Примери у овом чланку користе аспектЈ јер је најпознатији АОП језик.
Microsoft Transaction Server се сматра да је прва велика примена АОП затим Enterprise JavaBeans
Мотивација и основни појмови Типично, аспект је расут или замршен као код, што отежава да се разуме и одржи. Расут је на основу функције (као што је пријављивање) која се простире на великом броју неповезаних функција које могу да користе своју функцију, вероватно у потпуности неповезаних система, различитим језицима извора, итд То значи да промењено пријављивање може захтевати мењање свих модула. Аспекти постају замршени не само са умереним функцијама система у којима су изражени него и међусобно. То значи промена једне бриге подразумева разумевање свих замршених забринутости или има нека средства којима се ефекат промена може закључити.
На пример, размотримо банкарску апликацију са концептуално веома једноставним начином за пребацивање у висини од једног рачуна на други:Note: The examples in this article appear in a syntax that resembles that of the Java language.void transfer(Account fromAcc, Account toAcc, int amount) throws Exception { if (fromAcc.getBalance() < amount) throw new InsufficientFundsException();
fromAcc.withdraw(amount); toAcc.deposit(amount); }Међутим, овај метод преноса превиђа одређена разматрања које би распоредило примену захтева: недостају безбедносне провере да проверите да ли садашњи корисник има овлашћење за обављање ове операције; трансакција (базе података) би требало да обухвати операцију како би се спречио случајни губитак података; за дијагностику, операција треба бити пријављена на евиденцију система, итд
Верзија са свим тим новим проблемима, због примера, мога да донекле изгледа овако:void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger, Database database) throws Exception { logger.info("Transferring money...");
if (!isUserAuthorised(user, fromAcc)) { logger.info("User has no permission."); throw new UnauthorisedUserException();
if (fromAcc.getBalance() < amount) { logger.info("Insufficient funds."); throw new InsufficientFundsException();
fromAcc.withdraw(amount); toAcc.deposit(amount);
database.commitChanges(); // Atomic operation.
logger.info("Transaction successful."); }У овом примеру други интереси су постали замршени са основним функцијама (понекад названа пословна логика забринутости). Трансакције, сигурност, и пријављивање свих примером укрштене забринутости.
Сада размотримо шта се дешава ако се изненада треба променити (на пример) и сигурносни аспекти за примену. У тренутној верзији програма, операције везане за безбедност изгледају разбацано преко бројних метода, а таква промена ће захтевати велике напоре.
АОП покушава да реши овај проблем тако што програмер да изразе укрштених забринутости у самосталном модулу под називом аспекти. Аспекти могу садржати савете (код се придружио одређеној тачки у програму) и интертипове декларације (структурни чланови се додају другим класама). На пример, безбедносни модул може укључивати савете који обављају безбедносну проверу пре него што приступите банковном рачуну."Поинткат" дефинише време (придруже поена) када се може приступити банковном рачуну, а код у упутству тела дефинише како се спроводи провера безбедности. Даље, добар "поинткат" може да предвиди касније промене програма, тако да ако други програмер креира нови метод за приступ банковном рачуну, савет ће се примењивати на новом начину када извршава.
Тако, на горњем примеру спроводи се пријављивање у погледу:aspect Logger { void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) { logger.info("Transferring money...");
void Bank.getMoneyBack(User user, int transactionId, Logger logger) { logger.info("User requested money back.");
// Other crosscutting code. }Једино могу да замислим АОП као алат за дебаговање или као корисник оруђа на нивоу. Савети треба да буду резервисани за случајеве где не могу да се функције мењају (ниво корисника) или не желите да промените функцију у производњи кода (дебаговање).
Модели придружене тачке Компонента савет у вези једног аспекта оријентисаних језика дефинише се придруживањем тачки модела (ЈПМ). ЈПМ дефинише три ствари: Када се савет може покренути. То су придружени поени јер су поенеи у програму рада, где додатно понашање може бити корисно придружено. А придружена тачка треба да буде адресибилна и схватљива обичном програмеру да буде корисно. Такође би требало да буде стабилно преко неважних промена програма, како би један аспект требало да буде стабилан преко таквих промена. Многе АОП имплементације подржавају метод погубљења и референце на терену као придружена тачка. Један од начина да одредите (или количина) придруживање бодова, зове се "поинткат". Поинткат утврђује да ли је дато придруже тачке утакмице. Најкориснији поинткат језици користе синтаксу као основни језик (на пример, АспектЈ користи Јава потписа) и омогућава поновну употребу кроз именовање и комбинације. Средство за навођење кода да покрене придруживање тачке. АспецтЈ зове овај савет, а могу га покренути пре, после и око придруживања поена. Неке имплементације такође подржавају такве ствари које дефинишу метод у погледу на друге класе.
Тачка придруживања модела може се упоредити на основу придружене изложене тачкеж, како се придруже тачке су наведене, операције дозвољено на придружи поена, а структурних побољшања која се може изразити.
AspectJ придружена тачка модел Придружене тачке у аспектЈ укључују метод или конструктора позива или извршења, иницијализација класе или објекта, поље читају и пишу приступ изузетака сировина, итд Они не укључују петље, супер позиве, клаузуле, вишеструке изјаве, итд Тачке пресека су наведене комбинацијом примитивних "поинткат" ознака (ПЦД).
ПЦДС одговара посебној врсти придружених тачака (нпр извршења метода) и има тенденцију да се уђе у Јаву као потпис. Један такав "поинткат" изгледа овако:
execution(* set*(*)) Ако назив методе почиње сасети управо ту је један аргумент било које врсте. "Динамика" ПЦД проверава рунтиме врсте и везује варијабле. На пример, this(Point) Ово сечење одговара када тренутно извршавање објекта је инстанца класе Поен. Имајте на уму да неквалификовано име класе може да се користи преко Јаве нормалног типа проналажења.
Обим" ПЦДС ограничавају лексички обим придружене тачке. На пример: within(com.company.*) Ово сечење било ком придруживању у било којој врсти у com.companyпакету. * је један облик џокерске ознаке које се могу користити да одговарају многим стварима са једним потписом.
Тачка сечења може бити састављена и именована за поновну употребу. На пример: pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*); Овај метод-извршења придружеје тачку, ако назив метода почиње са "set" и this је инстанца типа Point у com.company пакету. Може се односи на употребу имена "set()". Савет наводи да ради на (пре, после, или око) А Члан тачке (одређеног ) сигурног кода (наведено као код у метод). АОП Рунтиме позива савет аутоматски када поинткат одговара тачки да се придружи. На пример: after() : set() { Display.update(); } То практично одређује: "ако set() поинткат одговара придружењу тачке, покрените кодDisplay.update() након што је придруже тачки завршења."
Други потенцијални модел придруживања тачке Постоје и друге врсте ЈПМс. Све инструкције језика се могу дефинисати у смислу њиховог ЈПМ. На пример, хипотетички језик аспект УМЛ могу имати следећу ЈПМ: Јоин тачке су сви елементи модела. Тачке сечења су неки изрази комбинујући елементе модела. Средства која утичу на ове тачке су визуализација свих поклапања да се придружи тачки.
Међу-типови декларације Међу-типови декларације обезбеђују начин да се изрази забринутост прожимајућег утицања на структуру модула. Познат и као отворена класа и проширења метода, ово омогућава програмерима да се изјасне на једном месту или члановима родитеља друге класе, обично у циљу комбинују све шифре које су повезане са бригом у једном аспекту. На пример, ако програмер реализује прожимајући екран ажурирања забринутости користећи посетилаца уместо тога, међу-типови декларације користећи образац посетилаца могу изгледати овако у аспектј: aspect DisplayUpdate { void Point.acceptVisitor(Visitor v) { v.visit(this);
// other crosscutting code... }Овај фрагмент кода додаје acceptVisitor метод Point класе.
То је услов да свака структурна слика мора бити компатибилна са оригиналним класама, тако да клијенти постојеће класе наставе да раде, осим ако примена за АОП може очекивати да контролише све клијенте у сваком тренутку.
Имплементација АОП програми могу утицати на друге програме на два начина, у зависности од основних језика и окружења: комбиновани програм производа, важи у оригиналном језику и не разликује се од обичног програма до крајњег преводиоца