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

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

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

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

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

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

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

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

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

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

9.11.2009 17:05:58
Для справки, хотя я предполагаю, что вы ищете независимые от языка ответы, в некоторых языках есть стили, которые предлагают ту или иную альтернативу. Я предполагаю, что это либо Perl, либо PHP?
Chris Lutz 9.11.2009 17:16:33
Да, я надеюсь, что будут ответы, специфичные для PHP, но советы, не зависящие от языка, также будут очень полезны.
pestaa 9.11.2009 17:30:30
4 ОТВЕТА
РЕШЕНИЕ

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

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

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

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

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

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

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

1
9.11.2009 21:10:50

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

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

и т.п.

0
9.11.2009 17:12:08

Я большой поклонник твоего «цепного» дизайна. Этот вид дизайна иногда называют свободным интерфейсом .

1
9.11.2009 17:13:47
Рада что тебе понравилось. Хотя, кроме фанатизма, можно ли что-нибудь упомянуть, пожалуйста?
pestaa 9.11.2009 17:29:09
Я думал, что вы суммировали его преимущества довольно хорошо: легче читать / поддерживать / рефакторинг из-за отсутствия явного локального состояния и общей краткости.
David Seiler 9.11.2009 18:23:18

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

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

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

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

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

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

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

3
9.11.2009 17:39:54
Возможно, я не выбрал лучшие имена подпрограмм для этого примера, но я бы предпочел объекты конфигурации, например, нескольким вызовам установщика. Как видите, пример также приводит объект от инициализации к сохранению. Является ли порядок-независимость, который только беспокоит вас?
pestaa 9.11.2009 18:01:01
Меня больше беспокоит масштаб конструкции. Большинство беглых интерфейсов, которые я видел, делают большие конструкции (отображение nHibernate) из маленьких компонентов. Маленькие компоненты на самом деле не стоят сами по себе. Конфигурирование и сохранение объекта - это не единственная конструкция. Это серия сдержанных шагов. Вот почему я не чувствую, что свободный интерфейс подходит. Это, однако, только мое мнение.
Ryan Michela 9.11.2009 18:51:50
Жаль, что новые "ОО" языки не поддерживают взаимодействия, которые делал оригинал (Smalltalk). В Smalltalk было просто отправить несколько сообщений одному объекту, разделяя их точкой с запятой. (Прямоугольник новый) цвет: красный; addToCanvas: mainCanvas.
Joe Koberg 9.11.2009 20:32:17
Я согласен с тем, что большие конструкции затрудняют поддержку кода в некоторых крайних случаях, но я в основном планирую реализовать гибкий интерфейс в ORM и другом базовом наборе объектов, так что это может ускорить разработку. Спасибо за ваше противоположное мнение, хотя! +1
pestaa 10.11.2009 17:54:01