.NET 流功能 - CanXXX 测试安全吗？

Question

.NET 中使用一种相当常见的模式来测试类的功能。 这里我将使用 Stream 类作为示例，但该问题适用于使用此模式的所有类。

该模式是提供一个名为 CanXXX 的布尔属性来指示 XXX 功能在该类上可用。 例如，Stream 类具有 CanRead、CanWrite 和 CanSeek 属性，表示可以调用 Read、Write 和 Seek 方法。 如果属性值为 false，则调用相应的方法将导致引发 NotSupportedException。

来自流类的 MSDN 文档：

根据底层数据源或存储库，流可能仅支持其中部分功能。 应用程序可以使用 CanRead、CanWrite 和 CanSeek 属性查询流的功能。

以及 CanRead 属性的文档：

在派生类中重写时，获取一个指示当前流是否支持读取的值。

如果从 Stream 派生的类不支持读取，则调用 Read、ReadByte 和 BeginRead 方法会抛出 NotSupportedException。

按照以下方式编写的：

if (stream.CanRead)
{
    stream.Read(…)
}

请注意，没有同步代码，例如以任何方式锁定流对象 - 其他线程可能正在访问它或它的对象参考。 也没有代码来捕获 NotSupportedException。

MSDN 文档没有声明属性值不能随时间变化。 事实上，当流关闭时，CanSeek 属性会更改为 false，这展示了这些属性的动态性质。 因此，没有合同保证上述代码片段中对 Read() 的调用不会抛出 NotSupportedException。

我预计有很多代码都存在这个潜在问题。 我想知道那些发现这个问题的人是如何解决的。 什么样的设计模式适合这里？

我也很感谢对此模式（CanXXX、XXX() 对）有效性的评论。 对我来说，至少在 Stream 类的情况下，这代表了一个试图做太多事情的类/接口，应该分成更基本的部分。 缺乏严格的、记录在案的合同使得测试变得不可能，实施也变得更加困难！

Answer 1

好吧，这是另一个尝试，希望比我的其他答案更有用......

不幸的是，MSDN 没有给出关于如何 CanRead/CanWrite/< code>CanSeek 可能会随着时间的推移而改变。 我认为可以合理地假设，如果一个流是可读的，它将继续可读，直到它被关闭 - 并且对于其他属性也同样如此。

在某些情况下，我认为流到 是合理的稍后变得可查找 - 例如，它可能会缓冲它读取的所有内容，直到到达底层数据的末尾，然后允许在其中查找以让客户端重新读取数据。 然而，我认为适配器忽略这种可能性是合理的。

这应该可以处理除了最病态的病例之外的所有病例。 （流的设计几乎就是为了造成严重破坏！）将这些要求添加到现有文档中理论上是一个重大更改，尽管我怀疑 99.9% 的实现已经遵守它。 不过，Connect 可能值得建议。

现在，至于是否使用“基于功能”的 API（例如 Stream）和基于接口的 API 之间的讨论……我看到的根本问题是 .NET 不提供指定变量必须是对多个接口的实现的引用的能力。 例如，我不能写：

public static Foo ReadFoo(IReadable & ISeekable stream)
{
}

如果它确实允许这样做，这可能是合理的 - 但如果没有的话，你最终会遇到潜在接口的爆炸：

IReadable
IWritable
ISeekable
IReadWritable
IReadSeekable
IWriteSeekable
IReadWriteSeekable

我认为这比当前情况更混乱 -尽管我认为除了现有的 Stream 类之外，我还支持仅使用 IReadable 和 IWritable 的想法。 这将使客户更容易声明式地表达他们的需求。

通过代码契约，API可以声明它们提供什么和需要什么，诚然：

public Stream OpenForReading(string name)
{
    Contract.Ensures(Contract.Result<Stream>().CanRead);

    ...
}

public void ReadFrom(Stream stream)
{
    Contract.Requires(stream.CanRead);

    ...
}

我不知道静态检查器对此有多大帮助 - 或者它如何应对流关闭时变得不可读/不可写的事实。

Answer 2

如果不了解对象的内部结构，您必须假设在多个线程中修改对象时，“标志”属性太不稳定而无法依赖。

我发现这个问题关于只读集合比流更常见，但我觉得这是相同设计模式的另一个例子，并且适用相同的论点。

澄清一下，.NET 中的 ICollection 接口具有 IsReadOnly 属性，该属性旨在用作集合是否支持修改其内容的方法的指示符。 就像流一样，该属性可以随时更改，并会导致抛出 InvalidOperationException 或 NotSupportedException。

围绕这个问题的讨论通常可以归结为：

• 为什么没有 IReadOnlyCollection 接口？
• NotSupportedException 是否是一个好主意。
• 拥有“模式”与独特的具体功能的优缺点。

模式很少是一件好事，因为你被迫处理不止一组“行为”； 拥有可以随时切换模式的东西要糟糕得多，因为您的应用程序现在也必须处理多个“一组”行为。 然而，仅仅因为可以将某些东西分解为更谨慎的功能并不一定意味着您总是应该这样做，特别是当将其分解并不能降低手头任务的复杂性时。

我个人的观点是，你必须选择最接近你认为同级消费者能够理解的心理模型的模式。 如果您是唯一的消费者，请选择您最喜欢的型号。 就 Stream 和 ICollection 而言，我认为对它们有一个单一的定义更接近于类似系统中多年开发所建立的心智模型。 当您谈论流时，您谈论的是文件流和内存流，而不是它们是否可读或可写。 同样，当您谈论集合时，您很少用“可写性”来提及它们。

