AOP vs Decorator - Powered by Jdon

1 2 ► 总共有 15 回复／ 2 页

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

AOP vs Decorator	2006年01月08日 22:28
标签列表

过滤器是架构设计模式中比较常用的一种，几乎每个灵活动态系统都需要过滤器，特别是当我们的数据以内存状态出现时，过滤器无疑成为领域层的一个核心业务逻辑，当然如果你还是使用面向数据库的编程模式，过滤器功能就被你用SQL语句的where语法给替代了，那么以下你可能不必再看.

http://www.jdon.com/AOPdesign/decorator.htm

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年01月11日 17:46

其实使用filter过滤器也可以替代我们业务中的if else，过滤器起到一种过滤和筛选作用，将符合本过滤器条件的对象拦截下来做某件事情，这就是一个过滤器的功能，多个过滤器组合在一起实际就是if else的组合。

mythmoon

悄悄话
发表文章: 202
注册时间: 2005年03月21日 01:09

Re: AOP vs Decorator

2006年01月11日 22:22

bang大哥．这个观点我以前听过，仔细想象还是有点不明白，可否用示例详细说明了！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
替未明白此道理之道友谢谢先！

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年01月12日 16:00

看看这篇文章：
http://www.jdon.com/artichect/ifelse.htm
如图:

如图，通过一个个条件过滤器我们立体地实现了对信号的分离，如果你使用if else，说明你是将图中的条件1/2/3/4合并在一起，在同一个地方实现条件判断。

wangwei1998

悄悄话
发表文章: 6
注册时间: 2003年09月18日 01:05

Re: AOP vs Decorator

2006年01月16日 23:43

从某种角度来说，if else是代码层次的，而filter考虑的角度更多的是业务需求层次的，虽然filter和if else在某些实现逻辑和模式方面相似，甚至有些地方可以相互替代，但毕竟两者是不同环境下考虑的，不应该拿来相比较，什么情况下用filter，什么环境下在代码中用if else实现，对于有经验的开发人员来说，还是比较容易判断的。
至于“将if else用在小地方”，则见仁见智了，何谓“小地方”？何谓“大地方”？？业务逻辑的实现有其相对成熟的模式，不管是filter也好、对象也好，都是业务实现的手段，可以用不同的方式互相替代，但替代的同时，是不是也要考虑不同业务的不同特性呢？

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年01月23日 19:49

>if else是代码层次的，而filter考虑的角度更多的是业务需求层次的，
这个总结非常好，实际上这也是我们很多有经验的程序员会在脑子里使用if else来替代有效的业务分析。

filter是从一个模式语言来说，其实我想表达的是动态的这个概念，是动态语言的动态。刚才在会SOA帖子时，我认为recher提到的SOA优点：

我个人觉得SOA根本体现分离关注点包含三个方面：一个是代码技术角度，一个是设计架构角度，一个应用业务功能角度。
代码技术：反应的从对象/接口的关系静态（体现代码）-->描述的动态的转变；
设计架构体系：从根本上可以把架构的技术关系从静态耦合关系-->代码没有耦合，耦合关系发生在runtime动态关系转变（这必然促使架构中组件关系的）；
应用角度：这是他思路最强和更高层次看问题，从业务和技术功能的从静态耦合到静态分离(runtime耦合)转变----这是多么强大的功能能也是IT行业追求的效果.

追求运行时动态耦合可以说时动态设计的最大目标，其中过滤器filter是这种实现的一个途径，每个构件功能都可能成为一个过滤器Filter，就象我们在做光学物理实验，在光线通向方向可以随机插入各种颜色滤镜一样，和我上帖的图非常类似。

这就是开发设计中动态设计境界，目前我已经在JiveJdon3中实现了。

但是，如果你使用if else考虑或实现系统时，实际你不是以动态和立体思维来分析和设计系统，而是一种静态强耦合。

>至于“将if else用在小地方”，
这个小地方就是指非业务实现，如流程或简单数据替代，目前这方面也正在被各种新技术钎灭。

另外从目前UML分析角度看，我们会发现UML没有通常的流程图，因为流程图中充满各种if 判断然后时不同的分支，这种方式被状态图活动图组合在一起替代。

总之，将if else丢在2005年才是你跟上软件技术前进的标志。

当然，具体实现时，不可偏激，需要逐步来实现，就象刚学会走路，就要慢慢学会跑一样。

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年01月23日 19:55

这里补充一下，谈到动态设计有人会想到就是AOP，其实Decorator+IOC组合也可以实现动态设计，Decorator模式比较好用，然后借助IOC实现不同的Decorator和Decoratee之间的动态组合。

使用过滤器，实现动态系统；消灭if else。你是否又这方面的经验分享？（这也是使用Spring/HiveMind/Jdon等框架深入后一个新境界）。

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年01月23日 20:07

另外，是否是真的动态还是那句话：这个过滤器插件是否可以被替代？只有能被完全替代，才是一个完全动态的系统，很象IE浏览器的插件概念，我们可以在服务器端软件象IE浏览器安装或去除插件一样安排我们的服务器功能了。

