为应该在复杂软件(使用 c#/wpf 编写)中使用的大多数控件创建一个接口(interface)是个好主意吗？目前我们遇到的问题是，我们使用 Microsoft 和一些第三方公司的控件。我们的问题是，如果我们想更改一些第三方组件，我们不想更改 howle 软件，因为我们为客户做了很多定制。
那么，为我们使用的每个控件创建一个抽象类，并且只使用抽象类/接口(interface)提供的成员是个好主意吗？
也许出于某些原因这是一个糟糕的解决方案，我不明白。
谢谢!
最佳答案
这是一个很深的问题，但我会尽力给你一个答复。
首先我要说的是，将表示逻辑与 UI 控件分开是非常好的。通常，您应该看一下源自 MVP 的设计模式或使用当前流行的模式，即 Martin Fowler 发明的所谓“展示模型”。
我强烈建议阅读有关软件设计和最佳实践的所有信息。一个好的开始是阅读这里的所有内容:http://martinfowler.com/eaaDev/OrganizingPresentations.html
根据我的经验，在 UI 和表示逻辑之间进行分离的最大好处不是改变 UI 技术，而是让您可以自由地非常轻松地测试您的表示逻辑。在我的整个职业生涯中，我从未切换到另一个 UI 控件提供商。
因此，请牢记可测试性，而不是改变 UI 技术。
谈到模式，在 WPF 中(您说您使用 WPF)已经使用了一种表示逻辑模式 => 所谓的 MVVM 并不是什么花哨的东西，而是换了品牌的旧表示模型。
与您如何看待问题有关...您所描述的方法与“模型- View -演示者”模式更相关，更准确地说是被动 View 子模式，其中控件被抽象为表示逻辑使用接口(interface)。状态存在于 UI 中，逻辑存在于 Presenter 中。这与状态在演示者中并且逻辑也在那里的演示模型模式相反。
我认为您不应该在您的应用程序中混合使用多种表示模式，我的建议是:让 MVVM 作为您的基本模式并尝试正确地使用它。这种模式将增强可测试性，我认为您永远不需要根据您的情况更改 UI 技术。但即使您要更改它，如果您在 MVVM 模式上正确编码，更改也是可行的。
关于c# - 复杂软件中的所有控件是否都应继承自编写的界面，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31547593/