|
管道过滤器（Pipe-And-Filter）模式
按照《POSA(面向模式的软件架构)》里的说法，管道过滤器（Pipe-And-Filter）应该属于架构模式，因为它通常决定了一个系统的基本架构。管道过滤器和生产流水线类似，在生产流水线上，原材料在流水线上经一道一道的工序，最后形成某种有用的产品。在管道过滤器中，数据经过一个一个的过滤器，最后得到需要的数据。 o 基本的管道过滤器：  管道负责数据的传递，它把原始数据传递给第一个过滤器，把一个过滤器的输出传递给下一个过滤器，作为下一个过滤器的输入，重复这个过程直到处理结束。要注意的是，管道只是对数据传输的抽象，它可能是管道，也可能是其它通信方式，甚至什么都没有(所有过滤器都在原始数据基础上进行处理)。 过滤器负责数据的处理，过滤器可以有多个，每个过滤器对数据做特定的处理，它们之间没有依赖关系，一个过滤器不必知道其它过滤器的存在。这种松耦合的设计，使得过滤器只需要实现单一的功能，从而降低了系统的复杂度，也使得过滤器之间依赖最小，从而以更加灵活的组合来实现新的功能。 这是mule3的flow基本处理流程，所有的transformer、filter、component、router都是Message Processor（MP），多个MP可以链接在一起顺序执行。 管道过滤器（Pipe-And-Filter）模式也就是pipe-filter架构风格，参见《软件架构》： http://blog.csdn.net/zhangshoucheng/article/details/4149415 这篇文章不错，讲述了架构、模式的发展历史，里面也提到了pipe-filter架构风格，你应该看看，得知道老外的软件设计经历的发展阶段。目的只有一个： “如何解决模块之间的依赖性？如何使设计有利于设计和代码的维护和扩展？” 像mule这么大规模的软件系统，不去划分职责直接编码的话，所有代码将混杂而庞大，无法维护无法继续发展下去的。所以说架构、设计模式更多是为了清晰（可维护）、职责明确（可发展），是为了适应大规模软件的代码组织方式的最佳实践，而不是为了完成新功能的新技术。 有兴趣可以再看看：http://www./wiki/blog/782740 总之，搞java的有各种开源可以拿来用，也没有必要再去研究各种规范、标准再自己去重新制造“轮子”（说实话这个可能更难，因为英文规范的研究你也知道是很困难的），但是如何组装好这些“轮子”的技巧是要去知道、最好掌握的，mule本身就是这样一个博采众长的例子，mule的lib中来自其他开源的opt中的jar要比mule自己的jar多得多。 |
|
|
