AOP设计模式的总结
2011-10-17 22:10
369 查看
AOP为Aspect Oriented Programming的缩写,意为:面向切面编程(也叫面向方面),可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP实际是GoF设计模式的延续,设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,AOP可以说也是这种目标的一种实现。
在Asp.net MVC中经常使用的 filter就是一种AOP设计模式。通过在Action上面增加一个属性或者filter就可以改变Action的行为,或者给Action添加部分的功能。好处就是可以不修改Action的代码来得到行为的改变。
面向过程编程离我们已经有些遥远,面向对象编程正主宰着软件世界。当每个新的软件设计师都被要求掌握如何将需求功能转化成一个个类,并且定义它们的数据成员、行为,以及它们之间复杂的关系的时候,面向方面编程(Aspect-Oriented
Programming,AOP)为我们带来了新的想法、新的思想、新的模式。
如果说面向对象编程是关注将需求功能划分为不同的并且相对独立,封装良好的类,并让它们有着属于自己的行为,依靠继承和多态等来定义彼此的关系的话;那么面向方面编程则是希望能够将通用需求功能从不相关的类当中分离出来,能够使得很多类共享一个行为,一旦发生变化,不必修改很多类,而只需要修改这个行为即可。
面向方面编程是一个令人兴奋不已的新模式。就开发软件系统而言,它的影响力必将会和有着十数年应用历史的面向对象编程一样巨大。面向方面编程和面向对象编程不但不是互相竞争的技术而且彼此还是很好的互补。面向对象编程主要用于为同一对象层次的公用行为建模。它的弱点是将公共行为应用于多个无关对象模型之间。而这恰恰是面向方面编程适合的地方。有了
AOP,我们可以定义交叉的关系,并将这些关系应用于跨模块的、彼此不同的对象模型。AOP 同时还可以让我们层次化功能性而不是嵌入功能性,从而使得代码有更好的可读性和易于维护。它会和面向对象编程合作得很好。
AOP 的应用范围
传统的程序通常表现出一些不能自然地适合单一的程序模块或者是几个紧密相关的程序模块的行为,AOP 将这种行为称为横切,它们跨越了给定编程模型中的典型职责界限。横切行为的实现都是分散的,软件设计师会发现这种行为难以用正常的逻辑来思考、实现和更改。最常见的一些横切行为如下面这些:
日志记录,跟踪,优化和监控
事务的处理
持久化
性能的优化
资源池,如数据库连接池的管理
系统统一的认证、权限管理等
应用系统的异常捕捉及处理
针对具体行业应用的横切行为
目前,前面几种横切行为都已经得到了密切的关注,也出现了各种有价值的应用,但也许今后几年,AOP 对针对具体行业应用的贡献会成为令人关注的焦点。
AOP模式主要应该适用于Java和.net的企业级别的开发。
AOP
帮助我们解决了新的问题没有?
AOP 并没有帮助我们解决任何新的问题,它只是提供了一种更好的办法,能够用更少的工作量来解决现有的一些问题,并且使得系统更加健壮,可维护性更好。同时,它让我们在进行系统架构和模块设计的时候多了新的选择和新的思路。
AOP 和 OOP 到底是什么关系
很多人在初次接触 AOP 的时候可能会说,AOP 能做到的,一个定义良好的 OOP 的接口也一样能够做到,我想这个观点是值得商榷的。AOP和定义良好的 OOP 的接口可以说都是用来解决并且实现需求中的横切问题的方法。但是对于 OOP 中的接口来说,它仍然需要我们在相应的模块中去调用该接口中相关的方法,这是 OOP 所无法避免的,并且一旦接口不得不进行修改的时候,所有事情会变得一团糟;AOP 则不会这样,你只需要修改相应的 Aspect,再重新编织(weave)即可。 当然,AOP 也绝对不会代替 OOP。核心的需求仍然会由
OOP 来加以实现,而 AOP 将会和 OOP 整合起来,以此之长,补彼之短。
AOP 适合工业化的应用吗?
这个问题很难回答,其实最好的答案就是尝试,用成功的项目或是产品来回答。Jboss 4.0 就是完全采用 AOP 的思想来设计的 EJB 容器,它已经通过了 J2EE 的认证,并且在工业化应用中证明是一个优秀的产品。相信在不远的将来,会出现更多采用 AOP 思想设计的产品和行业应用。
小结
AOP 正向我们走来,我们需要关注的是怎么样使得它能够为我们的软件系统的设计和实现带来帮助。本文旨在给大家一点启发,能够在更多的领域更深入的应用 AOP 的思想。
【整理完成,大部分内容来自搜索引擎和百度百科】
在Asp.net MVC中经常使用的 filter就是一种AOP设计模式。通过在Action上面增加一个属性或者filter就可以改变Action的行为,或者给Action添加部分的功能。好处就是可以不修改Action的代码来得到行为的改变。
AOP 能够给我们带来什么
面向过程编程离我们已经有些遥远,面向对象编程正主宰着软件世界。当每个新的软件设计师都被要求掌握如何将需求功能转化成一个个类,并且定义它们的数据成员、行为,以及它们之间复杂的关系的时候,面向方面编程(Aspect-OrientedProgramming,AOP)为我们带来了新的想法、新的思想、新的模式。
如果说面向对象编程是关注将需求功能划分为不同的并且相对独立,封装良好的类,并让它们有着属于自己的行为,依靠继承和多态等来定义彼此的关系的话;那么面向方面编程则是希望能够将通用需求功能从不相关的类当中分离出来,能够使得很多类共享一个行为,一旦发生变化,不必修改很多类,而只需要修改这个行为即可。
面向方面编程是一个令人兴奋不已的新模式。就开发软件系统而言,它的影响力必将会和有着十数年应用历史的面向对象编程一样巨大。面向方面编程和面向对象编程不但不是互相竞争的技术而且彼此还是很好的互补。面向对象编程主要用于为同一对象层次的公用行为建模。它的弱点是将公共行为应用于多个无关对象模型之间。而这恰恰是面向方面编程适合的地方。有了
AOP,我们可以定义交叉的关系,并将这些关系应用于跨模块的、彼此不同的对象模型。AOP 同时还可以让我们层次化功能性而不是嵌入功能性,从而使得代码有更好的可读性和易于维护。它会和面向对象编程合作得很好。
AOP 的应用范围
传统的程序通常表现出一些不能自然地适合单一的程序模块或者是几个紧密相关的程序模块的行为,AOP 将这种行为称为横切,它们跨越了给定编程模型中的典型职责界限。横切行为的实现都是分散的,软件设计师会发现这种行为难以用正常的逻辑来思考、实现和更改。最常见的一些横切行为如下面这些:
日志记录,跟踪,优化和监控
事务的处理
持久化
性能的优化
资源池,如数据库连接池的管理
系统统一的认证、权限管理等
应用系统的异常捕捉及处理
针对具体行业应用的横切行为
目前,前面几种横切行为都已经得到了密切的关注,也出现了各种有价值的应用,但也许今后几年,AOP 对针对具体行业应用的贡献会成为令人关注的焦点。
AOP模式主要应该适用于Java和.net的企业级别的开发。
AOP
帮助我们解决了新的问题没有?
AOP 并没有帮助我们解决任何新的问题,它只是提供了一种更好的办法,能够用更少的工作量来解决现有的一些问题,并且使得系统更加健壮,可维护性更好。同时,它让我们在进行系统架构和模块设计的时候多了新的选择和新的思路。
AOP 和 OOP 到底是什么关系
很多人在初次接触 AOP 的时候可能会说,AOP 能做到的,一个定义良好的 OOP 的接口也一样能够做到,我想这个观点是值得商榷的。AOP和定义良好的 OOP 的接口可以说都是用来解决并且实现需求中的横切问题的方法。但是对于 OOP 中的接口来说,它仍然需要我们在相应的模块中去调用该接口中相关的方法,这是 OOP 所无法避免的,并且一旦接口不得不进行修改的时候,所有事情会变得一团糟;AOP 则不会这样,你只需要修改相应的 Aspect,再重新编织(weave)即可。 当然,AOP 也绝对不会代替 OOP。核心的需求仍然会由
OOP 来加以实现,而 AOP 将会和 OOP 整合起来,以此之长,补彼之短。
AOP 适合工业化的应用吗?
这个问题很难回答,其实最好的答案就是尝试,用成功的项目或是产品来回答。Jboss 4.0 就是完全采用 AOP 的思想来设计的 EJB 容器,它已经通过了 J2EE 的认证,并且在工业化应用中证明是一个优秀的产品。相信在不远的将来,会出现更多采用 AOP 思想设计的产品和行业应用。
小结
AOP 正向我们走来,我们需要关注的是怎么样使得它能够为我们的软件系统的设计和实现带来帮助。本文旨在给大家一点启发,能够在更多的领域更深入的应用 AOP 的思想。
【整理完成,大部分内容来自搜索引擎和百度百科】
相关文章推荐
- Spring知识点总结(四)之SpringAOP基础 - 代理设计模式
- 设计模式原则总结--读《大话设计模式》有感
- 自适应XAML布局经验总结 (三) 局部布局设计模式2
- 设计模式总结之中介者模式
- C#设计模式总结
- 设计模式总结
- 几句话总结常用的设计模式
- 针对架构设计的几个痛点,我总结出的架构原则和模式
- 步步为营 .NET 设计模式学习笔记系列总结
- 设计模式总结-Prototype模式
- 设计模式学习阶段性总结之结构型模式
- 软考-设计模式总结
- Objective-C中设计模式总结
- 设计模式总结
- [设计模式整理笔记 六] 工厂模式与创建者模式总结
- 设计模式总结篇系列:组合模式(Composite)
- 学习设计模式笔记(二)部分总结
- php设计模式总结-工厂模式
- java设计模式个人总结(二)
- 23种设计模式总结