C# 中的接口、继承和 Windows 窗体
我有一个设计问题。 当编写一个应用程序时，其中有多个组件共享某些属性，而其他组件在 GUI（Windows 窗体）和后端方面又有所不同，理论上如何解决这一问题？
例如，我有一个应用程序，其中有 4 种不同类型的产品。 用于输入产品详细信息的表单都共享 3 个不同的字段。 到目前为止，很简单 - 有一个基类，然后从该基类派生出 4 种形式。 然而，例如，两种产品具有某种相同的行为。 当然，我可以有一个定义方法的接口，然后让这两个产品条目表单实现这个接口，但是由于接口没有提供默认实现，这样做不是很浪费吗？ 因为我必须在每个类中提供一个实现，如果它完全相同，那就是代码重复。
我当然可以将此方法放入基类中，并从它派生出两种形式。 如果我的表单共享多个共同元素并且不共享其他元素，那么最明智、最合乎逻辑的方式来表示这一点而不需要扯掉我的头发？
I have a design question. When writing an application where there are several components that share some attributes, and differ in others both in terms of GUI (windows forms) and back end, how would one theoretically approach this?
For example, I have an application where I have 4 different types of a product. The forms for entering product details all share 3 different fields. So far, easy - have a base class, then derive the 4 forms out of this base class. However, say, 2 products share a certain behaviour which is THE SAME for both of them. Of course, I could have an interface which defines methods, then have these 2 product entry forms implement this interface, but since interface provides no default implementation, wouldn't it be a waste to do that? Since I would have to provide an implementation in each class and if it is exactly the same, it would be code repetition.
I could of course put this method in the base class and have 2 forms derived from it. If my forms share more than one common element and not share other elements, what would be the sanest, most logical way to represent this without having to rip my hair out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么不让两个不相关的类直接从基类派生，然后创建一个具有通用功能并从基类派生的新类，并让其余两个类从该新类继承？
Why not have the 2 unrelated classes derive directly from your base class and then create a new class with the common functionality and is derived from the base class and have the remaining two classes inherit from that new class?
将共同行为引入两个类的一种方法是让两个类包含该行为作为成员，而不是继承该行为：对于表单，这可能意味着定义一个“用户控件”（即可重用的常用控件集合）。
One way to get common behaviour into two classes is for the two classes to contain that behaviour as a member, instead of inheriting that behaviour: for forms, this might mean defining a 'user control' (i.e. a reusable collection of common controls).
没有具体的布局很难说。 一般来说，另一种更灵活的重用形式是组合而不是继承。 事实上，控制层次结构显示了组合的强度。 也许您可以将 UI 的各个部分分离为自定义控件，这些控件根据您所追求的特定产品布局进行组装
Hard to tell without any specific layout. generally, the other , often more flexible form of reuse is doing composition instead of inheritance. In fact the control hierarchy shows just how strong composition can go. Maybe you can separate out parts of your UI into custom controls that are assembled based on the specific product layout you are after