Интерфейсная интерпретация аспектно-ориентированного программирования (АОП)

внешний интерфейс JavaScript React.js

предисловие

Объектно-ориентированный (ООП), как классическая парадигма проектирования, известен всем нам.Помните классическое резюме в начале нашей статьи-все является объектом.
Да, основываясь на характеристиках ООП-мышления об инкапсуляции, наследовании и полиморфизме, мы, естественно, будем следовать принципам модульности и компонентизации для проектирования и разработки приложений, чтобы достичь цели простого обслуживания, масштабируемости и повторного использования.
Поскольку у ООП так много преимуществ, что же такое аспектно-ориентированное программирование (АОП), о котором все часто упоминают, давайте рассмотрим его вместе.

определение АОП

Первый шаг — узнать, что такое aop, сначала объяснение из Википедии:

Аспектно-ориентированное программирование (АОП, также переводится как аспектно-ориентированное программирование, ориентированное на точку зрения программирование, профильно-ориентированное программирование) — термин в информатике, относящийся к парадигме программирования.
Концепция бокового профиля проистекает из усовершенствований объектно-ориентированного программирования, но этим она не ограничивается, ее также можно использовать для улучшения традиционных функций.

Сквозные проблемы изолированы, что является основной концепцией аспектно-ориентированного программирования с точки зрения основного интереса. Разделение касается таких кодов для решения конкретных проблемных областей, независимых от бизнес-логики.
Код бизнес-логики больше не содержит вызовов кода для конкретных проблем предметной области, а взаимосвязь между бизнес-логикой и конкретными проблемами предметной области инкапсулируется и поддерживается на стороне. Таким образом можно хорошо управлять изменениями, изначально разбросанными по всему приложению.

tip

Это немного менее ясно и действительно немного грязно. Но прежде чем мы напортачим, давайте взглянем на части, которые мы можем понять:

  • Аспекты (также известные как аспекты) используются для описания сквозных проблем, разбросанных по объекту, классу или функции..
    Дело тут в том, что сквозные заботы разбросаны по объекту, можно догадаться, что это такое, это должна быть общая часть между разными объектами
  • Концепция сторон проистекает из улучшений объектно-ориентированного программирования, и ее также можно использовать для улучшения традиционных функций.. Очевидно, что АОП не является альтернативой ООП, дополнением к ООП.
  • Отделение сквозных задач от основных задач является основной концепцией стороннего программирования.
    Конкретно для бизнес-проектов основное внимание уделяется бизнес-логике. Вызов кода проблемы для определенного домена — это та часть, на которую АОП должен обратить внимание.

Короче говоря, АОП предназначен для извлечения аспектов процесса обработки бизнес-процессов (то есть частей, не связанных с бизнес-логикой, таких как обработка ошибок, скрытые точки, журналы и т. д.).
Он сталкивается с определенным шагом или стадией в процессе обработки, чтобы получить эффект изоляции низкой связи между частями логического процесса (цель состоит в том, чтобы уменьшить связь).
В частности, реализация заключается в динамической вставке части, не относящейся к основной проблеме, в основную проблему (обычно это бизнес-логика).

Сказав так много, вы можете не понять, давайте посмотрим код вместе.

Погребенная сцена

В таком распространенном сценарии информация должна сообщаться после нажатия кнопки. Предположим, у нас есть такой инструмент логгера, о котором можно сообщить:

const logger = console.log
//引入即可使用
logger('按钮被点击了')

Итак, приступим непосредственно к делу:

const doSomething = ()=>{
    console.log('doSomething')
} 
let clickHandler = ()=>{
   logger('doSomething之前')
   // n行代码 
   doSomething() 
   logger('doSomething之后')
   //n 行代码
}

Ни на что не похоже, просто и грубо.
Если есть 30 кнопок, каждая из которых имеет свою бизнес-логику, эту точку необходимо скрыть (при условии, что информация о точках непротиворечива).
В наших 30 функциях, если нам придется вручную писать этот метод, это слишком неудобно.
Основная причина в том, что это серьезно связано с бизнес-кодом.Однажды я случайно коснулся какого-то другого контента, и я удалил его по ошибке, и это было gg.
Когда дело доходит до последующего обслуживания, это кошмар.
Присмотритесь, не соответствует ли это предпосылке использования АОП, тогда попробуйте АОП.

разделение интересов

В соответствии с вышеизложенным можно выделить следующие интересные моменты.

Основное внимание боковой фокус
Бизнес-логика (сделай что-нибудь) Похороненный информационный журнал

Как упоминалось ранее, АОП фокусируется на шагах, специфичных для примера, которые на самом деле являются шагами вставки регистратора.
Время вставки — это не что иное, как этап до или после выполнения бизнес-логики.
Это не так сложно реализовать

Реализовать идеи

Конкретно для js, из-за особенностей самого языка, он рождается с возможностью динамически вставлять логику во время выполнения.
Дело в том, что добавление других функций к исходной функции не меняет саму функцию.

В конце концов, функции могут принимать все формы параметров, и функции не являются исключением.
При передаче функции у нас есть много места для работы с ней,
Сохраните исходную функцию, а затем используйте последующие параметры, чтобы добавить вызов или применить для достижения нашей цели.
Кроме того, чтобы добавить свойство к функции, мы можем оперировать прототипом.

Реализация классики до или после

Подобных реализаций в интернете слишком много, просто посмотрите прямо на код:

// action 即为我们的侧关注点,即logger
Function.prototype.after = function (action) {
    //保留当前函数,这里this指向运行函数即clickHandler
    var func = this;
    // return 被包装过的函数,这里就可以执行其他功能了。
    // 并且该方法挂在Function.prototype上,
    // 被返回的函数依然具有after属性,可以链式调用
    return function () {
        // 原函数执行,这里不考虑异步
        var result = func.apply(this, arguments);
        // 执行之后的操作
        action.apply(this,arguments);
        // 将执行结果返回
        return result;
    };
};
// before 实现类似,只不过执行顺序差别而已
Function.prototype.before = function (action) {
    var func = this;
    return function () {
        action.apply(this,arguments);
        return func.apply(this, arguments);
    };
};

Затем код после того, как мы используем АОП для преобразования, выглядит следующим образом:

const doSomething = ()=>{
    console.log('doSomething')
} 
let clickHandler = ()=>{
   // n行代码 
   doSomething() 
   //n 行代码
}
clickHandler = clickHandler.before(()=>{
     logger('doSomething之前')
}).after(()=>{
     logger('doSomething之后')
})
clickHandler() // 执行结果和预期一致

Здесь реализовано аспектно-ориентированное программирование.Наша бизнес-логика заботится только о самом бизнесе, и таким образом динамически вводятся побочные задачи, отделенные от основной логики, которая является более чистой и простой в обслуживании.

заключительные замечания

На этом введение простого АОП завершено. Используя этот режим в сочетании с характеристиками самого нашего js, мы можем попробовать больше возможностей. Например, общий HOC в нашем реакте, мод декоратора es7, HOF и т. д., много раз нам приходится вздыхать суть мыслей больших коров, что заставит нас испытать чувство прозрения. Эта статья предназначена для привлечения других и совместного обучения.Это резюме и улучшение для меня, и я надеюсь помочь нуждающимся маленьким партнерам.Для получения дополнительных статей, пожалуйста, перейдите в мой блог

Справочная статья

AllyTeam — Улучшение кода JavaScript с помощью АОП
Углубленные декораторы Javascript и АОП-программирование