dev400

Такие вещи делаются через CSS.

Начнем с того что там адаптивщина, и 4 в строке - условность.

А выводить по 4 очень просто. Остаток от деления если равен 0 то.

// закрывать див с элементами и открывать новый.
<?if(i % 4 == 0) { ?>
        </div> <div>
<?} ?>

1. вы получаете окружение близкое или идентичное к продакшену.
2. вы получаете внятную консоль/шел из коробки.
3. вы избавляетесь от массы вопросов типа "на локалке все работает, а залил на сервер и получил жопу" (или наоборот).
4. у вас появляется более лучшее понимание как на сервере все работает.

при теперешнем развитие технологий и производительности железа, нет необходимости себя ломать.
можно попробовать в виртуалке (docker/vagrant)/дуалбуте и самому для себя решить стоит или нет.

nnmclub.to/forum/viewtopic.php?t=1003282

Да. Книга "Банда четырех".

https://github.com/domnikl/DesignPatternsPHP

https://sourcemaking.com
https://github.com/PhpFriendsOfDdd/state-of-the-union

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

Третий вариант не для того, чтобы так вызывать объекты. Он в 95% случаев вообще не требуется разработчику, к тому же в этом случае лишний раз вызывается функция. Для разработки фреймворков \ CMS он более чем полезен, т.к. позволяет оперировать переменными с именами объектов, классов и т.п.

напишу своё понимание, хотя я далек от гуру применения патернов.

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

Также почитал бы другие ответы, мб я что-то не так понимаю

ControllerResolver вероятно

Хм... роутер? В целом за "загрузку классов" отвечает автозагрузчик (например тот который генерит composer). Вам же нужно просто отдельный объект, который находит кого вызывать.

p.s. посмотрите реализации популярных роутеров.

Нет.

Полиморфизм, как следует из названия, это когда что-то маскируется под что-то другое. Это свойство системы типов языка на котором вы пишите, он может позволять вам делать вещи, маскирующие свой внешний вид ("названия") но все же это не та же вещь. Ну и стоит заметить что у полиморфизма есть еще разные виды. Например:

Параметрический полиморфизм. Это когда мы можем написать один код, с одним набором имен, которые работает с разными типами аргументов. Пример - шаблоны из C++ или дженерики в Java. То есть "имена" методов одинаковые, потому что они в одном экземпляре. Реализация одна, одно поведение. А вот аргументы могут отличаться.

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

Полиморфизм подтипов. При этом у нас как раз таки будет одни и те же имена и может быть совершенно разное поведение. Например мы можем создать какой-то базовый тип, который, к примеру, отправляет email-ы, и создать его подтип, который вместо отправки email-ов записывает в лог то что мы хотели отправить, после чего уже отправляет данные дальше другому объекту этого типа (шаблон проектирования декоратор).

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

Ну и еще есть одно серьезное ограничение. Если мы хотим заменить в системе объект какого-то типа на объект подтипа (грубо говоря наследника), то система не должна сломаться. То есть "другое" поведение нашего подтипа должно быть совместимо в плане интерфейса с базовым типом. Об этом можно почитать загуглил "Принцип подстановки Барбары Лисков".

Ad-hoc полиморфизм - это пожалуй самый интересный вид полиморфизма с которым можно долго холиварить. По сути при этом виде полиморфизма, у нас одинаковые имена, а поведение зависит от входящих аргументов. Пример - перегрузка методов в C++. Интересен этот вид полиморфизма в основном тем, что он не является "настоящим".

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

Среди PHP-разработчиков немало тех, кто мечтает увидеть в этом языке с динамической системой типов честную перегрузку методов как например в Java или C++. Просто так, потому что if-ы это плохо и лучше уж пусть они будут неявные на уровне компилятора/рантайма.

Полиморфизм с приведением типов - еще один вид "не настоящего" полиморфизма. Мы "эмулируем" полиморфизм за счет того, что на уровне рантайма языка происходят касты действительного в желаемое. Например в PHP мы можем выставить у функции тайпхинтинг string, и можем внутри иметь одно и то же поведение для всех входящих аргументов. Передать же в качестве аргумента мы можем все что можно скастить в строку.

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

учитывая то что по умолчанию в функции render $actionData = [], вы подразумеваете, что это нормально. Нет возможности выбирать, какому параметру оставлять значение по умолчанию, а какому присваивать, поэтому выживаем как можем
upd:
если вас этот факт смущает, сделайте часть параметров передаваемыми через ассоциативный массив.
и будет у вас

function render($actionView, $params = []) {
// понеслось 
 $actionData = (isset($params["actionData"]) && $params["actionData"]) 
 ? $params["actionData"]
: [];
//и тд
}

Самописный фреймворк, что ли?

Вот так сделайте:

public function index()
  {
    $layout = new View("/layouts/main");
    $view = new View("/site/index");
    $layout->set( 'content', $view->render() );
    $layout->set( 'title', $view->title );
    return $layout->render();
  }

Возвращаемое значение должен обрабатывать сам фреймворк, то есть он вызывает метод index (с помощью "рефлексии") и возвращаемый код выводит в echo.

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

Если самописка то в проекте должен быть только один финальный echo который выводит уже готовый шаблон.

echo на прямую в контролере - однозначно зло.

Следуя канонам PHP, любой метод должен возвращать значение. Так что ваш вариант "кривоват". Другое дело, если вы используете какой-то фреймворк, в котором так положено делать. Например в Yii 1.0 экшены контроллера именно так и выглядели. Во второй же версии Yii 2.0 это было исправлено на правильное поведение. Любой экшн возвращал какое-то значение.

Нормально, каких-либо ограничений нет. Дело в удобстве и универсальности, но это решает программист. Зачастую конструкторы и прочие методы могут принимать куда более, чем три аргумента. И ничего плохого в этом нет. Даже с помощью func_get_args() можно очень гибко организовать прием аргументов, если случай сложный.