Ответы пользователя по тегу ООП
  • Angular2 - присваивание в конструкторе в TypeScript как это работает?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    private _http: Http;
    
    constructor(http: Http) {
        this._http = http;
    }


    Подход - Inversion of Control и Dependency Injection как реализация подхода

    Как работает ассайн пропертей из конструктора и почему так делать удобнее: https://www.stevefenton.co.uk/2013/04/stop-manuall...
    Ответ написан
  • Как реализовать объект с методами, которые можно было бы вызывать последовательно?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Возможно вам стоит конкретизировать пример, поскольку то что вы хотите проще делать так:

    var el = document.querySelector('#id .selector span:first-of-type')
    Ответ написан
  • Как реализуется принцип открытости/закрытости в случае "ветвления" расширений в Java?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    основной — наследование.


    Наследование типов а не классов. То есть через интерфейсы.

    В Java нет множественного наследования.


    В Java есть возможность делать композицию типов путем имплементации множества интерфейсов. А с учетом того что в Java8 у вас теперь есть возможность делать "дефолтные" имплементации методов в интерфейсах - у вас есть "правильное" наследование.

    Через некоторое время, этот класс захотят расширить по OCP — унаследуются, и сделают класс Бармен.


    А как потом быть если мы захотим сделать робота бармена? Я это к тому что "человек" не всегда будет являться базовым типом "бармена".

    В целом Dmitry Roo вам верно сказал. "Бармен" это профессия. Свойство человека. У человека может быть много профессий:

    class Human
    {
        Profession[] professions;
    }


    Таким образом мы можем крутить и вертеть как хотим.
    Ответ написан
  • PHP функциональный язык или объектно-ориентированный?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Я могу дать вам лишь мой вариант ответа собеседующему:

    Никаким. Отличительная черта PHP в том, что он не задумывался как язык программирования. Это даже в названии отражено - PHP (recursive acronym for PHP: Hypertext Preprocessor).

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

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

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

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

    Отсюда сделаем вывод - PHP на сегодняшний день, процедурный язык программирования, имеющий достаточно возможностей чтобы практиковать все основные парадигмы программирования просто с разной степенью удобства.
    Ответ написан
  • Где осуществлять валидацию пользовательского ввода в архитектуре MVC?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Давайте размышлять что такое валидация и зачем она нам нужна:

    Нам нужно проверять, не нарушаются ли пред-условия для действий или инварианты состояний. Например - пользователь всегда должен иметь email - такие правила можно запихивать на уровне конструктора класса пользователя. Тогда у нас не будет физически возможности "создать" пользователя не указав email. Что бы убедиться что переданная строка email - мы можем опять же завернуть "примитив" в свой тип Email, таким образов сделав подтип строк, который гарантирует нам, что любая штука относящаяся к этому типу будет являться email-ом.

    Такие правила как "у пользователя должен быть уникальный email" могут быть проверены только там, где достаточно информации. Например - некий репозиторий пользователей, или DAO. При попытке "сохранить" мы уже делаем проверку. Или мы можем делать это просто повесив ограничение на уникальность на уровне базы данных. Это уже не столь важно.

    Различие тут в том, что все это будет вызывать ошибки. То есть мы не сможем вогнать систему в "невалидное состояние" но пользователь не сможет получить список ошибок, которые он совершил вводя какие-то данные. Все что он получит - отдельные ошибки.

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

    В простых случаях, когда данные из запроса втупую мэпятся на "модель данных", мы можем проверять уже результат. Но в случае с логикой сложнее CRUD это уже не выйдет. Точнее это уже чуть сложнее. К примеру мы передали несуществующий айдишник связанной сущности. Мы запросим данные, получим нул, и валидатор выдаст нам что-то вроде "Извините, но вот эта штука обязательна к заполнению". А пользователь такой "чтааа? Я ж заполнил!" Вот если бы ему приходило сообщение мол "Выбранная вами штука не существует" - тогда ладно, но подавляющее большинство так не запаривается.

    Словом... тут нужно исходить не из "где это делается в MVC" а из "а кому это нужно и какие цели вы приследуете".

    Если что, MVC это не все приложение, это лишь способ разделить ответственность. Приложение ничего не должно знать о UI и все. То есть валидация входящих данных вполне может лежать на уровне контроллера поскольку это ему нужно сформировать список ошибок и запихнуть их к полям формы. С другой стороны, часть валидации может происходить вообще вне "MVC", где-то внутри, на уровне модели предметной области.

    Нельзя из букв "M", "V" и "C" составить слово вечность. Именно по этой причине MVC как подход для организации GUI уже лет 20 как не используется в чистом виде.
    Ответ написан
  • Как выбирать направление архитектуры ООП приложения?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    и как отдельный класс-синглтон


    Зачем? Зачем сингелтон? Ответте на вопрос когда это нужно?

    Есть ли практики, которым следует придерживаться, чтобы сделать правильную и простую архитектуру?


    - Разделение ответственности - важный принцип инженерного дела в принципе.
    - Принципы SOLID - хорошо дают понять как работать с зависимостями и делать декомпозицию системы. Сильно пересекается с инкапсуляцией, полиморфизмом и разделением ответственности.
    - Паттерны GRASP - эдакая смесь принципов и паттернов, описывают нюансы цикла жизни объектов и их взаимодействия друг с другом.
    - Закон Деметры - про инкапсуляцию.
    - CQRS - подход по разделению операций записи и операций чтения. Естественно подход такой не работает если вам надо реализовать атомарную запись и чтение, но это минимальный набор задач.
    - Рефакторинг. Он нужен всегда. Его нужно делать по чуть-чуть когда видно что "уже мешает" или "можно было сделать лучше". Ну то есть это не переписывание всего и вся большими кусками, а маленькие изменения которые с течением времени эволюционно меняют архитектуру проекта. Возможно только если код покрыт тестами, это отдельная жирная тема.

    Не нужно знать "архитектуры", они являются лишь результатом соблюдение принципов. И уж тем более "паттерны" это лишь элементы архитектуры. Не нужно на них зацикливаться, это лишь словарь.

    https://en.wikipedia.org/wiki/Category:Programming...
    Ответ написан
  • Отличия абстрактного класса от интерфейса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    В чем отличие абстрактного класса от интерфейса в Java?


    Все упирается в понятие "тип". В былые времена, то есть во времена языка Simula, из которого черпали вдохновение создатели C++, были только классы. И на классах базировалась система типов. Причем механизм наследования был реализован так, как реализован, исключительно для экономии памяти, которая в те времена была очень дорогой.

    Для того чтобы достичь полиморфизма, мы должны иметь возможность объявлять абстрактные типы. Мол "любая хрень которая имеет такой тип будет работать как надо". Потому в языках типа C++ появились абстрактные классы. Поскольку иногда нам хочется делать композицию абстрактных типов, в C++ реализовали множественное наследование.

    В Java, которая во многом черпала вдохновения из C++ и smalltalk, решили ввести еще одну сущность - интерфейсы. Это был своего рода упрощенный способ задать абстрактный базовый тип. По итогу чтобы не решать проблему бриллианта (или ромба) от множественного наследования было решено отказаться и дать возможность классам имплементить несколько интерфейсов.

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

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

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

    Так же рекомендую к прочтению: www.javaworld.com/article/2073649/core-java/why-ex...
    Ответ написан
  • Правильно ли я понимаю паттерн прототип?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    А вы точно читали что это за паттерн и чем он от фабрики отличается?

    В целом ответить на вопрос можно если вы приведете пример использования данного паттерна. Ну и еще учитывайте такой момент - в вашем примере использование прототипа не рационально - клонирование таких объектов как request не сильно то и дорогое.

    p.s. метод `getClone` должен быть приватным. В остальном вроде бы все ок.
    Ответ написан
  • Как перенять объектно-ориентированное мышление?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.


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

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

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

    И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

    А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

    Вообщем писав всё время на процедурке, сложно перейти на ооп.


    Просто не думайте что это что-то "принципиально другое". Это та же самая процедурка, просто благодаря классам и объектам, вы можете порезать систему на маленькие модули. Данные будут лежать рядом с процедурами и у вас будет больше контроля за происходящим.

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

    Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.


    Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

    Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

    Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.


    Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.
    Ответ написан
  • Нужно ли учить ООП (PHP)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    но статья меня пугает, так нужно ли учить ООП или функциональное программирование: Welcome?


    ООП учить не нужно. Большинство вроде как и учат но выходит плохо. ООП надо понимать. Причем это скорее именно проектирование нежели программирование.

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

    А так... скажем так, использовать классы вам придется. В PHP другого способа изолировать состояние нет. Просто не надо думать что ООП про наследование (о чем большая часть статьи), оно про изоляцию состояния, взаимодействие объектов/модулей посредствам "общения" (tell don't ask, закон деметры), про позднее связывание (возможность подменить реализацию)... А не как не про классы. Классы лишь способ. Инкапсуляция, полиморфизм, наследование - все это было до ооп. Разве что наследование в Simula67 сделали в более удобном виде. Но все же считать этот язык объектно ориентированным не стоит. На его основе потом Страуступ плюсы сделал, и так же не думал делать объектно-ориентированный язык. Он хотел структурировать процедурный Си, задать так сказать культуру разработки. Менять парадигму он не собирался.

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

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    и объявляет глобальные вспомогательные переменные.


    про автозагрузку вам уже ответили - используйте composer. А на счет глобальных "вспомогательных" переменных - избавьтесь от них. Используйте контейнер зависимостей или сервис локаторы для управления зависимостями и конфигурации системы.

    Либо учитесь делать изолированное состояние - либо просто забейте и пишите процедурно как во времена php4. В этом нет ничего страшного, подавляющее большинство даже не знают о том что у них процедурщина с классами.
    Ответ написан
  • Как лучше разбить логику?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Пытаюсь понять SRP


    Давайте думать. Вот есть у вас класс который:

    - занимается аутентификацией пользователя
    - занимается регистрацией пользователя
    - занимается восстановлением пароля

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

    С другой стороны, давайте думать дальше. Если мы поместим все эти операции в рамках юзера - то как бы... все клево) юзер умеет менять свой пароль, юзер умеет логиниться, а регистрация - это просто создание нового юзера. То есть с точки зрения ООП все круто, и нам не нужно ломать инкапсуляцию юзера. Да, юзер много чего будет уметь и возможно даже знать о чем-то о чем не особо должен - но это уже решается инверсией зависимостей и делегированием.

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

    p.s. маленький вброс: https://gist.github.com/fesor/33f041e3f362beff8d0e...
    Ответ написан
  • В каком месте mvc системы должен находиться шаблонизатор?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1. шаблонизатор - это просто компонент. Они ничего не знает о MVC и прочем булшите
    2. шаблонизатор нужен там, где формируется view. Вы можете крутиться как хотите, но view на бэкэнде пассивно (это http ответ) в подавляющем большинстве реализаций (даже в ADR от которого нынче писают кипятком), а это значит что формироваться view будет в контроллере. Отсюда делаем вывод что шаблонизатор должен дергаться в контроллере а такого компонента как view у нас просто нет. Возможны хэлперы которые помогают формировать этот самый view но не более.
    3. управление зависимостями не входит в зону ответственности MVC. Оно обычно где-то сверху, тут можно заюзать Dependency Injection (только готовый контейнер если, свой не пишите).
    4. трейты в контроллерах нормальная тема просто потому что на код контроллеров нам должно быть плевать с высокой колокольни. Если вам не плевать на код контроллеров - возможно вы там делаете что-то чего контроллеры делать не должны. Ну и опять же это будет трейт который будет делегировать задачу шаблонизатору а не реализовывать его.
    5. что-то мне подсказывает что "модель" в вашей системе координат это какой-нибудь класс для работы с базой данных. Если так - вы не поняли зачем вообще вводится это разделение.
    Ответ написан
  • Как добавить метод к классу если переопределить класс нельзя?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    завернуть работу с этими сервисами в еще один сервис который собственно будет выступать фасадом и скрывать всю грязь что вы делаете что бы было удобно.
    Ответ написан
  • Как использовать рефлексию для метода?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    чем вас не устраивает call_user_func_array?

    p.s. ответ на ваш вопрос есть в документации по рефлексии.
    Ответ написан
  • Друзья, каким образом изменить значение свойства $b (прибавить единицу) у каждого объекта класса T, заданного в конструкторе класса G?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) var - не используйте это ключевое слово. Используйте public. А еще лучше - private.
    2) инкапсуляция, закон деметры. Не меняйте состояние объектов напрямую. Используйте сообщения (вызовы методов).
    3) вот эти свистоплязки с динамическим созданием имен переменных лишены всякого смысла
    4) имена классов, свойств, методов и вообще должны быть осмысленны. Вы должны быть в состоянии, ну не знаю, прочитать код вслух! и что бы всем вокруг все было понятно.

    class T{
        private $b;
        private $s;
    
        public function __construct() 
        {
             $this->b = mt_rand(0, 1000);
             $this->s = 'foo';
        }
    }
    
    class G
    {
        public function __construct(array $t) 
        {
              // ...
        }
    }
    
    $g = new G(array_map(function () {
        return new T();
    }, range(1, 4));
    Ответ написан
  • Как правильно создавать классы внутри объектов в javascript?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    реализовать подобие ООП в JavaScript


    Скажите где в аббривиатуре "ООП" вы видите слово "класс"?)

    Хочу например создать объект вот так:


    А зачем? "нэймспейсы"? Это не нужно если есть модули.

    Как мне создать конструктор внутри объекта Earth


    любая функция может быть использована как конструктор.
    Ответ написан
  • Как не нарушать SOLID?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    вы путаете инверсию контроля и инверсию зависимости. Давайте по порядку кратенько.

    Зачем нам нужны контроллеры или различные представления данных

    Зачем нам в принципе контроллер? Что он делает? Для упрощения не будет воспринимать контроллер как "один объект" и вместо этого представим себе его как целый слой. Так же заменим слово "модель" словом "приложение".

    Задача контроллера - принять и обработать запрос и выдать ответ. По сути в контексте WEB наш HTTP запрос и ответ это представление, которое хочет получить клиент (браузер, мобильное приложение, SPA, что угодно). HTTP - это интерфейс пользователя (UI) для нашего web-приложения.

    Например что бы независеть от реализации клиента и что бы было удобно мы передаем даты в формате iso 8601 (пример: 2016-07-14T19:40:12Z). Это удобно что бы быть независимым от реализации клиента или сервера. Но это не удобно для нашего приложения. В приложении скорее всего нам удобнее всего работать с объектом типа DateTime. То есть приложение использует абсолютно другое представление.

    Мы могли бы прямо в приложении конвертить DateTime в iso 8601 но тогда мы делаем наше приложение привязанным к одному конкретному представлению, которое хочет получить клиент. К примеру по каким-нибудь причинам известным только темным богам, вам вдруг понадобится быстро прикрутить интеграцию с другим сервисом и те же данные гонять уже в RFC2822. И стало быть уже приложению нужно париться о еще одном представлении.

    Мы могли бы сделать какие-то адаптеры у приложения, и дергать их в зависимости от потребностей, но тогда опять же наше приложение все еще знает о представлении, которое ему собственно не нужно. То есть у нас есть зависимость приложения от его UI что... похоже на "не лучшую идею". И тут на помощь приходит Inversion of Control.

    Что такое Inversion of Control

    Тут название само говорит за себя. Допустим у нас был объект A который дергал объект B, причем объект A по сути и не должен ничего знать об объекте B потому то это не его дело. Принцип инверсии контроля говорит нам о том, что в таких ситуациях именно B должно вызывать A, таким образом меняя направление потока управления. Это позволяет нам уменьшить связанность и повысить зацепление компонентов нашей системы. Так же сделав это у нас может появиться объект C который так же будет дергать объект A. Если говорить о UI - мы просто можем сделать несколько реализаций UI.

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

    Роутер и контроллеры как реализация UI

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

    Так а инверсия зависимости это что?

    Инверсия зависимости - очень похожа на инверсию контроля но действует чуть по другому. Проще всего будет вглянуть на картинку:

    Dependency_inversion.png

    стрелочка зависимости на первой фигуре выходит за пределы нашего "модуля" и залазит в "чужой", тем самым наш модуль становится зависимым от другого модуля. Яркий пример - у нас есть например SwiftMailer для отправки почты. Нашему коду нужен просто способ отправлять сообщения, а SwiftMailer просто конкретная реализация.

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

    Нужно ли соблюдать принцип инверсии зависимости в случае контроллеров?

    Нет. Контроллеру нужна конкретная реализация какой-то части нашего приложения (ибо приложение главнее UI-ки), иначе в них нет особо смысла. И наше приложение вообще не должно париться о том что есть какие-то там контроллеры.

    будет ли правильным передавать зависимости в роутинге

    Это уже вопрос реализации IoC. Конкретно вы хотите получить что-то вроде Dependency Injection. Вы можете забрать зависимости из аргументов метода экшена. или аргументов конструктора контроллера.... или просто использовать контейнер зависимостей внутри контроллера.... это совершенно не важно. Контроллеры это то место где высокая связанность на компоненты фреймворка более чем допустимы.

    С другой стороны у вас теперь роутинг совмещает обязанность маршрутизации и разруливания зависимостей. Сами понимаете что это как-то нарушает прицип единой ответственности. Этим может заниматься Controller Resolver какой-нибудь.
    Ответ написан