Бағдарламалау парадигмалары: Аспектке бағытталған бағдарламалау (AOP)

Кіріспе

Бағдарламалау парадигмасы

Есептеу техникасында, аспектіге бағытталған бағдарламалау (AOP) – модульділікті арттыруға бағытталған бағдарламалау парадигмасы. Ол қолданыстағы кодты өзгертпей, оған мінез-құлықты (кеңес) қосу арқылы, керісінше, "pointcut" спецификациясы арқылы қай код өгертілетінін бөлек көрсету арқылы жүзеге асырылады, мысалы, "функция атауы 'set'пен басталатын барлық функция шақыруларын тіркеңіз". Бұл бизнес-логикаға тікелей қатысы жоқ мінез-құлықтарды (мысалы, журналды жазу) негізгі функциялар кодын бұзбай бағдарламаға қосуға мүмкіндік береді. AOP бағдарламалау әдістері мен құралдарын қамтиды, олар бастапқы код деңгейінде мәселелерді модульдеуді қолдайды, ал аспектіге бағытталған бағдарламалық жасақтама әзірлеу – толыққанды инженерлік сала. Аспектіге бағытталған бағдарламалау бағдарлама логикасын функционалдық тұтас аймақтарға (көріністер деп аталатын) бөлуді қамтиды. Дерлік барлық бағдарламалау парадигмалары мәселелерді бөлек, тәуелсіз бірліктерге топтастыру және капсулалаудың белгілі бір деңгейін қолдайды, олар осы мәселелерді іске асыру, абстракциялау және біріктіру үшін пайдаланылатын абстракцияларды (мысалы, функциялар, процедуралар, модульдер, сыныптар, әдістер) ұсынады. Кейбір мәселелер бағдарламадағы бірнеше абстракцияларды "кесіп өтеді" және осы іске асыру формаларына қарсы тұрады. Мұндай мәселелер көлденең мәселелер немесе горизонтальды мәселелер деп аталады. Журналды жазу – көлденең мәселенің мысалы, өйткені журналды жазу стратегиясы жүйедегі журналға алынған барлық бөліктерге әсер етуі керек. Осылайша, журналды жазу барлық журналға алынған сыныптар мен әдістерді кесіп өтеді. Барлық AOP іске асыруларында әрбір мәселені бір орында қамтитын көлденең өрнектер болады. Іске асырулар арасындағы айырмашылық ұсынылған конструкциялардың қуаты, қауіпсіздігі және қолдануға ыңғайлылығында. Мысалы, түр қауіпсіздігін немесе жөндеуді қолдамайтын, көлденең кесудің шектеулі түрін анықтайтын перехватчиктер. AspectJ мұндай өрнектердің бірнешеуін қамтиды және оларды ерекше сыныпта, яғни аспект деп атайды. Мысалы, аспект кеңестерді (қосымша мінез-құлық) қолдану арқылы әр түрлі қосылу нүктелерінде (бағдарламадағы нүктелер) негізгі кодтың (бағдарламаның аспекті емес бөлігі) мінез-құлқын өзгерте алады, бұл нүктелік кесу (pointcut) деп аталатын нақтылау немесе сұраныс арқылы анықталады (белгіленген қосылу нүктесі сәйкес келетінін анықтайды). Аспект басқа сыныптарға мүшелер немесе ата-аналарды қосу сияқты екілік үйлесімді құрылымдық өзгерістерді де жасай алады.

