在可链接性和语言结构之间进行选择时我应该考虑什么？
我很难做出这个设计决定。
我可以使用传统的 new 语言构造来初始化对象，并通过变量使用它们，例如：
$o = new Object('arg');
$o->method();
$o->property = 'value';
$o->save();
或者我可以选择工厂模式和激进的可链接性，这样
Object::new('arg')->method()->setProperty('value')->save();
会导致
- 更少的 LOC
- 阅读，
- 维护，
- 重构，
- 无需命名变量。
然而，我不确定这是否是一种可以接受的方法，以及我是否忘记考虑一些事情。
请表达您的担忧或同意，并指导我如何做出决定。
I have tough time making this design decision.
I could go with traditional new language construct to initialize objects, and use them through variables, such as:
$o = new Object('arg');
$o->method();
$o->property = 'value';
$o->save();
Or I can choose factory pattern and aggressive chainability like as
Object::new('arg')->method()->setProperty('value')->save();
which would result in
- less LOC to
- read,
- maintain,
- refactor,
- no need to name variables.
However, I'm not sure if this is an acceptable approach, and if I forgot to take something into account.
Please express your worries or agreement, and guidance as how I could make my decision.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我对最近流行的 Fluent Interface 的感觉很复杂。
对我来说，当整个方法链从开始到结束表达一个概念时，流畅的界面就有意义了。例如：
每个步骤都需要链的上下文才有意义，并且链中方法的执行顺序很重要。如果在 Invert() 之前调用 Blend()，则会发生混乱。
在您的示例中，接口的方法之间几乎没有时间耦合。设置属性和执行方法不应依赖于顺序。我相信，为常规方法调用和属性操作引入流畅的接口只会增加接口的复杂性，同时给人一种时间耦合的感觉。
此外，添加流畅的接口会增加每个方法之间的耦合，因为它们现在依赖于彼此的返回值。当每个方法仅表达整体概念的一部分（例如煮咖啡的步骤）时，这种耦合是有意义的，但当每个方法单独存在时，可能会阻碍未来的重构。
虽然它可能更冗长，但我不建议为常规方法调用和属性设置引入流畅的接口。
I have mixed feelings on the recent Fluent Interface fad.
For me, fluent interfaces make sense when the overall method chain expresses a single concept from start to finish. For example:
Each step needs the context of the chain to make sense and the order in which the methods in the chain are executed matters. If Blend() were called before Invert(), chaos would ensue.
In your example, there is little temporal coupling between the methods of your interface. Setting properties and executing methods should not be order dependent. I believe that introducing a fluent interface for routine method invocation and property manipulation only increases the complexity of the interface while giving the perception of temporal coupling.
In addition, adding a fluent interface increases the coupling between each method because they are now dependent on each other's return value. This coupling makes sense when each method expresses only part of an overall concept (like a step in making coffee), but can hinder future refactoring when each method stands alone.
While it may be more verbose, I would not recommend introducing a fluent interface for routine method invocation and property setting.
流畅界面的好处在于，代码的核心内容不会在额外的语法管道中丢失，从而更易于阅读。然而，与逐行程序方法相比，它是一个不太熟悉的习惯用法，而且也不那么通用；并非所有代码结构都适合这种风格，例如
不会翻译得那么干净。因此，如果此类事情很典型，那么它可能不太合适。
还要考虑围绕它的其他代码的上下文。如果代码主要是类似样板的片段，
那么使它们更加简洁肯定会是一种改进。但如果这样的代码会在不同风格的许多其他代码中丢失，也许不会。
如果这看起来可能是个好主意，我会说那就去做吧。如果效果不佳，切换回来的小努力将是值得学习的经历。
What's nice about the fluent interface is that the meat of the code isn't lost among extra syntactical plumbing making it easier to read. However it is a less familiar idiom than the line-by-line procedural approach, and not as general; not all code structures will be a good fit for this style, for example
won't translate as cleanly. So if such things are typical, it may not be a good fit.
Also consider the context of the other code that will surround it. If the code is going to mostly be these sort of boilerplate looking segments like
then making them more succinct would surely be an improvement. But if such code will be lost among much other code in a different style, maybe not.
If it seem like it's probably a good idea, I'd say go for it. If it doesn't play out well, the small effort of switching back will be worth the learning experience.
我非常喜欢你的“可链式”设计。这种设计有时称为流畅界面。
I am a big fan of your 'chainable' design. This sort of design is sometimes called a Fluent Interface.
为什么不使用多个构造函数来获取初始化值。所以你会有：
等等。
why not have multiple constructors that take values for initialization. So you would have:
etc.