Как реализовать паттерн модуль на PHP?

Question

[Dubrovin]

Дано:
1. Главный класс приложения (фреймворк, апп или т.п.)
2. Классы модулей (отдельных частей) приложения (могут быть со статическими методами или нет)

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

Answer 1

[Кирилл Несмеянов]

Это называется интерфейсы и автолоадинг.

Answer 2

[Андрей]

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

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

Comments

[Dubrovin]

Как подсовывать то? Пример реализации есть?

[Андрей]

Тут хорошо описан пример (не на php, но принцип понять можно) нужного вам фасада.

[Dubrovin]

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

Answer 3

[Dubrovin]

Я в общем нашёл решение. Головной класс Framework наследуется от Singleton. Экземпляры отдельных классов (модулей) создаются в методе init класса Framework через new и сохраняются в свойства класса Framework. Модули общаются друг с другом только через фреймворк из любой части кода, например Framework::i()->file_system->get_contents( $file ). Таким образом, модули ничего не знают друг про друга. Если модуль при каких-либо условиях не должен загружаться, то он оборачивается в условие в методе init и экземпляр этого модуля не создаётся.
Очень странно, что мало кто разбирается в архитектуре и все дают ответы в виде "лозунгов" без конкретных примеров кода.

Comments

[Кирилл Несмеянов]

То, что вы реализовали - это называется "фасад" и сам по себе - это довольно отвратный вариант.

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

Вам дают основу, которую вы решили видимо проигнорировать, а реализаций может быть тысяча и одна. Да хоть тот же PSR-11 чем не реализация того, что вам надо? https://www.php-fig.org/psr/psr-11/

[Dubrovin]

Кирилл Несмеянов, фасад - это когда снаружи кто-то обращается к методу фреймворка (не зная ничего о его внутреннем устройстве). В данном случае это не фасад. Классы, которые обращаются к главному классу - это тоже часть фреймворка и они "знают" о свойствах фреймворка в которых нужно вызывать методы. Это называется медиатор (посредник). Получается, что главный класс одновременно является фасадом (для того, чтобы предоставлять API для использования фреймворка) и медиатором (для того, чтобы подружить все классы друг с другом без тесной связи - методы фреймворка всегда можно переписать).
По вашей ссылке вообще никаких примеров нет, три строчки элементарного кода, который вообще никак с архитектурой не связан. Второй уже ответ от вас бесполезный. Ещё раз повторюсь - вопрос был именно в реализации. То что вы пишите что реализаций может 100500 - это бред. В данном конкретном случае правильная реализация только одна и я её описал.

[Кирилл Несмеянов]

фасад - это когда снаружи кто-то обращается к методу фреймворка (не зная ничего о его внутреннем устройстве)

ага


А медиатор - это вообще система эвентов, прогнанная сквозь единый пайплаин. А-ля симфони. Смешались кони, люди...

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

Ну естественно, гуглить это так сложно! PSR-11 - это стандарт, на котором основан, например симфони DI: https://github.com/symfony/symfony или Laravel: https://github.com/illuminate/container или аура: https://github.com/auraphp/Aura.Di или phpdi: https://github.com/PHP-DI/PHP-DI или railt: https://github.com/railt/container

И всё это PSR-11, который вы посчитали бесполезным, который является основой Symfony, Laravel, Zend, Yii и вообще любого современного фреймворка/приложения. Смотрите внимательно, вжух: https://github.com/illuminate/contracts/blob/maste... и PSR-11. Магия!

Второй уже ответ от вас бесполезный

Ну если автор вопроса сам не может сформулировать свои мысли, и просто погуглить по приведённым ссылкам, то и ежик ему не товарищ.

А если я не прав, расскажите почему psr-0/psr-4 (по приведённым мною в самом первом ответе кейвордам про автолоадинг) не отвечает:

Как в зависимости от условий в главном классе подключать классы модулей

А psr-11 (а это уже второй пункт в моём ответе) с интерфейсами и инверсией зависимостями.

использовать их методы через главный класс

Аргументы вашим голословным утверждениям будут?

[Dubrovin]

На картинке у вас с фасадом - фасад обращается к классам субсистемы, а я говорю, что мне нужно из класса сабсистемы обращаться к ДРУГОМУ классу через главный класс.
Например, есть классы Application, Framework, Framework_Feature1, Framework_Feature2.
Application - класс приложения, управляет жизненным циклом Framework.
Если мне нужно из Application обратиться к методу foo() класса Framework_Feture1, то я "пробрасываю" этот метод в класс Framework и обращаюсь как Framework->foo(); В данном случае класс Framework является фасадом по отношению к Application.
Мне было нужно совершенно другое. Мне нужно из класса Framework_Feature1 обратиться к методу класса Framework_Feature2 (например boo()). Если я обращусь как Framework_Feature2->boo(), то класс Framework_Feature1 будет зависеть от класса Framework_Feature2. (И таких зависимостей будет куча среди всех подклассов фреймворка). Поэтому, я создаю в классе Framework экземпляры классов Framework_Feature1 и Framework_Feature2 и уже внутри класса Framework_Feature1 обращаюсь к методу boo() не как Framework_Feature2->boo(), а как Framework->feature2->boo(). Фреймворк по отношению к классам Framework_Feature1 и Framework_Feature2 - не фасад (!), эти классы "знают" про устройство фреймворка, а фреймворк знает про эти классы. Это посредник (медиатор).
Я просил КОНКРЕТНЫЙ пример реализации, а не кучу ссылок на стандарты, в которых Я НЕ НАШЁЛ примера реализации, который я описал выше!