部分课程或“链式继承”

Question

从我的理解中，部分课程有点被专业开发人员所诟病，但我已经过了一些问题;

我已经制作了一个RichTextBox控件的实现，该控件使用user32.dll调用来更快地编辑大型文本。这导致了很多代码。然后我向控件添加了拼写检查功能，这是在另一个继承RichTextBox控件的类中完成的。这也构成了一些代码。

这两个功能是非常独立的，但我希望它们合并，以便我可以在我的窗体上放置一个控件，该窗体既具有快速编辑功能，又具有内置的拼写检查功能。我觉得简单地将代码添加到一个类中到另一个会导致一个太大的代码文件，特别是因为有两个非常独特的功能区域，所以我似乎需要另一种方法。

现在我的问题;为了合并这两个类，我应该让拼写检查RichTextBox从快速编辑继承，继而继承RichTextBox？或者，我应该让这两个班的部分班级成为一个班级，从而让他们更“平等”这么说？

这是更多的OO原则和运动的问题，比我试图重新发明轮子，我知道有很多很好的文本编辑控件。但这只是我的一个爱好，我只想知道这种解决方案是如何由专业人员管理的。

谢谢！

Answer 1

我不完全相信，如果我明白你正在尝试做什么，但就我看来，你只是在寻找Decorator design pattern。如果这不足以解决您的问题，并且您真的在考虑编写特性类，请参阅Policy based design，尽管我不太确定在C＃中可以实现多少。 还有一本书 - Modern C++ design它是基于策略的设计的支持者，但它讨论了所谓的部分类与（多）继承之间的权衡。链式继承的问题在于决定顺序，因为该顺序会产生强烈的依赖关系，并且如果将拼写检查添加到RichTextEdit中，则一旦您想对例如“拼写检查”使用拼写检查，就会遇到问题。 SearchBox，它可能是SimpleEdit，但为用户提供拼写检查会很好......我希望这至少有一点帮助。

Answer 2

这里有一个多重继承的论点！

您可以为功能定义接口（IFastEditTextBox和ISpellCheckingTextBox）并在每个接口中实现方法。这将是更多的面向对象，但有可能“复制和粘贴”代码。

在这里使用部分类没有任何问题。与他们唯一的根本问题是他们可能会鼓励一个开发人员已经倾向于采用程序方法将所有代码编入一个类。