基于OOP设计新函数：两种foo函数实现方案的设计局限探讨

假设我们需要一个foo函数，接收A接口的实例，生成B接口的实例。下面分析两种设计方案各自的问题：

设计1 #

class A {
  foo(): B { /* … */ }
}

• 职责太杂：A类本来只该负责自身的核心功能，现在硬塞了生成B实例的逻辑，后续维护时，改A自身的代码可能影响B的生成逻辑，改B的生成逻辑也得动A，两头牵扯。
• 耦合太紧：A直接绑定了B的接口，要是B的定义变了（比如生成逻辑调整），A类必须跟着改，维护成本直线上升。
• 扩展麻烦：以后要是加A的子类，每个子类生成B的逻辑不一样，要么每个子类都重写foo方法，要么在父类A里堆一堆条件判断，越改越乱。
• 复用性差：生成B的逻辑绑死在A类里，别的地方想用A实例生成B，必须通过A的实例调用，没法单独把这个转换逻辑抽出来复用。

设计2 #

class B {
  static foo(a: A): B { /* … */ }
}

• 职责不纯：B类核心是管好自己的属性和行为，现在静态方法foo把A转B的逻辑塞进来，B的职责就变杂了，不再是纯粹的B类。
• 耦合问题：B类依赖A接口，一旦A的结构变了，B里的foo方法必须跟着改，维护起来一样闹心。
• 扩展受限：要是以后出了A的子类，需要不同的逻辑转成B，或者要生成B的子类，静态方法foo没法灵活调整，要么在方法里加一堆分支判断，要么新增静态方法，代码越写越乱。
• 测试费劲：静态方法不好模拟替换，测试B的生成逻辑时，必须用真实的A实例，没法用Mock来隔离测试，增加了测试的复杂度。

内容的提问来源于stack exchange，提问作者Dennis Kats