AOP 可以做哪些 OOP 无法执行的操作？

我主要是一名Java开发人员。我遇到了不少喜欢AOP的Java开发人员。我最近也看到越来越多的AOP“设计模式”出现，这些模式似乎被相当广泛地采用。即便如此，我仍然不相信OO代码中的AOP通常是一个好主意，原因有几个。

1. 它以不透明的复杂性的形式为代码添加了“魔力”，这可能非常难以调试，并且可能使调试它所影响的面向对象的代码变得非常困难。

2. 在我看来，这基本上是不必要的，而且（更糟糕的是）经常被用来避免必须设计好，或者补偿以前糟糕的设计。

这是一个我在过去几年中看到很多的例子，作为我问题的背景。

在 AOP 之前（来自 Hibernate 文档）

public void saveMyEntityToTheDatabase(MyEntity entity) {
    EntityTransaction tx = null;
    try {
        tx = entityManager.getTransaction();
        tx.begin();
        entityManager.persist(entity);
        tx.commit();
    } catch (RuntimeException e) {
        if(tx != null && tx.isActive()) {
            tx.rollback();
        }
        throw e;
    }
}

在 AOP 之后

@Transactional
public void saveMyEntityToTheDatabase(MyEntity entity) {
    entityManager.persist(entity);
}

对于很多人来说，这似乎是AOP的明显胜利。对我来说，最初的问题是API抽象级别不一致的症状。也就是说，比使用它的消息的业务级 API 低得多。这个问题可以通过更合适的抽象级别和更好的（OO）设计来解决。EntityManager

OO 解决方案

public void saveMyEntityToTheDatabase(MyEntity entity) {
    database.performInTransaction(new Save(entity));
}

此解决方案假定对象包含与负责管理方法的方面相同的事务逻辑。这解决了我上面的顾虑，因为它更清楚地表明，有一些东西可以管理与 的交互，而不是引入另一种编程范式。database@TransactionalEntityManager

最后，我的问题是：AOP能做什么，而OOP做不到的？我稍微相信它在跟踪日志记录中的有用性，也许是默认实现或类似的东西，但我很想知道是否有人发现它在特定类型的问题方面明显优于OO。toString()