In computing, aspect oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross cutting concerns. It does so by adding behavior to existing code (an advice) without modifying the code, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set. This allows behaviors that are not central to the business logic (such as logging) to be added to a program without cluttering the code of core functions. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while aspect oriented software development refers to a whole engineering discipline. Aspect oriented programming entails breaking down program logic into cohesive areas of functionality (so called concerns). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e. g., functions, procedures, modules, classes, methods) that can be used for implementing, abstracting, and composing these concerns. Some concerns "cut across" multiple abstractions in a program, and defy these forms of implementation. These concerns are called cross cutting concerns or horizontal concerns. Logging exemplifies a cross cutting concern because a logging strategy must affect every logged part of the system. Logging thereby crosscuts all logged classes and methods. All AOP implementations have some cross cutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to express a limited form of cross cutting, without much support for type safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, called an aspect. For example, an aspect can alter the behavior of the base code (the non aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary compatible structural changes to other classes, such as adding members or parents.

Тарих

AOP-ның бірнеше тікелей алдын-алағы бар: рефлексия және метаобъект протоколдары, тақырыпқа бағытталған бағдарламалау, композициялық сүзгілер және бейімделмелі бағдарламалау. Грегор Кицалес және Xerox PARC-тегі әріптестері AOP тұжырымдамасын қалыптастырды, одан кейін Java үшін AspectJ AOP кеңейтімдерін жасады. IBM зерттеу тобы тілдік дизайнға қарағанда құралдық тәсілге басымдық берді және 2001 жылы Hyper/J және Concern Manipulation Environment ұсынды, бірақ олар кеңінен қолданылмады. Осы мақалада AspectJ мысалдары келтірілген. Microsoft Transaction Server AOP-тің алғашқы маңызды қолданысы болып есептеледі, одан кейін Enterprise JavaBeans пайда болды.

Қосылу нүктелерінің үлгілері

Аспектке бағдарланған тілдің кеңес беруге қатысты компоненті бірігу нүктесі моделін (JPM) анықтайды. JPM үш нәрсені анықтайды: кеңес қашан орындалуы мүмкін. Бұлар бірігу нүктелері деп аталады, себебі олар жұмыс істеп тұрған бағдарламада қосымша әрекеттерді пайдалы түрде қосуға болатын нүктелер. Бірігу нүктесінің қарапайым бағдарламашыға түсінікті болуы және адрестелуі қажет, ол пайдалы болу үшін. Аспектік тұрақтылықты сақтау үшін, маңызды емес бағдарламалық өзгерістерде де тұрақты болуы керек. Көптеген AOP жүзеге асырулары әдіс орындауларын және өріс сілтемелерін бірігу нүктелері ретінде қолдайды. Бірігу нүктелерін белгілеу (немесе анықтау) тәсілі – нүктелік кесулер. Нүктелік кесулер берілген бірігу нүктесіне сәйкес келе ме екенін анықтайды. Көптеген пайдалы нүктелік кесу тілдері негізгі тіл сияқты синтаксис қолданады (мысалы, AspectJ Java қолтаңбаларын қолданады) және атау арқылы және біріктіру арқылы қайта пайдалануға мүмкіндік береді. Бірігу нүктесінде орындалатын кодты көрсету құралы. AspectJ мұны кеңес деп атайды және оны бірігу нүктелерінен бұрын, кейін және оның айналасында орындай алады. Кейбір жүзеге асырулар басқа сыныптағы аспектіде әдіс анықтауды қолдайды. Бірігу нүктесі модельдерін ашылған бірігу нүктелеріне, бірігу нүктелерін қалай анықтауға, бірігу нүктелерінде рұқсат етілген операцияларға және құрылымдық жақсартуларға қарай салыстыруға болады.

Басқа да ықтимал қосылу нүктесі үлгілері

JPM-нің басқа да түрлері бар. Барлық кеңес тілдерін олардың JPM арқылы анықтауға болады. Мысалы, UML үшін гипотетикалық аспект тілінің JPM мынадай болуы мүмкін:

Қосылу нүктелері – барлық модель элементтері. Тоқтап тұру нүктелері – модель элементтерін біріктіретін кез келген логикалық өрнек. Осы нүктелерде әсер ету тәсілі – сәйкес келетін барлық қосылу нүктелерін визуализациялау.

Басқа бағдарламалау парадигмаларымен салыстыру

Объектіге бағытталған бағдарламалау және рефлексивті бағдарламалаудан аспектілер пайда болды. AOP тілдерінің мүмкіндіктері метаобъектілік протоколдарға ұқсас, бірақ одан шектеулі. Аспекттер субъектілер, миксиндер және делегация сияқты бағдарламалау түсініктерімен тығыз байланысты. Аспектке бағытталған бағдарламалау парадигмаларын пайдаланудың басқа жолдары құралымдық сүзгілер және гиперслайс әдісін қамтиды. Кем дегенде 1970 жылдардан бері, әзірлеушілер AOP іске асыру әдістеріне ұқсас, тұтқындау және диспетчерлік түзетулердің түрлерін қолданып келеді, бірақ олардың ешқайсысы қима кесу спецификацияларының семантикасын бір орында ұсынбады. Дизайнерлер кодты бөлудің басқа жолдарын қарастырды, мысалы, C# тіліндегі ішінара типтер, бірақ мұндай тәсілдерде кодтың бірнеше қосылу нүктелеріне бір декларативті мәлімдемемен жетуге мүмкіндік беретін квантификация механизмі жоқ. Бұл байланыссыз сияқты көрінсе де, сынақта макеттер немесе стับтарды пайдалану AOP техникаларын қажет етеді, мысалы, айналма кеңес. Мұнда өзара әрекеттесетін объектілер сынақ мақсатында қима кесу мәселесі болып табылады. Осылайша, әртүрлі макеттік объектілердің фреймворктері осы мүмкіндіктерді қамтамасыз етеді. Мысалы, процесс баланс сомасын алу үшін қызметке жүгінеді. Процесті сынау кезінде соманың қайдан алынғаны маңызды емес, тек процесс талаптарға сәйкес балансты пайдаланатыны ғана маңызды.