Zend Framework的缺陷（连载之5）

    上一节我们讲的是Zend Framework中相对于基本编程规范的违规。也许有人会说，这种违规是可以忍受的。代码中一些地方的烦琐有时是必须的。我们可以接受这样的不同意见。那么，如果一个框架在面向对象的基本原则中违规，那你还可以忍受吗？
     设计模式和代码重构理论，是基于基本的面向对象的基本原则。这里我们有必要先讲一下这些基本原则：
     开闭原则（OCP）：对可变性进行封装。对象必须能对自己负责。这与单一职责的原则是完全一致的。
     里氏代换原则（LSP）：如何进行继承。继承必须维护遗传。而不能产生变异。这里的变异是指破坏了原有的结构与数据关系。
     依赖倒转原则（DIP）：要针对接口编程。不要针对实现编辑程。抽象不应当依赖于细节；细节应当依赖于抽象。
     接口隔离原则（ISP）：恰当地划分角色和接口。使用多个专门的接口比使用单一的总接口要好。
     合成/聚合复用原则（CARP）：尽量使用合成、聚合，尽量不使用继承。继承是“Is-A”关系。合成/聚合是“Has-A”关系。
     迪米特法测（LoD）：不要和陌生人说话。即：不存在对间接关系类的任何操作。
     这六大原则，相对于初学者，也许过于抽象。不过，不要紧，我们下面的缺陷分析，有助于你对这些原则有一些具体的认识。
     假如你是一个系统架构师，那么，你现在也许会说，我说的情况，在Zend Framework中根本不存在。
     那么，我们还是从更具体的实例进行分析吧。
     Zend Framework中有很多地方完全属于烂用依赖倒转原则（DIP）。简单来说，假如变化本身，只是一个方法，一个函数，相对于PHP，我们根本不需要使用依赖倒转原则为此定义出一个接口，并让用户去写只有一个方法的类，产生一堆这样的类文件。
     一个实例：Zend Framework中的Filter类，就是这种不良代码的典型！！这样做的坏处，那就是，变化的一切均分布在不同的类中。不仅不易于管理，同时也影响效率。另一方面，PHP5，提供了 __call, call_user_fuc, call_user_fuc_array， 所有这一切，均是为给这一种特别的聚合提供方便。凭错这些，我们可以直接增加函数列表，而函数列表，相对于代码管理，更加方便，并且，单一方法上的添加，可以直接使用继承法。但直接继承的结果，则是破坏了类与类之间的偶合。但如果是真的松耦合，那继承就没有什么关系。
     一种放松耦合的实现方式，即使用相关的配置，并使用createInstance一类的方法，创建指定的类的实例，这可能是一种高难度。一般架构师或程序员不一定能设计出这样的代码。
     最后，还需要说的是， Zend Framework中的Filter类即便是目前这样，也应当写得更好，Filter现在是把Filter与validate给混淆了。同时，所谓的链式操作，实际仍是不方便的操作，PHP函数，原本就可以接受不定数量的参数，所以，完全可以不用链式操作，而一次性传入所有要过滤的类型。但它没能做到。再有就是，输入与输出，原本应当要分开的，但却也是搅合在一起。假如，一个编辑器，输出是的 23,456,321这种格式的数字，表单提交后，用户很容易会直接使用整数过滤器。则肯定会出错。
      Zend Framework中实际这样的实例是相当多的。这里就不多说了。

附：非常高兴，已经看到有人拍砖了，参见：
      http://www.netroby.com/article-1706.html
     由此：这里需要声明一下：此文的目的，不是为了抵毁Zend Framework，而根本的目的，是在于两点：其一，教会大家，如何选择自己合适的开发框架；其二：让一些“框架开发者”清楚，一个框架究竟要做成什么样子。特别是，国内那些希望自己的框架能够拥有用户的开发者。很多是不了解一个大型企业开发的实际需求，闭门造车。个人观点，一个真正完全了解Zend Framework缺陷的人，才能开发出有拥户的有技术含量的框架，如同CI架构，确实是改观了一种缺陷，但只能用于小型网站，或许，它的定位就是如此。但如果拿它与Zend Framework相比，它就是一种玩具！  第三，我所识为的缺陷，也很可能是认识上的误区。因而，在此能引得同道的共同探讨，则有利于彼此的进步。
      所以，继续希望有人拍砖，但骂街性质的，强词夺理的（比如：说什么Zend Framework2.0肯定会改掉这些缺陷等观点），本人不会理会。所以只能说声抱歉。
      热烈欢迎一切理智的技术讨论。

