AOP在大规模软件开发项目中应用的尝试与思考
AOP开发实践(zz)
public class Security
{
public bool CheckRight(User currentUser , Model accessModel , OperationType operation)
{
……//校验权限
}
}
然后，在业务逻辑过程中进行如下调用：
public class BusinessClass
{
public void BusinessMethod()
{
Security s = new Security();
if (!s. CheckRight(……))
注意，AOP并不仅仅等同于方法调用拦截，当然，这也是最常用的和非常有效的AOP功能。
在某些开发中，我们可能使用过滤器来完成某些AOP功能。例如，当用户访问某些资源时，我们可以对访问信息进行一些过滤处理。一个常见的场景是，在JSP开发中，为了实现对中文的正确处理，我们通常需要对浏览器同服务器之间传递的数据进行转码处理，以获得正确的文字编码。在每个Request中手工进行转码肯定不是一个好的解决方案。一个比较好的例子，是为应用程序编写一个Filter，自动进行转码处理。例如，我们可以为TOMCAT写如下一个过滤器来实现转码：
{
return ;
}
……//执行业务逻辑
}
}
这种做法在OO设计中，是常见的做法。但是，这种做法会带来以下一些问题：
1、 不清晰的业务逻辑：从某种意义上来说，权限校验过程并不是业务逻辑执行的一部分，这个工作是属于系统的，但是，在这种情况下，我们不得不把系统的权限校验过程和业务逻辑执行过程掺杂在一起，造成代码的混乱。
AOP对软件复杂度的影响分析及应用_骆四毛
） 织入是由 ＡＯ （ ６ Ｐ 编译器将方面模块 的 代 码 织 入 到 宿 主代码中 ， 而 ＡＯ Ｐ 的织入时机可分为编 译 时 织 入 、 载 入 时
５］ 。 织入和运行时织入 ［
２ 解决方案
在某手机应 用 软 件 的 后 台 管 理 系 统 中 ， 管 理 员 维 护 模 块的功能是便于对 该 系 统 的 各 种 权 限 级 别 的 管 理 员 进 行 集 中管理 。 但在 开 发 时 ， 模 块 中 的 日 志 输 出 过 于 分 散 ， 且 在 许多个文件 中 相 互 缠 结 ， 使 相 关 复 杂 度 居 高 不 下 ， 不 便 于 后期维护和 更 高 版 本 的 良 好 兼 容 ， 开 发 进 度 深 受 影 响 。 而 ＡＯ Ｐ 在降低系统耦合度 、 提高 代 码 重 用 性 和 简 化 结 构 复 杂
Ａ ｎ ａ ｌ ｓ ｉ ｓ ａ ｎ ｄ ａ ｌ ｉ ｃ ａ ｔ ｉ ｏ ｎ ｏ ｆ ｉ ｎ ｆ ｌ ｕ ｅ ｎ ｃ ｅ ｓ ｏ ｆ ＡＯ Ｐ ｆ ｏ ｒ ｓ ｏ ｆ ｔ ｗ ａ ｒ ｅ ｃ ｏ ｍ ｌ ｅ ｘ ｉ ｔ ｙ ｐ ｐ ｐ ｙ
， Ｌ ＵＯ Ｓ ｉ ａ ｏ Ｚ ＨＯＵ Ｘ ｉ ｎ ｂ ｉ ｎ －ｍ － ｇ
软件度量学的最终目的是服务 于 软 件 质 量 控 制 与 评 价 ， 软件过程改 进 必 须 以 软 件 度 量 为 基 础 。 而 软 件 复 杂 度 ， 即 ） ， 作为传统软件 度 量 学 的 一 部 分 ， Ｓ Ｃ（ ｓ ｏ ｆ ｔ ｗ ａ ｒ ｅ ｃ ｏ ｍ ｌ ｅ ｘ ｉ ｔ ｐ ｙ 又可作为软 件 结 构 和 可 理 解 性 的 一 种 度 量 ， 一 般 地 ， 取 决 于软件内部结构各 子 系 统 之 间 的 控 制 流 与 数 据 流 的 复 杂 程
软件开发反思总结范文
在过去的软件开发过程中，我经历了许多挑战和成长。
回顾这段时间，我深刻认识到自己在技术、团队协作和项目管理等方面的不足，同时也收获了许多宝贵的经验和教训。
以下是我对这段时间的反思总结。
一、技术方面的反思1. 技术深度不足在软件开发过程中，我意识到自己在技术深度方面存在不足。
虽然掌握了多种编程语言和框架，但对某些技术原理和算法了解不够深入。
这导致在遇到复杂问题时，难以快速找到解决方案。
因此，在今后的工作中，我将加强技术积累，深入学习相关技术原理，提高自己的技术深度。
2. 编码规范问题在编写代码时，我发现自己存在一些编码规范问题。
如命名不规范、注释不清晰、代码重复等。
这些问题不仅影响代码的可读性，还可能导致后期维护困难。
为了提高代码质量，我将在今后的工作中严格遵守编码规范，提高自己的编程水平。
二、团队协作方面的反思1. 沟通不畅在团队协作过程中，我发现自己在沟通方面存在一定问题。
有时，由于表达不清或沟通不及时，导致团队成员之间产生误解，影响项目进度。
为了改善这一问题，我将在今后的工作中加强沟通，提高自己的表达能力。
2. 团队协作意识不足在团队项目中，我意识到自己团队协作意识不足。
有时，为了追求个人进度，忽视了与其他成员的协作。
为了提高团队整体效率，我将在今后的工作中加强团队协作意识，积极与其他成员沟通交流。
三、项目管理方面的反思1. 时间管理能力不足在项目管理过程中，我发现自己在时间管理方面存在不足。
有时，由于对项目进度估计不准确，导致项目延期。
为了提高时间管理能力，我将在今后的工作中合理规划时间，确保项目按时完成。
2. 风险控制能力不足在项目开发过程中，我意识到自己在风险控制方面存在不足。
有时，由于对潜在风险预估不足，导致项目出现严重问题。
为了提高风险控制能力，我将在今后的工作中加强对项目风险的识别和评估，提前制定应对措施。
总结：通过这段时间的软件开发工作，我认识到自己在技术、团队协作和项目管理等方面还存在诸多不足。
AOP技术的研究与应用
１引 言 ．
８００ ） ５ ０ ０
系统。 ２ＡＯＰ 术 的 应 用 ． 技 如果 需 要 在 用 户 管 理模 块 上 添 加 一 个 日志 ， 以 采 用Ｊ Ｋ 可 Ｄ 中 的 动 态 代 理 方 法 ｉ ａ ａ ｇ ｅ ｅ ｔ ｒｘ 类 和 ｖ ． ｎ ． ｆ ｃ． ａ ． ｎ ． ｆ ｃ． ｏ ｙ ｖ １ ｒｌ Ｐ ａａ ａｇ ｅ ｅｔ １ ｒｌ Ｉｖ ｃ ｔ ｎ ａ ｄｅ接 口来 实 现 ． 体 过程 ： ｎ ｏ ａ ｏ Ｈ ｎ ｌｒ ｉ 具
ｔｒｗｓ ｈｏ ａ ｌ（ ｈｏ ｒｗ ｂｅ ｔ
ｂ ｆｒ ｔ ｏ ｅｏ ｅｍｅｈ ｄ ｍ：
码基 础上 添 加 代 码 ． 这 样 既 造 成 了 代 码 的混 乱 ， 不 易 阅读 但 又 和修 改 。 （ ） 用 继 承 ， 合 性 强 ， 果 父 类 要 进行 修 改 ， 类 ２采 耦 如 子 也 得 修 改 ， 系很 死 ， 够 灵 活 。 （ ） 关 不 ３ 组合 ， 种 方 式 可 以实 现 这 多 个 类 来 回组 合 ， 比继 承 灵 活 ， 如 果 有 多个 ｂａ ， 不 能 自 但 ｅｎ 它 动 加 载 ， 以 组 合 也 很 难 实 现 。 针对 上 面 的 问 题 ， 文 提 出 了 所 本 新 的 解 决 办法 ： 这 些 日志 逻 辑 单 独 封 装 出 来 ． 要 的时 候 在 把 需 配 置 文件 中调 用 即可 ， 需 修 改 业 务 逻 辑 ， 就 是 Ａ Ｐ Ａ ｐｃ 无 这 Ｏ （ ｓｅｔ
Ｌ ｇｎｅｅｐｏ ｉ ｎ ｗ Ｌ ｇｎｅｃ ｐｏ（ ｏ ｌｔｒｅ ｔｒ ＝ ｅ ｏ ｌ ｔｒｅ ｔｒ ） Ｌ
Ｌ． ｔ ｒｅ（ ｓｒ ｉ ｅｔ ｇ ｔｕ ｅＤＡＯ） ｓ ａ ； ｕｅＤＡＯ．ｓｒ ｓｒ ｕｅＤＡＯＰ ｏｙ ｕ ｅＤＡＯ） ｒｘ ．ｅ Ｐ ｏ ｙｎ ｔｎ ｅ ｒｘ＝（ ｓｒ ｐｏ ｙｎ ｗ ｒｘ ｌｓａ ｃ （ ｓｒ ＡＯ． ｔｌｓ （ ．ｓｒｌｓＬ ａ ｅ（ ｕ ｅＤ ｇ ｃａ ｓ ） ｅｃａ ｓ ｏ ｄ ｌ ） ｅ ｕ
aop实现方式和应用场景
aop实现方式和应用场景
AOP（Aspect Oriented Programming）是一种编程思想，可以将
系统的核心业务逻辑与非核心功能（如日志记录、性能监控、异常处
理等）分离，从而提高代码重用性、灵活性和可维护性。
AOP实现方式包括注解、XML配置方式和自动代理。
其中，注解
方式最为简洁明了，通过在方法上添加注解的方式来切入非核心功能，使得代码结构更加清晰；XML配置方式则需要在XML配置文件中定义切面和通知的信息，相对比较繁琐；自动代理是一种自动为被代理对象
生成代理对象的方式，需要通过基于注解或XML的方式指定切面和通知。
AOP的应用场景包括但不限于：日志记录、性能监控、异常处理、事务管理以及安全控制等。
例如，通过在系统中引入AOP实现事务管理，可以避免在代码中手动控制事务，提高开发效率；通过在系统中
添加AOP实现安全控制，可以方便地控制用户权限，提高系统的安全性。
总之，AOP为软件开发提供了一种更加灵活、高效的编程方式，可以有效地提升系统的可维护性和可扩展性。
谈谈对AOP的理解
但是这种方式：还是需要定义接口。
3、利用cglib
CGLIB是针对类来实现代理的，他的原理是对指定的目标类生成一个子类，并覆盖其中方法实现增强。采用的是继承的方式。不细说，看使 用
a、业务类
/** * 业务类 * * @author yanbin * */ public class PeopleTalk {
}
private void sing(String singname) { System.out.println("唱歌：" + singname);
}
}
d、测试类
/** * 代理测试类，使用代理 * * @author yanbin * */ public class ProxyPattern {
this.target = target; return Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), this); }
/**
* @param Object
*
target：指被代理的对象。
* @param Method
*
method：要调用的方法
* @param Object
*
[] args：方法调用时所需要的参数
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
public void talk(String msg) { System.out.println("people talk" + msg);
对aop的理解
对aop的理解AOP，全称为面向切面编程，是一种计算机编程范型和技术。
它旨在通过在程序代码的不同位置注入代码，来实现解耦和划分责任的目的。
本文将从以下五个方面来对AOP进行简要的介绍和解析。
1. AOP的概念AOP是一种程序设计思想。
它的主旨是将程序应用中的业务逻辑与系统服务分离开来，这种分离使得逻辑代码更清晰，同时使其更有层次性、可维护性和可扩展性。
通过AOP，我们可以把系统中一些通用的方面，如日志、事务、权限、缓存等，提取出来作为切面，然后在需要用到这些方面的地方，使用AOP框架进行动态织入。
2. AOP的实现原理AOP框架实现的原理是动态代理和字节码操作。
在运行时，AOP框架会在目标对象和代理对象之间插入一层拦截器（Interceptor），当某个方法被调用时，拦截器会先执行通用逻辑，再执行业务逻辑。
代理对象可以通过继承实现，也可以通过JDK动态代理（基于接口）和CGLib动态代理（基于类）技术实现。
使用AOP的主要优势是解耦和模块化。
它将通用的方面提取出来作为切面，而业务逻辑则放在目标对象中，通过动态代理实现切面与业务逻辑之间的分离。
这使得系统更易于维护，也使得系统的架构更加可扩展和可重用。
4. AOP的应用场景AOP的应用场景主要包括日志、事务、缓存、安全、权限等方面。
比如，在一个Web应用中，我们可以通过AOP来实现记录日志、处理事务、统计性能、进行权限控制等功能。
使用AOP也有一些缺点，比如增加了代码的复杂度，增加了系统全局的耦合性，增加了程序的体积和运行的时间等等问题。
但是针对这些问题，开发人员可以通过精心设计和合理划分切面来避免和引导。
在总结上述内容之后，可以看出AOP在软件开发过程中有着非常广泛的应用。
它的优点在于将程序代码进行了分层，使得程序的结构变得更加清晰、易于维护和可扩展。
但是在运用AOP时，开发人员也需要遵循它的指导思想和设计思路，以达到最佳的效果和最低的副作用。
使用AOP技术优化数据库应用性能的实践
；
在 企业 级应 用 中 ，数据 库 系统 无疑是 最重 要 的因素 ，提升 数 但通 过 手 工 修 改代 码 在 应 用 中调 用 ｎ ｔｙ和 ｃ ｍｐ ｔｔｔ ｔ ｓ ｏｉ ｆ ｏ ｕＳａｉ ｉ ， ｓｃ 据库 的响 应性 能是 改善应 用性 能 的关键 。 却 有极大 的风 险 ：
当应 用要执 行一 个耗 时的 Ｓ Ｌ Ｃ Ｅ Ｅ Ｔ或 带有复 杂 Ｗ Ｈ Ｒ Ｅ Ｅ语句 解 决 共 性 问题 并 分散 在 系 统 中 各 个 部 分 的 模 块 纳 入 一 个 切 面
６ ：甚 Ｈ 。Ｂ ｌ． １ ６ 措 ２Ｅ ｌＯ １１ ： 。 ｔ
砸
，
Ａ ＰＰＬ Ａ Ｔ ＯＮ ＩＣ Ｉ
不 是 十 分 巨大 ，但 总计 也 有 近百 万 条 记 录。 首 先通 过 采 用调 整 必 须考 虑到 程 序 的控 制流 程 ，我们 必 须考 虑到 那 些 Ｓ ＯＬ语 句被
服 务器 内存 分配 、调 整硬 盘 Ｉ 和调 整操 作 系统参 数等 常规 优 化 真 正 的执 行 、那 个 带 有数 据 访 问 的循 环 要经 常 执行 、那 个 ｉ或 ／ Ｏ ｆ 策 略 ，发 现 应 用性 能没 有 显著 提 高。 因 此 ，把注 意力 集 中 到 了 ｅｓ 句块 要 被 执 行 到等 等 。 ｌ￣ 说 ：如 果 我们 放 置 ｎ ｔｙ和 ｌ ｅ语 ：ｔ Ｌｎ ｏｉ ｆ Ｓ Ｌ语句 的执 行效 率 上。 通过 使用 Ｓ ｒｃ ａｉｙ发 现 ： 日 ｃ ｍｐ ｔｔｔ ｔ ｓ 一个 循环 语 句 中 ，那 么统计 计 算将 发生 在每 Ｑ ＯＬＴａｅＦ ｃｉ ｌ ｔ ｏ ｕＳａｉ ｉ 在 ｓｃ 常使 用 中 查询 、 更 新操 作 都 很 频繁 ，而且 连 接 数 张表 或 带 有 复 次循 环 迭代 中 ，这 无 疑对 性 能 来 说不 但 不 是优 化 ，可 以说 是一
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
AOP在大规模软件开发项目中应用的尝试与思考转自IBM网站/developerworks/cn/java/j-aop/2005 年11 月本文的写作源于一个真实的大型软件开发项目，我们努力尝试在这个项目中推广应用AOP。
在此我们将对曾经面临过的一些实际问题与困难进行分析，试图引发关于面向方面软件开发(AOSD)的一些更深层次的思考。
本文的作者将站在开发者的角度做出客观的判断，既不是AOP的狂热鼓吹者，同样也不是AOP反对阵营的一员。
因此可以视作来自Java开发者对AOP技术应用的客观分析和建设性意见。
关于AOP关于AOP的概念，笔者在这里不再赘述。
谁最先创造了AOP，业界一直有些争议，但普遍接受的说法大概是最先由Gregor J Kiczales在ECOOP'97提出来的，随后Gregor又申请了AOP的专利[US06467086]。
很多人可能不太服气，因为他们或多或少早已有了类似的想法，只不过没有想到给他起个新名字罢了。
无论是OOP，MOP，还是AOP，其本质的想法都是试图在更贴近现实世界的层次上实现软件开发的模块化。
从这个角度看，AOP的想法不过是新瓶装旧酒罢了。
其实AOP作为新生事物的出现，并不是一种技术上的飞跃，而是软件模块化发展到某一个阶段的一个阶段性产物。
人的思维通常都有一些惯性，在我们饱尝了OOP的艰辛后，有一种新的概念跳出来分析总结了OOP的某些缺点，而且以看起来合理的方式做出改进，难免会给大家一种耳目一新的感觉。
但不可否认的是，到目前为止，AOP角色所扮演的应用角色更多的只是对OOP的一种补充，因此作为一种重要的"OP"存在似乎有些名过其实，看起来更像是一种高级的设计模式。
然而，在很多人的眼中AOP的分量甚至不亚于OOP，甚至AOP被视作未来软件开发的一个趋势。
笔者一直思考一个问题，AOP出现的七八年时间在IT界并不算很短了，有趣的现象是AOP始终保持了小火慢炖的热度，一直没有像大家所期望的那样大红大紫起来。
那么AOP究竟在多大程度上可以帮助我们解决实际的问题呢？让我们尝试在一个真实的软件开发项目中应用AOP。
对AOP所推崇的各个典型应用方向加以研究，例如，日志(Log),事务(Transaction), 安全性(Security), 线程池等等。
必须说明，我们这里提到的场景，是有一定规模的软件产品开发，我们最终完成的是百兆数量级的软件产品，因此我们研究的范围既不是程序员的个人行为，也不是小范围的示例。
让我们一起来看一看有什么有趣的发现。
回页首AOP的实践我们试验应用AOP的方向很多，这里仅以最具代表性的Log为例。
大多数人了解AOP，都是从经典的Log 关注点的剥离开始的。
因此这是每一个AOP的爱好者都耳熟能详的案例。
按道理，应该是无可争辩的。
很不幸，在我们的研究过程中还是碰到了很棘手的问题。
让我们来看一看一个经典的AOP 做日志的例子。
我们假定，按照AOP的思想，主逻辑的开发人员在写代码的时候不应该考虑边缘逻辑。
因此，上述的日志代码实际对主逻辑的开发者不可见。
假定我们以主流的Log4J为记日志的实现方式，以AspectJ作为Aspect的实现方式。
需要重申，本文的写作目的并不是针对某一种AOP的实现平台，选用AspectJ主要因为从语法的角度而言，AspectJ是目前所有AOP实现中覆盖范围最广的一种实现。
这样一个记日志的横切关注点描述，是最经典的AOP应用，它本身是没有任何问题的。
通常我们会怎样用它呢？在继承了这个抽象Aspect的子Aspect实现中指定切入点的位置①，并在这个位置上将实现的逻辑填入通知(Advice)②。
在一个小规模的应用开发环境中这样做是不会有问题的，首先，记日志的切入点不多，无论是采用一对一的位置直接描述，还是利用统一的编码规范来约束都是可行的方案；其次，通知中的逻辑不会很复杂。
整体的软件开发流程不会有什么变化的需要，通常的做法是由专门的Aspect开发人员统一编写Aspect，而由大家共享记Log的Aspect。
但是不鼓励每一个开发人员都写自己的Aspect，这样就不是横(cross-cut)，变成过筛子了(cross- point)，软件开发变成一盘散沙，失去控制，AOP 带来的好处丧失殆尽。
那么，在我们的项目中，情况怎样呢？上述看似简单的两个点都存在问题：(1) 具我们统计，在我们开发的软件上一个版本的软件代码中，总共有7万句记Log的调用。
如果我们不做任何相关的总结工作，直接一对一的对切入点进行描述，那么在位置①上的切入点描述就有7万条之多；姑且不算工作量，即使这样做了，将来带来的代码维护将是天文数字的成本，此路不通。
那么我们只能寄希望能够提炼出这7万句日志调用的公共模式，我们在这里用到的是一种优化过的Log组件，接口与LOG4J类似，考虑到LOG4J的广泛应用，我们下面将以LOG4J为参照。
Log Level 类中预定义了五个级别，DEBUG, INFO, WARN, ERROR，FATAL，根据统计，Fatal类型的调用最少，根据Fatal的级别定义，我们或许可以花一定时间整理代码，提炼出捕捉Fatal点的规则。
然后次之，WARN和ERROR大约占7%左右，这一部分就不好办了，WARN/ERROR类型的LOG并没有严格的界定，代码的分布点也难寻规律，一定要找到规律，要付出相当大的代价。
最后，DEBUG, INFO占据了很大的比例30%-50%，顾名思义，这一部分的代码出现的随机性很大，无论怎样努力都不可能找到有意义的公共规律。
此路还是不通。
有一种说法也许可以解释这种想象：如果切入点难于描述的时候，很大原因是因为关注点的定义不准确。
此说法有一定道理，以"日志"作为一个方面来切入粒度似乎太大了。
那么，唯一的办法是将"日志"关注点进一步拆解。
一直拆解到可以接受的程度。
但是，我们的问题似乎还没有解决，如果我们的项目足够小，那么这样的拆解总是有一定的限度的，这种做法或许可行。
但很不幸，我们的项目很大，要经过相当多的分解才能最终找到日志的规律性。
我们还是可能需要成百上千条语句来指定切入点的位置，最终的结果将很难维护，这样的做法对于一个不断演化中的项目而言是脆弱乃至于不可接受的。
况且，像Debug这样的Log级别，无论你怎样拆解，都不可能找到完美的规律。
通常，任何一个系统中的Log都会保持逻辑的一致性，如果经过了这样的层层分解，Log作为一个逻辑主体的完整性被完全破坏了。
这是一种为了AOP而AOP的做法，非但工作量没有减轻，还带来了无穷的后患。
好了，只剩最后一招了，为了用AOP, 我们牺牲掉Log的某些特性，预先定义好编码的规则和日志原则，强制推行。
当然，如果想要全面覆盖所有的日志点，这样的日志原则只能定得非常粗。
从AOP 的角度来讲，技术上是可行的，但粗放的日志规则会带来Log的信息量疯长，对于我们的软件项目来说，还是不可接受，因为日志失去了它的精确性，会对系统的维护产生较大影响，而且大量日志信息的增长对系统整体运行性能的冲击是显而易见的。
(2) 在图1 的第二个要点上我们也同样面临问题，也许从图上的例子你可能还看不出来，因为在所有的介绍AOP的文档材料中介绍Log的例子都很简单。
但是现实生活中的Log很不留情面。
很多时候程序对Log的调用都有其特殊的原因，它们的Advice需要分别编写。
例如在例子产品中我们经常需要把一个变量传给"日志" 方面, 而且，经常要传入一个局部变量。
至少现在，所有的AOP实现都还不支持对局部变量的捕捉，在可见的将来也不会有这种实现。
好吧，只好重构代码，如果您想传参数，必须要遵守我们预先定义的编码命名规则。
但是，这样给编程人员带来的限制会很大，你很难说服开发人员手捧厚厚的编码规范，小心翼翼的写程序。
综合上述两个致命缺陷，我们试图推行Log Aspect的工作已经遇到了相当的阻力。
回页首问题分析原本看起来一件简单的事情，现在变得很复杂了，最初的热情变成了爱恨交织与困惑，一定是哪里出了问题。
在大型的软件开发项目里AOP的切入点应该怎样控制？这牵涉到开发的流程，版本控制，编码规则等等。
似乎AOP本身并没有给出明确的答复。
当我们谈OOP的时候，涉及到的更多的是类，继承，多态，而更深层次的方法学被隐藏在OOA与OOD中。
类似的，我们在提到AOP的时候，表面上似乎就是Aspect，pointcut，advice，… 然而隐藏在代码后面的面向方面的精华却被忽略了。
因此，我们主张，在我们学习应用AOP的时候，不要过分沉迷于代码，应当合理的在分析、设计上投入更多的精力。
这是我们从上述的失败经历中得到的第一个教训。
才能的。
我们不能把AOP想象成为万灵丹，服用之后立刻生效。
相反，在实际项目中应用AOP需要多方面的考虑，这样才可能对由AOP 产生的问题胸有成竹。
从某种意义上讲，代码级别上的面向方面, 无论是面向Java的语言扩展还是XML，实现起来并没有太大的不同。
但是面向方面的技术也应该体现在不同的抽象层面上，如果在大规模的开发中应用，AOA(面向方面的分析)，AOD(面向方面的分析设计)是必不可少的，因此，AOSD(面向方面的软件开发)更贴切的描述了面向方面实际上是一个完整的实施过程。
关于在更高层面上的AOSD，很多人正在做有益的尝试，例如IBM 支持的基于Eclipse的CME项目，首先要解决的是怎样在软件开发的初始阶段，定义合理的关注点，至于后面的实现是否基于纯粹AOP的工具，并不是重要的问题。
脱离分析、设计阶段的关注点分析，直接在代码中使用AOP，只在小规模的应用中可行，一旦面向大规模应用，许多问题就会接踵而来。
除此之外，面向方面的开发过程还必须解决很多的具体问题，诸如：∙怎样在切入点的公共模式与切入点的特征描述之间权衡？这是一个怎样合理的控制AOP的粒度的问题，前面我们已经提到过，横切关注点的粒度其实是很难决定的。
在高层次上定义的横切关注点, 在底层实现的时候还可能会碰到问题。
对具体的AOP实现，可能单纯从代码的角度来看，粒度划分得越细越简单越好。
但这样一来，方面的代码与核心代码就会绑定很死，不好维护。
而且方面的代码不优雅，看起来好像单纯把一块代码摘出来另放一个地方，刻意隐藏的痕迹很重，很难看出AOP的好处。
但粒度如果太粗，AOP的代码就必须依赖公共模式的总结，这样的公共模式首先需要花功夫来定义，力求完美，因为规则的不断变化会带来很多问题，所以应尽量避免出现规则的频繁变动。
而且，规则是大家都要遵守的，这样会带来更多的编码限制。
当然，对于具体的项目，编码规则的多少是具体的问题，但如何能做到适度，并不是一个简单的问题。