为什么要避免形式继承？
我记得学习VB4并将一个按钮拖动到窗体上，双击该按钮，然后在刚刚被我神奇地祝福的事件处理程序中键入代码。来自QBASIC，我为“ VB”中的“ V”而感到激动，这是自切面包以来最好的视觉设计师。 当然，您可以通过编程方式完成所有这些操作，但是“ V”的魔力是如此吸引人，您只能忍不住拖动该按钮。我们被鼓励走那条路。 但是几年前，我开始学习C＃和.net框架，并且对我以为我知道的一切刚刚消失的方式着迷。VB6中发生了很多神奇的事情，.net完全揭开了它的神秘面纱：以构造函数和InitializeComponents方法为例。在后者中，您将找到从工具箱中拖动的所有控件实例，已注册的所有事件以及在设计器中设置的属性。 很好...我想。只是，我感觉我不“拥有”正在发生的事情，我只能通过设计者修改的这段代码使我烦恼不已。每次将一个表示“确定”的按钮从一种形式复制到另一种形式（有时连同其兄弟“取消”）时，您实际上是在复制代码，这是一种罪过吗？教皇说，干，别重复。 除了客观存在的宗教和思想流派之外，我们是否不应该从基本表单中获取表单，并让“确定”按钮（及其所有朋友）都在基本表单上生活？像a这样的东西FormBase衍生出a DialogFormBase; 立即创建所有类...通过键入代码。根据实例的类的创建方式创建按钮（即，构造函数的enum参数确定要创建的按钮），将控件布置在拆分面板和流布局面板的内部，并按如下方式插入表单Content适用于主要内容面板。这不是ASP.net对母版页和内容占位符的作用吗？当我需要一个新的“母版页”时，我会派生一个表单，但是这个新的“母版页”仍然派生自基本表单类，因此整个应用程序的视觉效果是一致的。 对我来说，这是很多更多的代码重用比什么都重要，我曾经在的WinForms设计师做的，它甚至不是辛苦，代码不与200线方法混乱，我无法控制，我可以将评论放在我喜欢的位置，它们不会被设计师覆盖。我想这只是模式和体系结构的问题，这就是带我进入此链接的地方：能够共享通用功能的Windows窗体的最佳设计，我在那里发现，除了那里的答案外，我确切地表明了我的意思。这样做，但它建议对形式的继承，因为设计师的考虑。那是我不了解的部分。出于代码结构方面的考虑，尤其是在形式和控件继承方面，我认为没有理由要避免，除非这样做会破坏设计人员。 我们不能都只是懒惰，所以我缺少哪一部分？