ООП-билдер «массивных» параметров

>Мы же не используем голый SQL, где его вполне легко можно заменить AR`ами или теми же query builder`ами?

Используем. Не используем, как-раз, AR/Builder/ORM. В остальном, с постом согласен: в случае с конфигами билдер будет удобен (при использовании кеширования, конечно-же).

Ужас какой. Это вы называете человеко-читаемым?

Посмотрите в сторону YAML, пожалуйста.

У него есть ещё один громадный плюс, — одним и тем же конфигом можно пользоваться из приложений на PHP, Python, Perl, Ruby, Node.JS etc.

Не понимаю, за что минусуют, но я категорически плюсую. Делать вместо многомерныйх не структурированных массивов чёткие структурированные объекты — это признак хорошего тона, особенно, если в твоём коде будут разбираться другие программисты вооруженные топорами и бензопилами. Yaml и XML не спасут, если ты не помнишь названия переменных/атрибутов наизусть и иногда опечатываешся.

Это то же самое, что создавать константы для ключевых слов:

<?

class Image {

   const RESIZE_METHOD_RESIZE                    = 'resize';
   const RESIZE_METHOD_CROP                      = 'crop';
   const RESIZE_METHOD_CROP_TOP                  = 'cropTop';
   const RESIZE_METHOD_CROP_WITHOUT_CROPPING     = 'cropWithoutCropping';
   const RESIZE_METHOD_SOMTHING                  = 'somthing';
   const RESIZE_METHOD_ETC                       = 'etc';
   // Эти константы не нужны для какой-то логики,
   // но они нужны для автокомплита и что бы не опечататься.

}
?>

Откуда они подлецы вообще появляются?

Зачастую они появляются из-за отсутствия в PHP именованных параметров и, отчасти, параметрического полиморфизма. Ну и не любят многие ООП, предпочитая $user['profile']['name'] вместо $user->profile->name.

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

От «уровневого» параметра (если я правильно понял) спасёт создание объектов с нужными полями. Если есть необязательные поля, то опять же конструктор с именнованными полями пригодился бы.

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

...
    ->conditions
        ->is('Model.field', 123) // отступили
        ->between('Model.field5', 5, 5)
        ->notLike('Model.field8', '%8%')
        ->up()
    ->recursive(1) // вернулись
...

А как Ваш IDE вот здесь делает ступеньки при автоматическом форматировании?

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

ЗЫ Не увидел этой ссылки www.phptherightway.com

То, что предложил автор — излишнее усложнение. Если на каждую не нравящаюсю нам особенность PHP писать по несколько классов для ее обхода, все будет работать с черепашьей скоростью и в 20-50 мс на запрос мы никогда не уложимся.

Паттерн Builder используется не для того, чтобы заменить массивы с конфигом (да, в динамических ЯП можно использовать массивы там, где в строгих ЯП надо делать классы и структуры ради одноразового использования), а для того, чтобы заменить конструктор или метод с 20 параметрами. Как вариант — построение запроса на выборку чего-нибудь из хранилища, например.

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

Лучшее решение для того, чтобы заменить массив чем-то строго типизированным — использование класса с публичными методами. Как бонус, получаем еще и дефолтные значения. Вот код:

class SomeServiceConfig
{
public function __set($k,$v) { throw new \Exception; }
public function __get($k) { throw new \Exception; }

/** комментарий */
public $maxConnectionNumbers = 100;
public $useSomeProtocol = false;
public $warnOnUsingSomeCommand = true;
}

(__set и __get нужны для обхода неудачной идеи в дизайне PHP, позволяющего создавать свойства динамически при опечатке в имени свойства). Пример кода, инициализирующего такой конфиг:

$cfg = SomeService::getDefaultConfig();
$cfg->useSomeProtocol = true;
$service = SomeService::create($cfg);