在这个讨论中(创建流畅API),一位回答者指出,建造者模式比使用扩展方法来创建流畅接口更好。为什么会这样呢?扩展方法遵循SOLID原则中的"O"。我个人只在开发流畅接口时使用扩展方法,但现在想重新考虑一下是否需要改变这种做法...
这个SO问题描述了扩展方法的缺点。 此外,一些人认为,扩展方法违反了开闭原则,而不是遵循它,因为它们以可能不被原始创建者预期的方式引入了功能。 如果建造者模式可以在没有缺点的情况下实现相同的目标,那么为什么不使用它呢。
我想到的一件事是,扩展方法并不是用于流畅API而是用于扩展类型功能。构建器模式需要更多的理解,与柯里化、单子和函数式编程有关。因此,后者是更好的概念基础,可以翻译成许多语言,而前者是C#术语,在其他语言中可能没有对应项。如果两种方法产生相同的行为,则可以自由选择其中一种。但是,您还应考虑所需/想要的功能:代码的表达能力、可读性、可移植性、安全性和性能都是可能在两种选择之间有所不同的质量。