从 .NET 中的 Form 类派生
理论上你可以从 Form 派生，但这是你不应该做的事情吗？ 我直觉上是这么认为的，但我从来没有听说过这样的规则。
我的意思是一些已经从 Form 派生的具体类。 例如，如果我有 class MyForm : Form，问题是：我可以从 MyForm 派生吗？
Theoretically you can derive from a Form, but is it something you should not do? I intuitively think so, but I've never heard of any rule like this.
I mean some conrete class that already derives from Form. For example, if I've got class MyForm : Form, the question is: can I derive from MyForm?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
创建新的 Windows 窗体时应该从 Form 派生。
在 Visual Studio 中创建新表单时，您获得的源文件已经派生自 Form。
You should derive from Form when creating a new Windows Form.
When creating a new form in Visual Studio, the source files you get already derive from Form.
没有任何硬性规定可以阻止您派生 Windows 窗体。 如果您有充分的理由这样做（例如，在整个项目的所有表单中加入一些常见的功能），那么就继续吧。
There's no hard and fast rule that prevents you from deriving a windows Form. If you have a good reason to do it (e.g., bolting in some features common throughout your project throughout all forms), then go ahead.
从通用基 Form 派生类派生表单是完全合理的，并且对于使应用程序具有标准外观和感觉很有用。
It's perfectly reasonable to derive forms from a common base Form-derived class, and can be useful for having a standard look and feel for your application.
我们已经成功地从表单派生出一个类，然后从中派生出项目中的所有表单。 它使我们能够轻松应用项目范围的策略。 我们所有的表单都具有一致的外观和感觉。 它还可以轻松地让每个表单记住其大小和位置。
We've had success deriving a class from form and then deriving all of our forms in the project from it. It allows us to easily apply project-wide policies. All of our forms have a consistent look and feel. It also made it easy to have each form remember its size and location.
我强烈建议从 BaseForm 继承。 这使得让所有 EditForm 看起来都一样变得非常容易，因为您可以在基础上设置通用控件（如按钮），为它们提供背景色/图像等。对于所有可以分组的表单也是如此。
我通常有 1 个 BaseForm，然后根据它的“组”（编辑、列表、对话框等）再有一个 BaseForm，
它使你的 winapp 看起来更加一致。
代码也是如此，通常编辑表单具有类似的代码库：验证、保存逻辑……您可以将所有这些逻辑放在基本表单上，然后有一些可以在子表单上实现的抽象方法。
I highly recommend inheriting from a BaseForm. This makes it very easy to f.e. make all EditForms look a like, because you can set the common controls on the base (like buttons), give them a backcolor/image, etc. Same goes for all sort of forms that can be grouped.
I usually have 1 BaseForm and then again a BaseForm according to it's 'group' (edit, list, dialog, ...)
It makes you winapp look more consistent.
Same goes for code, usually Edit form have a similar code base: validation, save logic, ... You can put all this logic on the baseform(s) and then have a few abstract methods that you can implement on the childform.
这个问题实际上取决于您的派生类的作用。
表单和许多此类最终类旨在执行许多复杂的任务，以便为您提供表单相关活动的充分优势，而无需编写太多代码。
规则是这样的，“如果你打算做一个简单的窗口操作，并且它不会干扰常规行为，那么最好不要从表单派生。
或者由于表单负载很重，你可以节省内存和CPU通过从基类而不是形式派生它来节省时间。
The question really depends on what your derived class does.
Form and many such end classes are designed to do lots of complex tasks to give you full advantages of form related activities without having to code too much.
The rule would be something like this, "If you intend to do a simple window operation, and if it may not disturb the regular behavior then its better not to derive from form.
Or since form is heavily loaded, you can save memory and cpu time by deriving it from base classes instead of form.