代码之家  ›  专栏  ›  技术社区  ›  pestaa

在选择可链接性和语言结构时,我应该考虑什么?

  •  1
  • pestaa  · 技术社区  · 15 年前

    我很难做出这个设计决定。

    我可以选择传统的 new 语言构造来初始化对象,并通过变量使用它们,例如:

    $o = new Object('arg');
    $o->method();
    $o->property = 'value';
    $o->save();
    

    或者我可以选择工厂模式和侵略性链能力,比如

    Object::new('arg')->method()->setProperty('value')->save();
    

    会导致

    • 更少的LOC
      • 读,
      • 维护,
      • 重构器,
    • 不需要命名变量。

    然而,我不确定这是否是一个可以接受的方法,如果我忘记考虑一些事情。

    请表达您的担忧或同意,并指导我如何做出决定。

    4 回复  |  直到 15 年前
        1
  •  1
  •   Grumdrig    15 年前

    Fluent接口的好处在于,代码的精华不会在额外的语法管道中丢失,从而更容易阅读。然而,这是一个比逐行程序方法更不熟悉的习惯用法,也不是一般用法;例如,并非所有的代码结构都适合这种风格。

    if (something) $o->method();
    

    翻译不干净。因此,如果这类事情是典型的,那么它可能并不适合。

    还要考虑将围绕它的其他代码的上下文。如果代码主要是这些类似样板文件的片段

    $o = new Object('arg');
    $o->method();
    $o->property = 'value';
    $o->save();
    

    那么让它们更简洁肯定是一种进步。但是,如果这种代码在其他许多不同样式的代码中丢失,也许不会。

    如果这似乎是一个好主意,我会说去做吧。如果效果不好,那么切换回来的小努力就值得学习。

        2
  •  3
  •   Ryan Michela    15 年前

    我对最近流畅的界面时尚有着复杂的感觉。

    对于我来说,当整个方法链从头到尾表达一个单一的概念时,流畅的接口是有意义的。例如:

    var SuperLate = (new Coffee()).AddMocha().AddCream().Invert().Blend();
    

    每一步都需要链的上下文来解释,链中方法的执行顺序也很重要。如果在invert()之前调用Blend(),则会导致混乱。

    在您的示例中,接口方法之间几乎没有时间耦合。设置属性和执行方法不应依赖于顺序。我相信为常规方法调用和属性操作引入一个流畅的接口只会增加接口的复杂性,同时给出时间耦合的感觉。

    此外,添加一个Fluent接口会增加每个方法之间的耦合,因为它们现在依赖于彼此的返回值。当每个方法只表示一个整体概念的一部分时(就像制作咖啡的一个步骤),这种耦合是有意义的,但是当每个方法独立时,这种耦合会阻碍将来的重构。

    虽然它可能更详细,但我不建议为常规方法调用和属性设置引入一个流畅的接口。

        3
  •  1
  •   David Seiler    15 年前

    我非常喜欢你的“链式”设计。这种设计有时被称为 Fluent Interface .

        4
  •  0
  •   ennuikiller    15 年前

    为什么不让多个构造函数接受初始化值呢?所以你应该:

    Object::new()
    Object::new('arg1')
    Object::new('arg1','arg2')
    

    等。