“返回$ this;”设计模式还是反模式？

如何解决“返回$ this;”设计模式还是反模式？

| 我已经看过很多次使用

return $this;

模式样式的Zend Framework  -从我的角度来看： 优点：对于在同一对象上链接许多动作并缩短代码长度来说，它的样式风格似乎还不错。 缺点：当您看到该对象在方法中返回自身时，代码看起来有点怪异，这会做其他事情（例如，某些属性的设置器） 它是真的很好的模式实践还是一种反模式实践？ 编辑：好吧，从我这边叫它“模式”有点太多了，谢谢大家为我指出正确的方向！     

解决方法

返回“ 1”可让您链接呼叫并设置值。这对于配置某些对象非常有用（请参阅Fluent界面）。您可以非常轻松地表达所需的内容（也可以使用不同的返回类型来实现所需的内容）。     ,我发现方法链接在有意义的情况下很有用。特定领域的语言，例如：

$query->select(\'*\')->from(\'users\')->where(array(\'user_id\' => 1,\'verified\' => 1));

事实是，这些方法无论如何都只会返回

void

，因此

return $this

只是作为写作的简写形式：

$query->select(\'*\'); $query->from(\'users\'); $query->where(...);

我们仍将调用

toSQL()

或

execute()

方法来利用填充对象的数据。 我认为这不是反模式，可以在适当的情况下充当合法，明智的对象填充方法。     ,如果您的意思是“良好做法或不良做法”，这是我的看法： 从好的方面来说，您会得到一些语法糖。 不利的一面是，您放弃了有意义的返回值以支持可链接性。这实际上是不可行的，因为最终您将不得不拥有返回除基础对象以外的其他东西的方法，因此您最终得到了一些可链接的方法，而某些不是可链接的（您的类的用户会很有趣地猜测哪些是可链接的）哪一个。） 或者您全力以赴，无论如何都使它们可链接，但是随后您发现自己处于荒谬的境地，例如为了保留链而返回伪造的“空”对象，该对象需要进行一些测试。遮盖属性，以确定它是链中的“真实”链接还是链接。 经典示例是jQuery，它表现出所有症状：基础对象试图成为整个代码中唯一的数据基本单位（所有内容都返回一个jQuery对象）。假物体测试（

if (obj.length)

）；加上自矛盾，对于返回字符串的方法（如ѭ9），仍然需要打破可链接性。 恕我直言，仅仅为了一点点语法糖就把事情弄得一团糟。     ,并非只有PHP / Zend Framework会这样做，因为还有许多其他编程语言都使用了流畅的界面。我当然认为这很方便，并且使用流畅的界面是一种很好的编码方式。尽管有时代码看起来很怪异，但这并不意味着它是错误的，并且我不认为您可以将其置于骗子之下。 最后，程序员只能看到他返回了相同的对象，而不是它在流畅的接口类的代码中的外观。我认为流畅接口的最大优点是代码的可读性。如果您想听到一个缺点，那么调试一条流畅的链条就是一个。 流利的界面     ,这称为Fluent接口，我不认为这是一种模式，而是一种更好的实现函数的方式，以减少代码量并提高可读性。 我让您阅读Wikipedia页面：http://en.wikipedia.org/wiki/Fluent_interface