评论

5 楼 nm052001 2010-09-16  

其实。楼主也应该写一下ZF 的优点。和symfony 的优点。
看看各框架的利弊所在

4 楼 netroby 2010-05-25  

Zend Framework的市场也不是应该由我来操心的，你写什么我不关心。维基百科用symfony，没用Zend Framework也不能说明什么问题，你不妨找一个实际应用中用Zend Framework来开发，拖累了开发进度的例子，以便更好的证实你的论调。
在我公司的实际开发中，ZendFramework的使用还处在小规模局部化应用，注重效率的地方，还是用裸写调优后代码来处理的。也并未看出来ZendFramework带给我们很多负面的影响。

如果你不放心ZendFramework的表现，你可以选 择你所看好的symfony，也可以自行解决你的需求。
当然了，跟本系列文章的主题思想就相去甚远了。

框架只是工具，去芜存精，适当加以利用，才能发挥它的最大价值。

我看待框架，带着辩证思维，在找不到证明Zend Framework是一无是处的框架的前提下，我保留慎用的观点。


你的这系列文档只提到Zend Framework一些做的不好的方面。如果你够大度的话，不妨写一些公正的文章来分析Zend Framework的优异点，这样才会给没有接触Zend Framework或了解不深的使用者更全面的认识。

3 楼 bardo 2010-05-23  

netroby 写道

正如你连载五篇所说，我也注意到你提的这些问题，但我说我期待zend framework在2.0版会有更好的表现，怎么在你眼中就成了强词夺理了？
你说ZendFramework现在怎样怎样，我无可辩驳，因为问题的确有存在。但你也不能否认ZendFramework还在不断成长和完善当中。
如果你对ZendFramework有更好的见解和论点，何不尝试成为Commiter呢？总比这边大谈特谈来的要好得多。
你只能让没接触过ZendFramework的开发人员心生畏惧，原来ZendFramework这么不堪造就？
其实真正又是怎么一回事呢？

你好像担心的是本人的文章影响zend的市场，是吧？我写与不写实际对实际市场的影响力相当小，你不妨看看现实：维基百科，用的是symfony,而不是ZendFramework，如果要选现有的框架，我个人肯定选symfony，因为它是最成熟的，鞭开发插件的人数，可用插件也是相当多的。一个不大的主框架，加上大量的可选插件库，远远要比40M的大多数功能用不上的代码要强得多。ZendFramework怎么说都不容乐观。与我写什么无关！！

2 楼 netroby 2010-05-22  

我不会骂人，因为我关心的是技术，我只是如何能更好的利用这些工具来服务我们的开发需求。
你应该还注意到我所说的，框架不是必须要用的，要看需求的。我在实际开发中，也不尽都用了框架，有时为了效率和性能，还是写简单的语句更为适宜。

1 楼 netroby 2010-05-22  

正如你连载五篇所说，我也注意到你提的这些问题，但我说我期待zend framework在2.0版会有更好的表现，怎么在你眼中就成了强词夺理了？
你说ZendFramework现在怎样怎样，我无可辩驳，因为问题的确有存在。但你也不能否认ZendFramework还在不断成长和完善当中。
如果你对ZendFramework有更好的见解和论点，何不尝试成为Commiter呢？总比这边大谈特谈来的要好得多。
你只能让没接触过ZendFramework的开发人员心生畏惧，原来ZendFramework这么不堪造就？
其实真正又是怎么一回事呢？