Fluent 接口和类复杂度答案

【问题标题】：Fluent Interface and class complexityFluent 接口和类复杂度
【发布时间】：2014-03-14 16:29:22
【问题描述】：

问题：使用多种方法实现流畅的接口会导致类复杂度指标增长得非常快快。

实现流畅接口的类如何保持低复杂度？

关于特定类的一些信息：

已经考虑过的选项：

反馈（关于设计、性能、可维护性等）备受期待。

检查示例：

可以将问题视为与语言无关 - 从 PHP 实现和设计的角度回答同样受欢迎。

编辑：

目标是为函数式编程（map、reduce 等）提供漂亮（易于使用和易于维护）的工具

【问题讨论】：

如果流畅的界面增加了那么多复杂性，不围绕流畅的界面进行设计怎么样？
你到底在想什么？
抱歉，我不明白fluent interfaces 是如何增加类的复杂性的。具有和不具有流畅接口的类之间的区别在于在方法中返回对同一对象实例（$this）的引用，该引用不返回其他值，最多增加 1 个 LOC pro 方法（并且没有额外的圈复杂度）。还是您的意思是流畅界面和/或复杂性的另一种定义？ @Im0rtality
理论上你是对的。然而实际上这些方法将有超过 1 个 LOC/方法（它必须在 return $this 之前做一些事情）。复杂性很快就会增加。

【解决方案1】：

复杂性是一种软件指标，表明开发人员对必须与之合作的开发人员缺乏理解。因此，软件实体（包/模块、类、方法）的复杂性越高，它的可维护性就越差。或者换句话说，修改和维护一个软件实体需要多少时间和精力。

类的主要复杂性类型有：

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

实现流畅接口的类如何保持低复杂度？

Fluent Interface 是一种用于链接方法调用的设计模式。最好的链接看起来像真正的短语。它旨在提供更具可读性的代码。因此它降低了复杂性。只需添加一行新代码即可实现 Fluent Interfaces，这只会影响较大的方法体和较大的类长度。因此，流畅的界面对复杂性的影响非常低。

随着复杂性的增加，最好用真实的短语进行链接可能会很困难，但要标记这一点，proxy classes 可以做到这一点，它将操作委托给没有流畅接口的对象。

【讨论】：

完全没有抓住重点。问题不在于流畅接口类的用法，而在于实现了流畅接口本身的类。请参阅问题的第一行“问题：实现流畅的界面...”而不是“问题：使用 ...”
在类本身实现简单的流利的接口不是复杂性的问题。如果您要为真正的短语使用实现流利的界面，这可能是一个问题，因此您可以通过代理访问它以标记复杂性。我试图在答案中说。

【解决方案2】：

一种方法是拥有一个简单、可靠的基类，该基类提供实现流畅接口类的工具方法。然后，流畅的接口类只需调用它所做的所有事情的基类，将复杂性降低到单个流畅的接口类。

您是否已经为您的流利界面设计了一个设计？（我想知道您实际上会使用多少种方法。）

【讨论】：