Совершенно просто, конечно, имеет смысл группировать части приложения в соответствующие модули.
Обычно, разделение этих модулей не является проблемой, однако часто возникает необходимость в том, что данные из модуля управления пользователями требуются другими компонентами.
По нормальным принципам он существенно меньше идеалов, что эти клиентские модули будут знать внутренние классы пользовательского модуля и т. Д., Что подводит меня к вопросу о том, как наилучшим образом сконструировать эту межмодульную связь.
Мои мысли до сих пор состоят в том, что модуль может иметь условно названный класс API, через который другие модули могут «запрашивать» модуль. Этот подход все равно приведет к определенной зависимости, но, по крайней мере, только к другому модулю / его API.
Ваши мысли об этом будут очень приветствоваться.
Спасибо заранее, Джеймс
Вы можете назвать пользовательский модуль «библиотекой». Это изменение терминологии может помочь уточнить, какие модули должны быть на высшем уровне, и какие из них управляют действиями более низкого уровня, которые предназначены для использования несколькими другими модулями. В основе этого подхода лежит инфраструктура CodeIgniter PHP .
Ну, «модуль» крайне неопределенен – именно то, что определяет модуль, может сильно варьироваться от системы к системе.
Я действительно смущен тем, какой тип сценария вы пытаетесь избежать. Это не редкость для двух классов или групп классов для общения с eachother. Вот почему у нас есть такие вещи, как интерфейсы.
Я предполагаю, что в вашем сценарии у вас может быть класс, подобный контроллеру (как в C от MVC) между вашими модулями, которые знали бы кишки каждого и могли бы служить мостом связи.
Возможно, вы захотите прочитать «инъекцию зависимостей». Symfony Components предлагает решение для Injection Dependency Injection и имеет много хороших примеров чтения / примеров по этому вопросу.