在 WPF 中创建自定义控件时如何克服从多个类派生的需要

发布于 2024-10-12 17:24:01 字数 323 浏览 10 评论 0原文

我知道 C# 不是 C++,因为它限制您从多个类派生,但是在开发 WPF 应用程序时有哪些方法可以克服它。

在我的场景中,我有一个第三方控件,它是一个滑块,它不是从内容控件派生的,因此没有内容属性。但是我需要拥有该财产。 我想到了几个解决方案:

  1. 从多个类派生(在 C# 中不可能) 将
  2. 附加属性添加到第三方控件
  3. 扩展第三方控件并添加 Content 属性及其运行所需的所有其他属性。
  4. 将第 3 方控件封装在我的自定义控件中并从内容控件派生。

哪种方法是最好的方法?或者如果您知道任何其他方法,请告诉我。

I know that C# isn't C++ in terms that it restricts you from deriving from multiple classes, but what are the ways to overcome it when developing a WPF application.

In my scenario I have a third party control which is a slider, it doesn't derive from content control, hence doesn't have a content property. However I need to have that property.
Several solution came to my mind:

  1. Derive from multiple classes (Not possible in C#)
  2. Add an attached property to the third party control
  3. Extend third party control and add a Content property and all other properties which are required for it to function.
  4. Encapsulate 3rd party control inside my custom control and derive from content control.

What approach would be the best one? Or if you know any other approaches let me know.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

南街女流氓 2024-10-19 17:24:01

我投票支持选项 4。从长远来看,组合似乎是比继承更好的选择。稍后,您将能够用其他东西替换您的第三方控制,而外界的任何人都不会知道这一变化。换句话说,您将对第三方控件的依赖封装在您的控件中。

I vote for option 4. Composition seems to be a better option then inheritance in a long run. Later you will be able to replace you third-party control with something else without anybody from outside world knowing about the change. In other words you will encapsulate the dependency on the third-party control in your control.

我的影子我的梦 2024-10-19 17:24:01

我会选择选项 3。这将允许您向第 3 方控件添加附加功能,而无需更新它(选项 2)。如果第三方提供商更新那里的解决方案,这将很有用。您不需要重新添加更改。如果您不需要从内容控制中派生控件,我不会选择选项 4。这可能会让未来的开发人员感到困惑。所以选项 3 似乎是最好的。

I would go with option 3. This would allow you to add additional features to the 3rd party control without needing to update it (option 2). This would be useful if the 3rd party provider updates there solution. You wouldnt need to re-add your changes. I wouldnt go with option 4 if you dont need your control to derive from content control. It might be confusing to future developers. So option 3 seems the best.

ㄟ。诗瑗 2024-10-19 17:24:01

选项 3... 将第 3 方控件的外观放在自定义控件上,该控件间接指向第 3 方控件的私有实例。尝试查看第 3 方控件的反汇编(使用 Reflector 或类似的控件)以查找可以实现的接口,以帮助构建外观。

Option 3... Put a facade of the 3rd-party control on your custom control that indirects to a private instance of the 3rd-party control. Try looking in the disassembly of the 3rd-party control (using Reflector or similar) for interfaces you could implement to assist with the building of the facade.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文