xyxx

悄悄话
发表文章: 16
注册时间: 2006年01月17日 10:26

Re: AOP vs Decorator

2006年01月25日 16:58

拜托不要动不动就来什么“面向对象”好不好！？在面向负责逻辑得时候ifelse总是不太恰当的，总会有各种各样的设计模式来处理这个问题。要真的替代代码逻辑的ifelse还不容易，apache jakarta commons下有个专门研究类似面向对象的解决办法，但这只会增加编程麻烦和性能消耗，又是一个典型的技术人员思维！

xyxx

悄悄话
发表文章: 16
注册时间: 2006年01月17日 10:26

Re: AOP vs Decorator

2006年01月25日 17:07

再补充一下，过滤器模式在处理同一业务对象时是很有效的。
banq现在大谈过滤器玩意儿，是不是刚从jivesoftware学得拿来卖弄呀

dabb

悄悄话
发表文章: 233
注册时间: 2004年04月21日 15:02

Re: AOP vs Decorator

2006年03月20日 20:10

题外话
如果需要大量的if/else来实现一个复杂的业务逻辑，可以考虑使用规则引擎比如(drool)来实现。使用规则引擎可以大大提高开发复杂业务逻辑的速度和逻辑的可维护性。

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年03月20日 20:25

>banq现在大谈过滤器玩意儿，是不是刚从jivesoftware学得拿来卖弄呀
注意我这篇文章的新意是：将AOP纳入过滤器实现一种，我们需要设计一个完全动态可插拔的系统，所有组件功能都是一块块plugin的过滤组件，就象位于光线穿透方向上的过滤镜一样，在软件系统中，客户端的请求透过一个个过滤器组件直至抵达数据库终端，所以这个请求走过的路线类似光的路线。

有了这个概念，最大的用处是什么呢？

Java编程有一个最大难点是什么呢？就是你编写代码时，脑子必须想的是代码运行状态，也就是说：手上编制的是表面上是暂时静止的代码，但是我们实际是假定它在运行，如何运行？是按照代码先后次序运行，这在传统过程语言编制中是一个基本规律，代码写到哪里实际运行就到哪里。

好了，到了OO语言Java中，我们反对一个方法中的代码超过10行以上，所以原来的本来堆积在一起长的过程代码被OO分离封装了，这就类似拼图游戏，一个整图被划分成很多小图，而且划分越细，小图越多，多得你都不能一下子把它们还原成一张大图。

这是拼图游戏得乐趣，也是OO带来给程序员得痛苦。

所以我们必须找出一个还原拼装成整图的有规律方法途径，也就是拼图的解决之道，那是什么呢？

就是使用过滤器概念，将你的业务功能划分为业务核心和过滤器两种，说白了就是业务层和核心层两个层，但是这两个层运行时必须组合运行，核心层其实就是使用过滤器实现。

puddlor

悄悄话
发表文章: 1
注册时间: 2006年01月04日 13:30

Re: AOP vs Decorator

2006年05月24日 09:44

消灭If/else?
其实更准确的是重复的else语句把。
OO的根本不过是从代码层，逻辑层等消灭重复代码，或逻辑，
如果只是简单的if/else，就使用重型的模式，是有点牛刀杀鸡的味道。
例如出现if/ifelse/ifelse/..等,多于3次重复时才是考虑使用模式的时候。只是为了证明自己是OO程序员，为模式而模式，呵呵，就有点问题了。

banq

悄悄话
发表文章: 9312
注册时间: 2002年08月03日 17:08

Re: AOP vs Decorator

2006年06月17日 16:26

看到网络web2.0谈到一种资讯过滤器，信息过滤器，这样的功能其实可以使用本篇文章介绍的过滤器技术实现。

技术发展和功能发展在互联网过滤器这个节点上重合，多么巧妙，特记录：
http://jeph.bluecircus.net/archives/005597.html

linhui

悄悄话
发表文章: 6
注册时间: 2007年11月05日 11:19

re:AOP vs Decorator

2008年01月02日 15:27

>>"过滤器是架构设计模式中比较常用的一种，几乎每个灵活动态系统都需要过滤器，特别是当我们的数据以内存状态出现时，过滤器无疑成为领域层的一个核心业务逻辑，当然如果你还是使用面向数据库的编程模式，过滤器功能就被你用SQL语句的where语法给替代了"

banq大哥，我在项目过程有个类似的问题，就是在查询的时候有个全局查询条件，每个查询都要包含这个字段，但由于分页要求，无法在查询结果返回之后进行过滤，这样将导致前几页的结果可能为空列表，所以我想过拦截所有的查询，动态添加全局查询条件，那这样是不是变成了面向数据库的编程模式，即“用SQL语句的where语法替代”，对于这样又全局查询条件，又涉及到分页，该如何设计？

这个主题有 15 回复／ 2 页 1 2 ►