继承是正确的方法

Question

我们有一个基本TCP Server类，它提供Server functionallity。现在我们也希望提供安全的TCP服务器功能。我们正在讨论两种方法。

1. 将值传递给TCP服务器构造函数，指示它是否应该充当TCPServer或TCP安全服务器。

2. 创建一个继承自TCP Server类的TCPSecure类，这将需要覆盖基类的少数方法。

第一种方法的好处是它可以将所有内容保存在一个类中。

第二种方法看起来更正确。但我们不希望发生更多类型的推导。那么值得为此引入一个新类吗？

提前致谢。

Answer 1

第二种方法是正确的，如果且仅当每个TCPSecure可以用作非安全服务器的替代品，而没有使用服务器的对象注意到他们正在使用安全服务器。

这被称为Liskov substitution principle，是OO设计的基石之一。

Answer 2

不是传入一个值来表示对象是如何构造的（当只有2种类型而不是N类型时听起来很好）传入一个处理该类型逻辑的对象。也就是说，使用合成来分割在您的类中变化的区域，以便您可以将方差封装在其自己的对象中。继承的组合将使未来的重构更容易处理和实现。如果更改跨越所有N个子类型，那么N位置您需要更改它，但如果它只跨越构成某个对象的其中一个对象，那么，您看到了什么好处？

Answer 3

一般来说，行为开关并不像子类那样容易，所以我倾向于支持子类化。我不担心未来的子类化缺乏。可能最好的方法是拥有一个带有安全和不安全子类的服务器基类（或者你想要调用它们的任何东西）。

记住Liskov原则：TCPSecure应该是TCPServer的直接替代品，因为从编程的角度来看，它将完成TCPServer所做的一切。它不需要以相同的方式执行它，它实际上可以阻止某些用户行为，但调用它的代码不应该知道，并且调用函数不应该得到意外的结果。

另一个问题是安全性不仅仅是一个快速的附加组件。它需要关注整个系统。我认为这有利于子类化，因为它将安全行为放在一个地方。如果您使用行为开关，我建议让每个功能文档以不同的方式设置为安全或不安全。

Answer 4

听起来第二种方法很好。一个好的指标是确保它不违反Liskov Substitution Principle。

Answer 5

你必须看到正在发生变化并将其封装在自己的类中。有时简单地使用变量不起作用，尽管它似乎是最简单的使用方法。但随着时间的推移，随着需求的变化，这肯定会发生，它将成为维护代码并与之共存的负担，即依赖性。 继承是人们过度使用的东西，但在这种情况下，它可能是更好的解决方案。我不会使用变量来区分安全和不安全。随着时间的推移，维护代码将很难。