twin, я писал тебе ответ, но что-то не то нажал и все пропало. Писать заново не буду, короче делайте фичу, которая будет черновик сообщения в localStorage писать.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

twin, это уже не первый раз, на phpclub например черновики есть и это крайне удобно.


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

class Factory
{
    public function create()
    {
        return new SomeClass;
    }
}

class builder
{
    public function create()
    {
        $obj = new Class1;
        $result = $obj->getResult();
        return new Class2($result);
    }
} 

@twin я понял, что ты имеешь в виду. Проблема в том, что крупные проэкты имеют не только протекающие в контроллере операции, но имеются Джобс или к примеру возможности вызывать ту или иную имплементации интерфейса, в зависимости от среды или конфигурации + тесты.. Чисто из этих соображений, если в системе нет депенденси инекцион контейнера я не только делаю фабрики, но и фабрики которые позволяют заменять имплементации производимого фабрикой класса. Типа мутанта между фабрикой и фасадом. По сути мы об одном и тоже говорим, так как в том, что ты называешь билдером, а я фабрикой, общая цель по созданию объекта какого то типа в определённой среде и скрыть грязь производства этого объекта.

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

SlavaFr

И снова к кодам. Возьмем пример из вики, от которой ты фанатеешь, если уж перешли на жаргон. Весь пример не потащу, только вызов:

$appearance = "osx";

$factory = NULL;

switch ($appearance) {
    case "win":
        $factory = new WinFactory();
        break;
    case "osx":
        $factory = new OSXFactory();
        break;
    default:
        break;
}

$button = $factory->createButton();
$button->paint();

И скажи мне теперь, чем это лучше, чем так:

$appearance = "osx";

$factory = NULL;

switch ($appearance) {
    case "win":
        $button = new WinButton();
        break;
    case "osx":
        $button = new OSXButton();
        break;
    default:
        break;
}

$button->paint();

Сейчас ты скажешь про полиморфизм. Абстрактная фабрика позволяет систематизировать объекты по семействам. Выбрал фабрику и клепай круглые кнопки. Выбрал другую - получи квадратные. Да, полиморфизм - дело полезное. Но не в этом случае. Полиморфизм в виде фабрики полезен только в десктопных языках. Когда тебе сейчас нужна круглая кнопка, через пять минут переключил скин - квадратная. Потому и говорю, что фабрика призвана "фабриковать" много однотипных объектов.

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

При запуске веб-приложения нам заранее известно, что для него потребуется в процессе исполнения. Все внешние данные подаются на входе, запросами или конфигурацией. Если есть запрос на квадратные кнопки, они и будут квадратными до конца. И этим вопросом куда как лучше справляется DIC. Контейнер, это и фабрика, и билдер, и прототип, и реестр, и локатор в одном флаконе. Сейчас 2017 год, напомню. Не 1994, в котором GoF написали. Награмождать на контейнер еще и внешнюю абстрактную фабрику... поясни смысл. Не догоняю.

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

Фабричный метод, если он параметризирован, еще куда ни шло, это может быть полезным при инициализации объекта по имени класса, полученного из СУБД. И то, с популяризацией всяческих AR и ОRM в этом пропадает необходимость.

Кстати, отдельное наблюдение. Большинство описаний паттернов в GoF не скупится на классы и интерфейсы, а каждый должен быть в отдельном файле. И это понятно почему. Эти все примеры для компелируемых языков. Там не особо важно, сколько чего ты наворотил, в итоге все равно получится один ексешник (я не беру во вимание либы, конфигурацию и пр, только приложение). А вот в интерпретируемых языках это плохо. Это сказывается на производительности. Конечно, сейчас опять начнеся "железо дешевле программиста" и прочая. Не понятно, зачем это делать специально, используя совершенно неприемлимые примеры, как делает Ron.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.