我对此的经验法则是：始终寻找一种方法将行为分解为更具体的界面，而不是拥有操作“模式”，只要它符合简单的心理模型即可。 如果很难将单独的行为视为单独的事物，请使用基于模式的模式并非常清楚地记录它。

Answer 3

Stream.CanRead 只是检查底层流是否有读取的可能性。 它没有说明是否可以进行实际读取（例如磁盘错误）。

如果您使用任何 *Reader 类，则无需捕获 NotImplementedException，因为它们都支持读取。 只有 *Writer 才会有 CanRead=False 并抛出该异常。 如果您知道流支持读取（例如您使用了 StreamReader），恕我直言，无需进行额外的检查。

您仍然需要捕获异常，因为读取期间的任何错误都会抛出异常（例如磁盘错误）。

另请注意，任何未记录为线程安全的代码都不是线程安全的。 通常静态成员是线程安全的，但实例成员不是——但是，需要检查每个类的文档。

Answer 4

从你的问题和所有随后的评论来看，我猜测你的问题在于所述合同的清晰度和“正确性”。 所述合同是 MSDN 在线文档中的内容。

您指出的是，文档中缺少一些内容，迫使人们对合同做出假设。 更具体地说，由于没有提及流的可读性属性的易变性，因此可以做出的唯一假设是 NotSupportedException 可能可能抛出，无论相应的 CanRead 属性的值是几毫秒（或更长时间）之前的。

我认为在这种情况下，我们需要继续了解该接口的意图，即：

1. 如果您使用多个线程，则一切都将失败；
2. 除非您在接口上调用可能会更改流状态的内容，否则您可以安全地假设 CanRead 的值是不变的。

尽管如此，Read* 方法可能可能会抛出NotSupportedException。

相同的参数可以应用于所有其他 Can* 属性。

Answer 5

我也非常感谢对此模式（CanXXX、XXX() 对）有效性的评论。

当我看到此模式的实例时，我通常会期望这样：

1. A 无参数 CanXXX 成员将始终返回相同的值，除非......

2. ...存在 CanXXXChanged 事件，其中无参数 CanXXX 可能会在该事件发生之前和之后返回不同的值； 但不触发事件就不会改变。

3. 参数化CanXXX(…)成员可能会为不同的参数返回不同的值； 但对于相同的参数，它很可能返回相同的值。 也就是说，CanXXX(constValue) 可能保持不变。

   <块引用>

   _{我在这里很谨慎：如果 stream.CanWriteToDisk(largeConstObject) 现在返回 true，是否可以合理地假设它将始终返回 true 将来会怎样？ 可能不会，所以参数化 CanXXX(…) 是否会为相同的参数返回相同的值可能取决于上下文。}

4. 调用 < code>XXX(…) 仅当 CanXXX 返回 true 时才能成功。

---

话虽如此，我同意 Stream 使用此模式存在一些问题。 至少在理论上是这样，但在实践中也许不是如此。

Answer 6

这听起来更像是一个理论问题，而不是一个实际问题。 除了由于流被关闭之外，我实在想不出任何情况下流会变得不可读/不可写。其他。

很可能存在一些特殊情况，但我根本不希望它们经常出现。 我认为绝大多数代码不需要担心这一点。

但这是一个有趣的哲学问题。

编辑：解决 CanRead 等是否有用的问题，我相信它们仍然有用 - 主要用于参数验证。 例如，仅仅因为一个方法需要在某个时刻读取一个流，并不意味着它想在该方法的开头读取它，但理想情况下应该在该位置执行参数验证。 这实际上与检查参数是否为 null 并抛出 ArgumentNullException 没有什么不同，而不是在第一次取消引用它时等待抛出 NullReferenceException。

此外，CanSeek 略有不同：在某些情况下，您的代码可以很好地处理可查找和不可查找的流，但在可查找的情况下效率更高。

这确实依赖于“可搜索性”等保持一致 - 但正如我所说，这在现实生活中似乎是正确的。

---

好吧，让我们尝试换一种方式......

除非您在内存中读取/查找并且已经确保有足够的数据，或者您在预先分配的缓冲区中写入，否则总是事情有可能会出错。 磁盘故障或填满、网络崩溃等。这些事情确实在现实生活中发生，因此您始终需要以能够在故障中幸存下来的方式进行编码（或者在问题没有发生时有意识地选择忽略问题）这真的很重要）。

如果您的代码能够在磁盘发生故障的情况下执行正确的操作，那么它很可能能够在 FileStream 从可写变为不可写时幸存下来。

如果 Stream 确实有固定合约，那么它们必须极其脆弱 - 您无法使用静态检查来证明您的代码始终有效。 你能做的最好的事情就是在面对失败时证明它做了正确的事情。

我不相信 Stream 会很快发生变化。 虽然我当然承认它可以被更好地记录下来，但我不接受它“完全被破坏”的想法。 如果我们不能在现实生活中实际使用它，它就会更加坏掉……如果它比现在更坏，那么从逻辑上讲，它还没有完全坏掉。

我对该框架有更大的问题，例如日期/时间 API 的状态相对较差。 在过去的几个版本中，它们已经变得很多，但是它们仍然缺少（例如）乔达时间。 缺乏内置的不可变集合、对语言中不可变性的支持不佳等——这些都是真正让我头疼的问题。 我宁愿看到它们得到解决，也不愿在 Stream 上花费大量时间，在我看来，这是一个有点棘手的理论问题，在现实生活中几乎不会引起任何问题。