C# 包还是不包

我想这是一个相当主观的问题，所以我将给出一个具体的例子

在考虑使用

System.Management

命名空间设计一组包装类来包装对WMI信息的访问时，我遇到了一个问题，我开始想知道如何满足需要一次性值的情况，比如Win32_BIOS中的BIOS序列号，也适用于可能需要许多不同属性或更复杂搜索的情况，例如在

CIM_DataFile

中搜索文件

这让我想知道，像System.Management命名空间中提供的那样包装功能是否是一个好主意，或者最终我是否会以减少应用程序中代码量的名义添加不必要的复杂和冗长的包装类

---

对这类问题的普遍共识是什么,，为了节省以后的时间而编写复杂的包装器类是否值得？或者，即使有时看起来不是特别干净或整洁，还是坚持使用内置类的灵活性更好。

包装器类的目的是对调用方隐藏复杂的功能

换句话说，如果调用应用程序想要做的只是找出序列号，那么它应该只调用类似于

myobj.GetSerialNumber（）

的东西，这将使所有WMI调用都必须返回该值

---

但是，如果调用应用程序已经深入到WMI中，或者如果您发现自己只需做一些小的更改就可以模仿WMI的工作方式，那么最好不要将其包装，让调用应用程序自己完成它的工作。

+1对于这个好标题，您是否关心能够模拟正在包装的类？如果是的话，这个问题可能更适合我考虑.NET类的包装器（在这种情况下是一个包装器本身，我相信）只有当我发现自己在同一个代码中在我的应用程序中的多个地方一遍又一遍的写同样的代码。干净、优雅的代码是一个伟大的目标和标准，但如果以复杂性、可理解性和可维护性为代价，它就不值得（IMO）。我觉得这对我来说很有意义，但是当我这么做的时候，我开始想我应该真的把这样的包装器做成可重用的库，然后再把复杂性变成雪球。@Ashigore:给定的代码库应该是解决您所面临的问题所必需的最复杂的。换言之，只在必要时使其可重用，以解决您当前的问题。如果以后您发现您的代码可以在另一个应用程序中重用，那么您可以重构它。实际上，在很少的情况下，最初为重用而构建是可行的。。。也就是说，当你已经有了多个系统，并且你知道这些系统的规格时，你就会利用它们。我这么说的主要原因是你完全不知道未来系统的需求是什么。因此，您完全不知道他们可能需要什么功能。这意味着不管怎样，您都将重构您的库。现在最好保持简单，只有在实际需要时才引入复杂性；即使这样，也只会引入所需的复杂性。是的，这是有意义的，节省了浪费时间包装我甚至不需要的功能。非常感谢。