问题标签 [fluent-interface]

与经典属性相比，使用它的最大收获是什么？

我知道实例名称的重复消失了，但仅此而已吗？

主要问题在标题中，但这是背景。

因为我选择了懒惰的方式来注册我的组件

现在当我尝试

Windsor 告诉我已经有一个具有相同键的组件

但是，如果我注释掉那行 Windsors 无法解析 CompositionBinder Now 如果我这样做

然后它工作。因此，我想深入了解引擎，以了解注册到我的容器的组件和密钥类型。

如何获取当前在 Castle Windsor 中注册的组件的所有密钥？

我最近遇到了这个表达 - 但在维基百科上阅读并没有对我来说很清楚 - 我仍然不明白：

1. 它有什么意义
2. 它在实践中是如何使用的（即它如何使编码人员在他们的日常工作/构建系统中受益）？

[编辑] Wikipedia 文章 C++ 示例过长，将流畅界面的讨论与简单的 Glut 应用程序示例混为一谈。有人可以提供一个说明流畅接口的类的 SUCCINCT C++ 示例（例如，这种影响与普通 C++ 接口有何不同）？

我试图弄清楚是否可能，我失败了，但也许有可能（我认为应该有可能）。

假设我们有一些类似于 Swing 层次结构的 UI 组件 + 我们将使用流畅的接口Fluent Interfaces：

是否有可能使用泛型来编写类似的东西？

setName 应该返回 TitledPanel 而不是 Component 以便能够链接这些调用。

这只是一个简单的例子，但想法是一旦我有一个类型为 T 的对象，任何对超类的任何流利方法的调用都返回类型 T。

编辑1：我忘了排除覆盖方法并返回协变类型的部分:)如果确实可能的话，我只想要普通的泛型。

我有一个接口继承问题一直困扰着我一段时间。这似乎没有任何意义，我只能得出结论，我错过了一些基本的东西。

概述

下面的代码来自我们 ORM 工具的流利界面的一部分。它提供了一种类似 SQL 的语法，用于从数据库中提取数据。你不必完全理解所有的相互关系来理解问题——真正的问题是 EndClause 方法。

EndClause 问题

有一种名为 EndClause 的方法没有出现在预期的位置——IOrderQueryRoot。据我所知，它应该显示出来，因为它继承自两个不同的接口，这两个接口都有一个名为 EndClause 的方法，但是当我使用一个实现 IOrderQueryRoot 的对象时，EndClause 不会在智能感知中弹出。

下面还有一些更多的实现细节。

首先，如果您查看 IOrderQueryRoot（其中包含 EndClause），您可以看到它继承了 IHasOrderLogicalOperators 和 IHasOrderFields（也包含 EndClause）。

我认为问题一定与 EndClause 方法从继承链中的不同位置两次进入 IOrderQueryRoot 的事实有关。它确实需要以这种方式工作。

由于您可能想查看我实际使用接口的位置，因此这是我正在使用的代码：

在这一点上，接口工作正常——如果我要删除这个方法，VS 会尖叫我必须实现这两个 EndClause 方法。当“最终开发人员”试图针对接口实际编写代码时，问题就在下一级。

请让我知道如果有什么东西在你身上跳出来 - 这个已经让我发疯了很长时间！

我将举例说明一个问题。有一个具有流畅接口的基类：

和一个子类：

问题是当你调用时customer.WithAccountNumber("000").WithFirstName("John").WithLastName("Smith")你不能.WithId(123)最后添加，因为WithLastName()方法的返回类型是 FluentPerson（不是 FluentCustomer）。

这个问题一般是怎么解决的？

除了 web.config ，有没有人尝试过类似于Fluent-Nhibernate项目的东西？这甚至合理吗？

我希望能够做这样的事情：

如果我确定每次都按该顺序调用所有方法，那么它会很简单，我可以在每次方法调用时返回对象本身的实例，以便构建查询并最终在 orderBy 方法处执行。但是我希望该类也能够执行如下查询：

以下代码适用于第一个代码示例（即调用所有方法时），但不适用于第二个代码示例，其中只有在 getRows 之后调用的方法。它只返回一个自身的实例。

忽略所有小错误 - （我没有检查它是否确实有效，但它应该。）我怎样才能做到这一点？

我正在编写一个帮助类来包装JQuery Taconite插件的功能。该插件使您能够在单个 Ajax 调用中处理多个 DOM 更新。

该类仅使您能够构建发送回客户端的适当 xml 结构。我正在尝试将此功能包装在一个流畅的界面中。基本示例如下所示：

我担心的是，在调用这个之后你会期望创建什么结构：

您的期望是：

或者：

问题是 - 您是否希望上下文转移到新添加的内容或保留在选择器中？

更新 有问题的项目已上传到code.google。希望你觉得它有用。

感谢您的输入！

当针对流畅的 API 进行编程或仅使用方法链时，我看到的风格大多是这样的：

将点放在行首而不是行尾的原因是什么：

或者，它仅仅是一个团队达成共识的风格吗？