这是我参与更文挑战的第10天，活动详情查看：更文挑战
当OOP(Object-Oriented Programming)/OOSD(Object-Orient Software Development)被提出来，以取代过去的基于过程化编程的开发方法的时候，或许，那个时代的人都会以为，面向对象编程和面向对象的软件开发就是我们一直所追求的那个能搞定一切的“银弹”。但不得不承认，即使面向对象的软件开发模式，依然不能很好地解决各种需求，包括业务需求和系统需求。使用面向对象方法，我们可以对业务需求等普通关注点进行很好的抽象和封装，并且使之模块化。但对于系统需求一类的关注点来说，情况有所不同。
以一个有关贷款业务的管理系统为例。从业务角度说，该系统提供了顾客贷款申请、顾客信息管理、贷款信息管理、贷款发放回收等功能。这些都属于普通的业务需求。通过面向对象方法，可以很容易地按照功能划分模块并完成开发。下图给出了这些模块之间清晰的关系。
在开发中为了调试，或者在进入生产环境后为了对系统进行监控，我们需要为这些业务需求的实现对象添加日志记录功能。或者，业务方法的执行需要一定的权限限制。那么方法执行前肯定需要有相应的安全检查功能。而这些则属于系统需求的范畴。虽然需求都很明确（加入日志记录、加入安全检查），但是要将这些需求以面向对象的方式实现并集成到整个的系统中去，可就不是一个需求对应一个实现那么简单了。系统中的每个业务对象都需要加入日志记录，加入相应的安全检查，那么，这些需求的实现代码就会遍及所有业务对象。整个场景如下图所示：
图中日志记录和安全检查的需求和实现的对应关系还仅仅是1：2。但随着系统中业务对象的增加，这个对应关系就会变成1：3、1:4...、1:100甚至更多。你可以想象一下，随着这个数目的增多，你的系统开发和维护的难度会向一个什么方法发展。、
对于系统中普通的业务关注点，OOP可以很好地对其进行分解并使之模块化，但却无法更好地避免类似于系统需求的实现在系统中各处散落这样的问题。所以，我们找到了AOP。
AOP全称为Aspect-Oriented Programming，中文通常翻译为面向切面编程。任何一个软件系统就跟上面提到的贷款业务的管理系统一样，日志记录、安全检查、事务管理等系统需求就像一把刀“恶狠狠”地横切到我们组织良好的各个业务功能模块之上（见下图）。以AOP的行话来说，这些系统需求是系统中的横切关注点。使用传统方法，我们无法更好地以模块化的方式，对这些横切关注点进行组织和实现。所以AOP引入了Aspect的概念，用来以模块化的形式对系统中的横切关注点进行封装。Aspect之对于AOP，就相当于Class之对于OOP。AOP仅是对OOP方法的一种补足，当我们当以Class形式模块化的业务需求和以Aspect形式模块化的系统需求拼装到一起的时候，整个系统就算完成了。
