Почему шаблон внедрения зависимостей не был включен в группу из четырех человек ? GOF предшествовал широкому распространению автоматизированного тестирования? Считается ли внедрение зависимостей основным шаблоном?
design-patterns
Том Сквайрс
источник
источник
Ответы:
Я был редактором журнала Software Development, когда вышла книга «Банды четырех», и я могу с полной уверенностью сказать, что модульное тестирование не было широко распространенной практикой в 1994 году, когда первоначально были опубликованы шаблоны проектирования .
В 1994 году C ++ был наиболее часто используемым объектно-ориентированным языком, и большинство людей, программирующих его, исходили из языка Си. Одной из вещей «мышления в объектах», которых просто не было у людей, является идея сотен или тысяч точек входа в вашу программу. Вы думали о
main(). Если вы работали над большим проектом, у вас может быть (обычно довольно сложный) make-файл для создания программы на основе модулей. Но "юнит-тестирование"? Запуск процесса, создание необходимого контекста памяти, его выполнение и разрушение для каждого метода ? Это было очень радикально.Java сделала программирование с несколькими точками входа более очевидным. Ко времени первоначального бума в Dot-Com модульное тестирование было общеизвестной техникой, но именно JUnit (около 2001 года?) Заставил его загореться и стать универсальной практикой.
Хотя стратегия и общая концепция программирования интерфейса были частью GoF и духом времени середины 90-х, идея внедрения пришла довольно поздно (около 03–05?). Честно говоря, мои седые волосы все еще довольно сомнительны в отношении этого аспекта DI («Убирайся с моей лужайки, черт возьми, файлы конфигурации!»).
источник
Они назвали это Стратегией .
Их стратегия, кажется, имеет все особенности внедрения зависимостей без комплексного названия.
источник
Я думаю, что Dependency Injection более актуально при разделении реализации по уровням. Еще одна область, где мы думаем о внедрении зависимостей, это модульное тестирование. И ваше предпоследнее предложение кажется правильным. Если банда будет собирать и разделять шаблоны в 2012 году, то определенно произойдет внедрение зависимости.
Стратегия может обсуждаться, но в Стратегии не говорится о внедрении зависимости. Но при использовании шаблона стратегии в одном проекте или dll (все классы и интерфейсы остаются в одном проекте), оказывается, что мы внедряем зависимости. На самом деле мы не.
Теперь, если классы и интерфейсы, упомянутые в шаблоне стратегии, разделены в разных проектах или уровнях, тогда МЫ должны будем использовать методы внедрения зависимостей. Мы могли бы использовать файлы конфигурации для единства (однако изменение во время выполнения невозможно). Но шаблон Стратегии не говорит о том, как ввести зависимость.
Если существует шаблон, который очень похож на внедрение зависимостей, то это шаблон Абстрактного фабричного метода. Этот шаблон можно использовать внутри шаблона стратегии для внедрения зависимости.
источник
Стратегия ответа на 100% правильная. Я проголосовал за это, но могу прокомментировать.
«Стратегия позволяет алгоритму варьироваться независимо от клиентов, которые его используют. [1] Стратегия - это один из шаблонов, включенных во влиятельную книгу« Шаблоны проектирования »Гаммы и др., Которая популяризировала концепцию использования шаблонов для описания разработки программного обеспечения».
Шаблон дизайна не зависит от его использования. Внедрение зависимостей осуществляется с помощью шаблона «Стратегия». Если бы мы назвали каждый шаблон в зависимости от варианта использования, нам пришлось бы переименовать множество шаблонов.
Шаблон репозитория - это не новый шаблон, это шаблон шаблона.
«В методе шаблона этого шаблона проектирования один или несколько шагов алгоритма могут быть переопределены подклассами, чтобы обеспечить различное поведение при одновременном соблюдении всеохватывающего алгоритма».
Часто шаблоны представляют собой несколько шаблонов, объединенных и названных, например, шаблон MVC.
GOF не имел интерфейсов используемых классов Pure Abstract, а также использовал способность C ++ наследовать от нескольких классов.
источник