第一个问题：）
基本上我想在.NET WinForms项目中实现多个表继承。
我们使用具有2个基类的框架：UIForm和UIWizard。我们（不幸的是:)被迫使用这些表单开始我们自己的实现。
除此之外，我们构建了以下结构： UIForm是OurForm的超类。 UIWizard是OurWizard的超类。 OurForm和OurWizard几乎都是双胞胎 OurForm本身也是其他形式的超类：OurCrudBase，OurListBase，OurSearchBase，...
机会
OurForm和OurWizard包含“档案”相关的属性和方法，而这个档案上下文与许多形式无关。更糟糕的是，我们最近开始添加具有全新上下文的表单：现有的档案，还有客户，统计等。
所以这里是
我们想要一个同时是CrudBase和DossierBase的Form。或者是ListBase和ClientBase等的表单。为了实现单继承，基础表单的数量会爆炸（即DossierBase + CrudBase + ListBase等）。所以我们不想这样做。
解决方案
我们正在考虑删除UIForm，说UIForm实际上是一个UIWizard，但只是“一步”。 BaseClasses的数量已经减少了一半。
基类实际上可以分为两类
- 功能：档案，客户，统计，...
- 技术：Crud，List，Search，......
UIForm将成为技术或功能形式的超类。另一种类型将实施为策略。
功能派生类：
+ 表单只能是其中一个功能类。不能为“stastics”和“client”创建表单。通过这种方式，继承在这里是有意义的
+ 可能会将技术功能实施为策略。我在想一个接口，基本上有一个方法可以解决窗体上可能发生的一切：加载，保存，关闭，关闭，...
- 不同策略之间的互动可能会很混乱。 （即确保当你将List和Crud放入一个实现不会相互混淆的形式时）
技术衍生课程：
+ 不知何故，我对这种方法有了更好的感觉。 （即使我只能列出负面因素）
- 如果要组合使用List + Crud，则需要重复的课程。但重复的数量很少
- 客户，档案，统计没有共同点。所以将它们变成一种策略是相当困难的。
我想我已经回答了自己的问题。但你同意吗？或者你认为我是否过度思考这个问题，我是否应该尽可能多地接受超级课程并尽可能少继承？ 或许是一种完全不同的方法来解决这个问题？
非常感谢任何帮助！
干杯，
沃特
答案 0 :(得分：3)
根据你的描述，我不太明白为什么你需要继承。看起来你可能最好使用合成而不是继承。
我建议您创建组件，控件和代码模板来处理不同的问题，然后您可以拖动您需要的内容。您可以只使用一个基本表单覆盖需要覆盖的方法/属性，并为组件/控件提供一种简单的方法（例如引发事件），以执行他们需要执行的任何自定义工作。