AspectJ - Зачем помещать управление транзакциями в отдельное место?

#aop #aspectj

Вопрос:

Хорошо, я не до конца понял философию, для чего хорош AOP AspectJ. Теперь я внедрил ведение журнала и управление транзакциями при снятии денег с банковского счета. Хорошо, почему это хорошо делать? Я мог бы аналогичным образом реализовать управление в том же файле класса, где я также сохранил все свои банковские методы (снятие, депозит, баланс … и т.д.). И ведение журнала Я мог бы создать для него новый класс, а затем создать его экземпляр в классе BankAccount.

Итак, почему мне нужно использовать AOP, AspectJ для этого? Я не до конца понял идею…

Вот мой файл aspect

 public aspect SafeWithdrawal {                                                                                  

pointcut checking(BankAccount bk, float x): execution(* BankAccount.withdraw(float)) amp;amp; target(bk) amp;amp; args(x);                                                                                                   

public static void BankAccount.LogChange(String str){                                                    
    System.out.println(str);                                                                             
}                                                                                                        


before(BankAccount b, float x) : checking(b, x) {
        if(b.getBalance() >= x) {
            BankAccount.LogChange("Account changing. $"   x   " withdrawn...");
        } else {               
            BankAccount.LogChange("Account does not have. $"   x   " to withdrawn...");
        }

}                                                                                                        

}

Ответ №1:

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

1. «сфокусированный на лазере»? Итак, идея состоит в том, чтобы не связывать вашу функцию с вещами, которые не связаны с самим методом? Ну, тогда есть много вещей, которые нужно преобразовать в аспекты, не так ли? Я думал, что идея с ООП уже охватывает это.

2. @starcorn: Как ООП решает сквозные проблемы?

3. @starcorn: Приведенный выше комментарий не очень конструктивный. Идея, лежащая в основе AOP, заключается в том, что каждый класс несет единственную ответственность. Целью вашего класса банковского счета является обработка транзакций, а не реализация политики кэширования или ведение журнала или единообразная обработка исключений. Ответственность классов ведения журнала заключается в регистрации всех ошибок (например), ответственность политики кэширования заключается в кэшировании значений и т.д. Затем вы можете указать на уровне приложения, как обрабатывается ведение журнала / кэширование / etc, И заставить это правило применяться везде. Но каждая из этих частей информации указывается только один раз.