缠绕或不缠绕

我想这是一个相当主观的问题，所以我会站点一个具体的例子。缠绕或不缠绕

虽然考虑使用System.Management命名空间来封装对WMI信息的访问的一组包装类的设计，但我有一个问题，我开始想知道如何满足需要一次性值的情况，比如说BIOS编号为Win32_BIOS，也适用于可能需要许多不同属性或更复杂搜索的情况，例如搜索CIM_DataFile中的文件。

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

对于这类问题，普遍的共识是什么？在编写复杂的包装类时希望稍后节省时间还是值得的，或者更好地坚持内置类的灵活性，即使它有时似乎并不特别干净或整洁。

来源

2014-01-22 Ashigore

+1为好标题 –

你是否在意能够模拟你正在包装的课程？如果是这样，那么是的。 –

这个问题可能更适合于http://programmers.stackexchange.com/ –

包装类的目的是为了隐藏调用者的复杂功能。

换句话说，如果所有的调用应用程序想要做的是找出序列号，那么它应该只是调用像myobj.GetSerialNumber()这将使所有的WMI调用所需的所有返回该值。但是，如果调用应用程序已经深入到WMI中，或者如果您发现自己模仿WMI的工作方式只需稍作更改，那么最好不要包装它，让调用应用程序执行它的操作。

来源

2014-01-22 17:20:48 NotMe

我觉得这对我有很大的意义，但是当我这样做时，我开始认为我应该真的把这样的包装变成可重用的库和复杂的雪球。 – Ashigore

@Ashigore：一个给定的代码库应该像解决你所面临的问题一样复杂。换句话说，只能将其视为可重用以解决当前问题。如果稍后您发现您的代码可以在其他应用程序中重用，那么您可以重构它。实际上，在最初建立用于重复使用的情况下，也就是说，当您已经拥有多个系统并且您知道的规格将会占据优势时，情况非常罕见。 – NotMe

我这样说的主要原因是你完全不知道未来任何系统的要求是什么。因此，你完全不知道他们可能需要什么功能。这意味着无论如何，无论如何你都会重构你的图书馆。现在更好地保持简单，只在实际需要时才引入复杂性;即使这样也只会引入所需的复杂度。 – NotMe

缠绕或不缠绕

回答

相关问题