Design patterns 何时在具体类中隐藏继承层次结构？

每当我遇到一个工厂根据一些“低级”类型参数（如协议或外部资源的格式）将抽象基类实现返回给用户的情况时，我总是试图将抽象类转换为具有内部“策略工厂”的具体类这样用户就可以将实现类型传递给构造函数，并直接使用基类

---

我注意到.Net framework选择以这种方式实现套接字（而不是在构造时传递SocketType来创建DatagramSocket）。在决定何时可以接受将层次结构扁平化为一个具体的类时，有哪些指导原则？

我认为关键是：“客户应该了解多少底层细节？”

如果选择第一个解决方案（抽象基类），则会向客户机类隐藏更多细节。这样，客户端就可以完全忽略底层细节（协议、外部资源的格式）。当目标是完全隐藏实现细节和实现中使用的类型时，我更喜欢这种方法

---

否则，如果客户机已经知道低级实现的一些细节（例如，客户机知道他将使用的套接字是UDP，并且他也想知道这类信息），那么抽象基类方法可以用内部“策略工厂”代替

本着“更喜欢组合而不是继承”的精神，我总是选择策略+工厂方法而不是继承。这给了我两个优势： *大多数情况下，每个策略都可以单独测试，而不必关心将使用它的类。 *同样，客户机类也可以使用模拟策略进行测试 *策略可以被设计成可组合的，例如使用decorator模式，它提供了很大的灵活性，而不会导致子类爆炸

总而言之，如果所有子类的外部语义都是相同的（应该是相同的），那么遵循策略路线