Fluent接口与类复杂度

Question

Problem：使用许多方法实现fluent接口会导致类复杂性度量的快速增长。

如何为实现fluent接口的类保持低复杂度？

有关特定类的一些信息：

• 类已经有25种方法，并将得到另外15种方法。
• 类中的所有方法都以一种或另一种方式转换$this->wrapped对象。
• 几个(5-7)方法重用已经存在的方法(这些方法可以提取到类中，并通过继承添加，而不是在这里发布)。

已考虑的备选方案：

1. 特性-我想支持PHP5.3和更高版本。
2. 每种方法一种--大规模扩展链，不太好。
3. ‘'Plugins’--帮助类以某种方式注入到“主类”中，通过神奇的方法调用，并通过@method注释添加了自动完成支持。

反馈(在设计、性能、可维护性等方面)对于任何选项，都是备受期待的。

经核实的例子：

1. 罗达什：170个ish方法，1个类，8400行
2. Doctrine2 QueryBuilder：40+40-ish方法，2个类，1400+600代码行；通过ExpressionBuilder类分隔
3. Symfony2 FormBuilder：10种曝光方法，1级，300行

无论是从PHP实现角度还是从设计角度来看，问题都可以被认为是语言无关的答案都是同样受欢迎的。

编辑：

目的是要有一个好的(易于使用和易于维护)的功能编程工具(map，reduce等)。

Answer 1

复杂性是一种软件度量，用来表示开发人员对必须使用的理解缺乏理解。因此，软件实体(包/模块、类、方法)的复杂性越高，它的可维护性就越差。换句话说，修改和维护一个软件实体需要多少时间和精力。

类的主要复杂性类型是：

• Cyclomatic-Complexity:方法中的决策点数，如“if”、“while”、“for”、“switch”
• 通过该方法的非循环执行路径的NPath-Complexity:数
• 太大的类长度:类的指示做得太多了
• 太大的方法主体：对方法的指示做得太多了
• 太长的方法参数列表：应该按ValueObject分组
• 提供了太多的公共方法：表示中断互换性
• 太多的类字段/属性:缺少嵌套对象的指示
• 继承的子级数:不平衡类层次结构的指示
• 继承深度:不平衡/错误类层次结构的指示
• 对象之间的耦合:太多依赖项的指示

所有的类型都可以用工具来测量，并且有一个角点，这里的复杂度太高。在这种情况下，为了通过使用Design来降低复杂性，它是一个很好的重构嫌疑犯。衡量复杂性的另一个标准是，类的可测试性。我需要多少存根/模仿，需要多少断言，等等。

如何为实现fluent接口的类保持低复杂度？

Fluent接口是链接方法调用的设计模式。把最好的东西串起来就像真正的短语。它的目的是提供更具可读性的代码。因此，它降低了复杂性。只需增加一行代码即可实现Fluent接口，这只会对方法体和类长度产生较大的影响。因此，fluent接口对复杂性的影响非常低。

随着复杂性的增加，将最好的词组与真实的短语联系起来可能很困难，但是要想解决这个问题，代理类是可以实现的，它将操作委托给没有fluent接口的对象。

一般来说，降低复杂性的最佳方法是将单一责任原则、界面偏析原理、信息隐藏原理和松耦合作为关键方面。

Answer 2

一种方法是拥有一个简单、可靠的基类，为实现fluent接口类提供工具方法。然后，fluent接口类只调用基类来完成它所做的一切，将复杂度降低到单一的、流畅的接口类。

您是否已经为您的流畅界面进行了设计？(我想知道你实际使用了多少种方法。)