Как правильно использовать паттерны проектирования? Всем доброго времени суток! Читаю сейчас книгу банды четырёх и в параллель "Паттерны проектирования" Фрименов. И некоторые вещи мне реально взрывают мозг.
Пока вынес оттуда, это то, что надо стремится к слабой связанности и программировать на уровне интерфейсов, а не реализаций. Но вот когда доходит дело до реального применения, я впадаю в ступор.
Т.е. понятно, что у нас есть некоторые модули, которые могут (и возможно даже будут) использоваться в других местах (других проектах и т.п.). И там (в модулях/сервисах) ты реально используешь все эти паттерны и всё круто.
Но вот когда дело доходит до использования этих модулей, начинается какая то каша. Вот есть контроллеры/вьюхи (ещё что то). Они привязаны к конкретному проекту и нигде больше не будут использоваться (разве что в качестве сниппетов).
Зачем им передавать кучу зависимостей? Зачем их делать слабосвязанными?
Не проще ли им тянуть все зависимости из глобального объекта приложения (который, по сути, будет синглтоном и SL (Service Locator) или DIC (Dependency Injection Container))?
Может, я что-то не так понимаю?
Как правильно использовать паттерны проектирования? Всем доброго времени суток! Читаю сейчас книгу банды четырёх и в параллель "Паттерны проектирования" Фрименов. И некоторые вещи мне реально взрывают мозг.
Пока вынес оттуда, это то, что надо стремится к слабой связанности и программировать на уровне интерфейсов, а не реализаций. Но вот когда доходит дело до реального применения, я впадаю в ступор.
Т.е. понятно, что у нас есть некоторые модули, которые могут (и возможно даже будут) использоваться в других местах (других проектах и т.п.). И там (в модулях/сервисах) ты реально используешь все эти паттерны и всё круто.
Но вот когда дело доходит до использования этих модулей, начинается какая то каша. Вот есть контроллеры/вьюхи (ещё что то). Они привязаны к конкретному проекту и нигде больше не будут использоваться (разве что в качестве сниппетов).
Зачем им передавать кучу зависимостей? Зачем их делать слабосвязанными?
Не проще ли им тянуть все зависимости из глобального объекта приложения (который, по сути, будет синглтоном и SL (Service Locator) или DIC (Dependency Injection Container))?
Может, я что-то не так понимаю?
Пока вынес оттуда, это то, что надо стремится к слабой связанности и программировать на уровне интерфейсов, а не реализаций. Но вот когда доходит дело до реального применения, я впадаю в ступор.
Т.е. понятно, что у нас есть некоторые модули, которые могут (и возможно даже будут) использоваться в других местах (других проектах и т.п.). И там (в модулях/сервисах) ты реально используешь все эти паттерны и всё круто.
Но вот когда дело доходит до использования этих модулей, начинается какая то каша. Вот есть контроллеры/вьюхи (ещё что то). Они привязаны к конкретному проекту и нигде больше не будут использоваться (разве что в качестве сниппетов).
Зачем им передавать кучу зависимостей? Зачем их делать слабосвязанными?
Не проще ли им тянуть все зависимости из глобального объекта приложения (который, по сути, будет синглтоном и SL (Service Locator) или DIC (Dependency Injection Container))?
Может, я что-то не так понимаю?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Паттерны проектирования действительно могут быть сложными и запутанными на первый взгляд, но их цель - помочь создавать гибкий и расширяемый код. При использовании паттернов следует помнить о принципе SOLID (пять принципов объектно-ориентированного программирования), включая принцип единственной ответственности (Single Responsibility Principle) и принцип инверсии зависимостей (Dependency Inversion Principle).
В вашем случае, даже если контроллеры или вьюхи не будут использоваться в других проектах, делание их слабосвязанными и передача зависимостей через инъекцию поможет сделать код более читаемым, поддерживаемым и тестируемым. Кроме того, использование Dependency Injection Container или Service Locator поможет упростить процесс управления зависимостями.
Если ваши контроллеры и вьюхи становятся слишком зависимыми от глобального объекта приложения, это может привести к жесткой связанности и затруднить тестирование и поддержку кода. Поэтому рекомендуется продолжать использовать паттерны и принципы проектирования в своем коде, даже если он нигде больше не будет использоваться. В конечном итоге, это поможет создать качественное и эффективное программное обеспечение.