4

如今，流畅的 API 非常普遍。最近，我几乎在我使用的每个系统中都能找到它们。大多数情况下，它们增强了可读性，但有时它们将我锁定在不灵活的规范中，使理解他们构建的规范的运行时行为几乎是不可能的。关于如何创建良好的流畅 API 是否存在共识？使用 fluent API 表示结构或规范的最佳方式是什么？

我最近在NServiceBus配置类中的 fluent API 上注意到了这个新颖的变体：

class EndpointConfig : IConfigureThisEndpoint, AsA_Server { }

它使用多个接口作为一种线性流畅的接口。我喜欢它，因为当我只尝试表示简单的需求时，它不会给我带来额外的代码和上下文的沉重负担。在简单的情况下就足够了。不过，我不认为它会扩展到复杂的规格。您如何看待接口的这种使用？

您在 C# 中使用了哪些其他新的习语？你在哪里使用它们？他们的优势是什么？你不会在哪里使用它们？另外，您如何衡量您正在考虑使用的成语的优势？

4

1 回答 1

1

我曾经在指示不同行为的方法上避开布尔参数，例如我会采取

int ExpensiveComputation(bool useDiskCache)

并且更愿意把它变成

int ExpensiveComputation(CacheType.DiskCache)

我最喜欢这个，因为当你打电话时ExpensiveComputation(true)，不清楚这true意味着什么，而不知道一切ExpensiveComputation，但ExpensiveComputation(CacheType.DiskCache)会给你一个好主意。

然而，对于命名参数，我发现使用第一个参数通常是可以接受的，并且这样称呼它：ExpensiveComputation(useDiskCache: true) 所以这是我最近为自己发明的一个习语。

于 2010-08-18T04:31:36.817 回答