1

我目前正在开发一个可以在连接到 PC 的设备上读取和设置配置值的库。每个配置字段都由一个常量 ( public static readonly) 对象描述，该对象包含该字段的名称、其数据类型（以及值限制）以及读取/写入它所需的命令序列。

这些信息大多只在图书馆内需要。但是，客户端代码需要能够告诉库读取/写入特定字段，并且我还想在将字段与其值相关联的字典中传递配置值的集合。为此，我需要提供标识字段的公共值。

可以使用相同的对象在内部描述字段并公开标识它们吗？感觉有点不对劲，但我无法说出原因。我希望您可以消除我的疑虑，或者告诉我为什么这是一个坏主意或要注意什么。

更新：我最终为字段标识和实现字段访问使用了相同的对象。现在，几个月后，我终于遇到了一个问题，它强调了为什么这不是一个干净的解决方案：正如我上面提到的，一个字段对象代表设备上的一个配置字段。这与访问此类字段的方式无关。

更笼统地说：我对事物的隐藏内部表示并没有描述事物。它描述了与不一定具有 1:1 关系的事物相关的事物。

如果您想更改字段访问权限，这可能会成为一个问题。例如，现在我无法创建一个提供“错误重试”访问行为的字段装饰器类。使用装饰器的代码会将其视为自己的字段，与实际的底层字段无关。

请注意，这不是对原始问题的回答，而是意识到我的假设是错误的。如果您真的确定您对事物的内部描述与事物本身具有 1:1 的关系，则此问题不适用。

4

1 回答 1

2

这实际上取决于您的库如何运作以及客户端代码如何与之交互。将内部表示暴露给客户的一个潜在问题是，在不破坏客户代码的情况下，您没有足够的灵活性来更改内部表示。但是，我认为这不会太难克服，因为在您需要内部不同表示的时间点，您可以创建一个新的内部表示，并将旧表示保留为公共 API 的一部分.

如果您决定将内部表示作为公共 API 的一部分公开，需要注意的一件事是意外的副作用。例如，假设客户端代码向您传递一个对象，然后您在内部存储该对象。对象在 C# 中通过引用传递，这意味着对该对象的任何修改也将发生在内部存储的对象上。当然，您可以只制作对象的副本，这样就不会出现此问题。

最后，您可能想退后一步，从客户端的角度考虑公共 API（如果您还没有）。也许尝试在一些单元测试中使用它。您可能会发现，从客户的角度来看，内部表示并不是表示它的最佳方式。

For very simple API's using the internal structure is probably ok. I always tend to lean the other direction, and would opt for an abstraction and an isolation in my design that segregates the public API from the inner workings.

It's all about tradeoffs and just depends on what you're trying to accomplish. Hopefully this will help your decision a little bit.

于 2012-11-02T01:53:35.137 回答