Aspect-oriented programming

Най-просто – когато имаме допълнителни (така да се каже „сервизни“), класове, които не са част от самият бизнес модел, но са необходими (като Logger, Auth…), вместо да ги инджектваме в съответният съществен клас (напр. News) и така да го натоварваме, и него, и другите съществените (бизнес модела) с още код, правим допълнителни Aspect класове като напр. AspectLogger, който ще прави логването като Logger, и допълнително AspectConfigurator, където задаваме кой „аспект клас“ къде да бъде викан.

Ето един супер прост пример – на този клас искаме да му добавим например проверка дали даденият, логнат потребител има право да го използва.

Стандартният начин е да имаме клас Auth например, и да инджектнем един негов обект, и например в началото на всеки метод да викаме метод на Auth който да проверява.

<?php
class MyServices
{
    public function doAdminStuff1() {
        //some stuff only the admin should do
        echo "Calling doAdminStuff1";
    }

    public function doAdminStuff2() {
        //some stuff only the admin should do
        echo "Calling doAdminStuff2";
     }
}

Няма ли това да усложни нещата? Ами утре ако трябва и друга функционалност да се използва вътре в MyServices? Пак инджектвай, пак усложнявай методите на MyServices…? И то с какво? С нещо, което няма пряка връзка с MyServices.

Или да изнесем например Auth функционалността извън MyServices? ОК, но това ще значи навсякъде, където се викат методи на MyServices, да използваме Auth и другите (Logger…).

Няма ли да е по-елегантно да изведем някъде настрана логиката кога, къде и какво да се вика за проверки, логове и т.н., без да занимаваме съществените за бизнес модела класове?

AOP is a PECL extension that enables you to use Aspect Oriented Programming in PHP. Като гледам, тук най-просто се дефинират нещо като евент хендлъри, където се задава за кой клас, кой метод, и кога да се извика какво.

<?php
aop_add_before('MyServices->doAdminStuff1()', 'theNameOfTheAuthCheckMetod');

In computing, aspect-oriented software development (AOSD) is a software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program’s business logic.
It does so by adding additional behavior to existing code (an advice) without modifying the code itself, instead separately specifying which code is modified via a „pointcut“ specification.

Core concerns – неща, директно свързани с бизнес модела.

Cross-cutting concern – така да се каже „помощни неща“ като например логване на грешки, аутентикация… Именно това е целта и идеята на Aspect Orienter Programming – да капсулира тези cross cutting concerns в т.н. „aspects“ и да направи използването им възможно, с цел да се олекоти core concern. Aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects to retain modularity.

For instance, if writing an application for handling medical records, the indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they interact with more parts of the program.

Aspects – част от целият софтуер, който може да се използва на различни места, но не е директно свързан с „program’s primary function“.
Но ако гледаме по-философски на нещата, дори и самата бизнес логика (the core concern) може да се разглежда като aspect, and by weaving them together (a process also called composition), one finally produces a whole out of the separate aspects.

Литература

https://en.wikipedia.org/wiki/Aspect-oriented_programming

https://aop-php.github.io/

https://en.wikipedia.org/wiki/Aspect-oriented_software_development