0. Слишком много внимания уделял карьере.

В ООП тоже всё легко тестировать если пользуешься DI и пользуешься фаулеровскими заветами вроде разделяй запрос и модификатор.
Вы в статье очень удачно использовали объекты, тем самым продемонстрировав, что ООП не отменяет функциональных подходов, а очень удачно дополняется ими.

А что вы хотите от страны где 80% не имеют загранпаспорта и дальше крыма не выезжали, а дома пилят проекты на битриксе. Но это вымирающее меньшинство. В Беларуси или Украине таких проблем нет, практически везде чтение документации на английском и ооп — обязательные условия, т.к. проекты западные.

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

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

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

Здесь та же проблема как у любителей вима — сразу пишется кривой код на основании копипаста, а затем героически с этим борются, но копипаст остаётся.

Всё печальнее, я писал даже под IE 5.5, а ajax реализовывали через тег img и не боялись xslt в браузере.
Вот только не надо на основании этого записывать меня в олдфаги, которые боятся «новых» технологий. Сейчас я пишу на react, до этого был проект на vue, до этого на angular 1 и т.д. Есть с чем сравнивать.

p.s. Я спутал теневой дом с виртуальным, но в любом случае, он ещё не стандарт, а лишь черновик.

У меня более десяти лет опыта писания на javascript, по моим ощущениям связка react + flux это худшее с чем мне приходилось работать. Не понимаю откуда такой хайп. Единственный плюс это теневой дом, который в теории должен обеспечить лучшую производительность, но на практике постоянно встречаю подлагивание реакт приложений начиная с самого facebook.

Мне всё это напоминает smarty в мире php, когда брали шаблонизатор и строили архитектуру вокруг него. Реакт это такой же тупой шаблонизатор, хватит на него молиться, в нормальной архитектуре это звено, которое вообще должно быть легко заменяемым.

Это вы смешали.
1. Нет, это декоратор, он сломал принцип лискоу, так как не сломал интерфейсы и не пройдёт тайпхинтинг.
2. Это паблик морозов, т.к. у вас model — протектид, а __call предоставляет к нему доступ как к публичному.
3. В статье недоразумение, а не паттерн, он нарушает сразу несколько солид принципов, о чём и был смысл данного обсуждения.
4. Обязательно уберите и код из контроллера тоже.

Нет, вам следует убрать магический __call и тогда это будет презентер или viewmodel, а так это паблик морозов, который позволяет делать $object->delete() в слое представления.

Да, декораторы могут наследовать несколько интерфейсов, но не плодить свои. Это всё же динамический паттерн.

Вот, _расширять_. Потому что наличие интерфейса согласуется с принципом лискоу. При этом слово расширять — лучше понимать как наследовать несколько интерфейсов, соблюдая принцип разделения интерфейсов.
Я сам об это споткнулся пару лет назад, пришлось ставить костыли из-за наличия __call и обратной совместимости вместо нормально интерфейса.

Они оба предполагают соблюдение интерфейса, но цель разная. Прокси контролирует объект, а Декоратор предоставляет возможность _динамического_ изменения поведения.

Нет, вы были скорее правы.
Декоратор предполагает обёртывание объекта с сохранением интерфейса и предпологает обёртывание существующих методов, здесь интерфейса вообще нет, плюс добавляются новые методы. А здесь действительно прокси, так как проктирует обращение на модель, тем более магический __call выполняет функцию паблика морозова, нарушая инкапсуляцию, что недопустимо даже для презентера.

Очень странная реализация подхода с кучей кода в контроллере.
Давайте теперь добавим отчество, вы будете каждый контроллер править добавляя 'middle_name' => $user->middle_name?

Вот видите, почему важно давать точную информацию, а не рассчитывать на понимание новичками контекста.

Где вы увидели оскорбления?

Про вашу ситуацию я сказал выше https://habrahabr.ru/post/309568/?reply_to=9798148#comment_9797974 Даже под линуксом нужно разрабатывать в той же среде, что будет на проде.

Так ежик, вы даже с гитом в команде не работали, какой к чёрту опыт. Первая же проблема которая вылезет при переносе после вашей статьи — это права на файлы. И человек бежит на форумы спрашивать, ведь он же статью прочитал, зачем ему доки, если если человек с опытом так написал.

Здесь же дело не в удобстве, а в разном функционале при работе под windows и linux, из-за которого ваш проект может вовсе НЕ РАБОТАТЬ под другой операционной системой.

винда на декстопе, линукс на сервере. не вижу противоречий.