Java 如果一门课只授权而不做其他事情，那么它有什么好处呢？

这里的示例摘自以下书籍：

在AOP一章中，我们以AccountManager实现为例：

public class AccountManagerImpl implements AccountManager {
    private MailSender mailSender;
    private SimpleMailMessage message;
    private AccountDao accountDao;

    public void setMailSender(MailSender mailSender) {
        this.mailSender = mailSender;
    }

    public void setMessage(SimpleMailMessage message) {
        this.message = message;
    }

    public void setAccountDao(AccountDao accountDao) {
        this.accountDao = accountDao;
    }

    private void sendMail(Exception ex) {
        SimpleMailMessage msg = new SimpleMailMessage(this.message);
        msg.setText("Encountered exception " + ex.getMessage());
        this.mailSender.send(msg);
    }

    public Account getAccount(String accountId) throws AccountNotFoundException, DataAccessException {
        try {
            return this.accountDao.findAccount(accountId);
        } catch (AccountNotFoundException ex) {
            sendMail(ex);
            throw ex;
        } catch (DataAccessException ex) {
            sendMail(ex);
            throw ex;
        }
    }

    public void createAccount(Account account) throws DataAccessException, {
        try {
            if (isInvalid(account)) {
                throw new InvalidAccountException(account);
                this.accountDao.saveAccount(account);
            } catch(IOException ex){
                sendMail(ex);
                throw ex;
            } catch(DataAccessException ex){
                sendMail(ex);
                throw ex;
            }
        }
    }
}

然后解释了面向方面编程的所有优点，进行了一些配置以将

sendMail（ex）

移动到一个方面，最后我们得到：

public class AccountManagerImpl implements AccountManager {
    private AccountDao accountDao;

    public void setAccountDao(AccountDao accountDao) {
        this.accountDao = accountDao;
    }

    public Account getAccount(String accountId)
            throws AccountNotFoundException, DataAccessException {
        return this.accountDao.findAccount(accountId);
    }

    public void createAccount(Account account) throws DataAccessException {
        this.accountDao.saveAccount(account);
    }
}

从书中引用：

结果是一个重大的改进。会计经理纯粹是 负责帐户管理，使代码更加简单和 易于阅读和维护。异常通知机制是 干净的模块化设计，因此可以单独维护 业务逻辑。例如，一个开发人员现在可以修改 无需修改大量数据的异常通知策略 在传统方法中会受到影响的文件的数量

在我看来，AccountManagerImpl以前实际上是一名经理，而第二个例子只是一场灾难

正如在第二个版本的实现中所看到的，Manager类根本不做任何事情，而是将所有事情委托给一个

AccountDao

---

我的具体问题是：为什么要使用这个实现（第二个版本）？我们也可以将这一方面应用到AccountDao，不？

我同意重构后，manager的核心功能看起来没有说服力。但原因可能只是作者没有花太多时间寻找更好的例子

---

aspects的要点是：提取可以在不同类中找到的横切功能。换句话说：您会发现一个或多个类花费代码来做一些并不真正符合每个类的核心职责的事情。然后，您将这个“非核心功能”抽象为方面-允许您转向AOP工具。因此，您可以通过让工具将相应的代码移动到方面中来理顺您的核心业务逻辑

如果Manager类的意思是一个Façade，那么它的目的是隐藏其成员交互的复杂性。在您的示例中，它有点太简单，因此好处不明显。但是考虑到对DAO的调用不是很直接（需要一些锅炉代码），那么管理器类隐藏了复杂性是很好的。或者假设DAO需要与其他对象进行一些交互，那么复杂性也被Manager类隐藏了。对于外部客户来说，电话很简单。

我很欣赏这种快速恢复。超快！