.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，展示了这些属性的动态特性。因此，没有合同保证上述代码 sn-p 中对 Read() 的调用不会引发 NotSupportedException。

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

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

Answer 1

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

很遗憾，MSDN 没有提供任何关于 CanRead/CanWrite/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 的想法。这将使客户更容易以声明方式表达他们的需求。

使用Code Contracts，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 属性的值早于几毫秒（或更多）。

我认为在这种情况下需要继续这个界面的intent，即：

1. 如果您使用多个线程，所有赌注都将被取消；
2. 在您调用接口上可能会改变流状态的东西之前，您可以放心地假设CanRead 的值是不变的。

尽管有上述情况，Read* 方法可能可能会抛出 NotSupportedException。

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

Answer 5

我也很感谢 cmets 关于这种模式的有效性（CanXXX、XXX() 对）。

当我看到这种模式的一个实例时，我通常会这样认为：

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

2. …在存在 CanXXXChanged 事件的情况下，无参数的CanXXX 可能会在该事件发生前后返回不同的值；但它不会在不触发事件的情况下改变。

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

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

4. 只有在CanXXX 返回true 时，对XXX(…) 的调用才能成功。

---

话虽如此，我同意Stream 对这种模式的使用有些问题。至少在理论上，如果在实践中可能没有这么多的话。

Answer 6

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

可能会有一些极端情况，但我根本不希望它们经常出现。我认为绝大多数代码都不需要担心这一点。

不过，这是一个有趣的哲学问题。

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

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

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

---

好的，让我们换个方式试试...

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

如果您的代码在磁盘故障的情况下可以做正确的事情，那么它很有可能在FileStream 从可写变为不可写时幸存下来。

如果Stream 确实有固定合同，那么他们就必须难以置信地弱 - 您不能使用静态检查来证明您的代码将始终有效。你能做的最好的事情就是证明它在面对失败时做了正确的事。

我不相信Stream 会很快改变。虽然我当然接受可以更好地记录它，但我不接受它“完全损坏”的想法。如果我们不能在现实生活中实际使用它，它会更多损坏......如果它可能比现在更损坏，那么它在逻辑上还没有完全损坏.

我的框架存在更大的问题，例如日期/时间 API 的状态相对较差。在最近的几个版本中，它们已经很多变得更好了，但是它们仍然缺少很多（比如）Joda Time 的功能。缺乏内置的不可变集合，语言中对不可变性的支持不佳等 - 这些都是让我实际头疼的真正问题。我宁愿看到它们得到解决，也不愿花时间在Stream 上，在我看来，这似乎是一个有点棘手的理论问题，在现实生活中几乎没有引起任何问题。