Что я должен учитывать при выборе цепочки и языковых конструкций?

Question

Мне трудно принять это дизайнерское решение.

Я мог бы пойти с традиционной new языковой конструкцией для инициализации объектов и использовать их через переменные, такие как:

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

Или я могу выбрать заводскую модель и агрессивную цепочку, как

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

, что приведет к

• меньше LOC до
  • читать
  • поддерживать
  • рефакторинг
• не нужно называть переменные.

Однако я не уверен, является ли это приемлемым подходом, и забыл ли я что-то учитывать.

Пожалуйста, выскажите свое беспокойство или согласие, а также укажите, как я могу принять свое решение.

Answer 1

У меня смешанные чувства по поводу недавнего увлечения Fluent Interface.

Для меня беглые интерфейсы имеют смысл, когда вся цепочка методов выражает единую концепцию от начала до конца. Например:

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

Каждый шаг нуждается в контексте цепочки, чтобы иметь смысл, и порядок, в котором выполняются методы в цепочке, имеет значение. Если Blend () вызываться до Invert (), наступит хаос.

В вашем примере, существует небольшая временная связь между методами вашего интерфейса. Установка свойств и выполнение методов не должны зависеть от порядка. Я полагаю, что введение свободного интерфейса для рутинного вызова методов и манипулирования свойствами только увеличивает сложность интерфейса, в то же время давая ощущение временной связи.

Кроме того, добавление свободного интерфейса увеличивает связь между каждым методом, поскольку теперь они зависят от возвращаемого значения друг друга. Такое сочетание имеет смысл, когда каждый метод выражает только часть общей концепции (например, этап приготовления кофе), но может препятствовать рефакторингу в будущем, когда каждый метод стоит отдельно.

Хотя это может быть более многословно, я не рекомендовал бы вводить свободный интерфейс для обычного вызова метода и установки свойств.

Answer 2

Что хорошо в беглом интерфейсе, так это то, что смысл кода не теряется среди дополнительных синтаксических элементов, что облегчает его чтение. Однако это менее знакомая идиома, чем построчный процедурный подход, и не такой общий; не все структуры кода подойдут для этого стиля, например

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

не будет переводиться так чисто. Так что, если такие вещи типичны, они могут не подходить.

Также рассмотрите контекст другого кода, который его окружит. Если код будет в основном подобным типом сегментов, таких как

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

тогда сделать их более лаконичными, несомненно, было бы улучшением. Но если такой код будет потерян среди множества других программ в другом стиле, возможно, нет.

Если кажется, что это, вероятно, хорошая идея, я бы сказал, пойти на это. Если это не удастся, небольшие усилия по переключению назад будут стоить обучения.

Answer 3

Я большой поклонник твоего «цепного» дизайна. Такую конструкцию иногда называют Fluent Interface .

Answer 4

почему бы не иметь несколько конструкторов, которые принимают значения для инициализации. Таким образом, вы должны иметь:

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

и т.д.