Perl → Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
Думаю многие понимают значение баззвордов Inversion of Control (Ioc) и Dependency Injection (DI). Если не очень, но интересно — на хабре было несколько статей на эту тему, очень познaвательно и доступно изложено.
Методики отличные, но применить их в настоящей жизни как-то не получалось.
Под катом — небольшой обзор плачевного состояния дел в Perl и самостийное «кажется» решение.
Методики отличные, но применить их в настоящей жизни как-то не получалось.
Под катом — небольшой обзор плачевного состояния дел в Perl и самостийное «кажется» решение.
PHP → IoC на PHP
Inversion of Control (IoC) контейнеры — это удобный способ организации внедрения зависимости получивший широкое применение в мире Java.
Данная библиотека позволяет использовать IoC контейнеры в PHP.
Данная библиотека позволяет использовать IoC контейнеры в PHP.
.NET → IoC, DI, IoC-контейнер — Просто о простом из песочницы
Думаю сейчас слова IoC, DI, IoC-контейнер, как минимум у многих на слуху. Одни этим активно пользуются, другие пытаются понять, что же это за модные веяния.
На данный момент, на эту тему уже довольно сказано, написано, в том числе и на хабре, но как раз из-за обилия информации сложно найти действительно полезный контент. Кроме того, данные понятия часто смешивают и/или путают. Проанализировав множества материалов я решил изложить вам свое видение предмета.
На данный момент, на эту тему уже довольно сказано, написано, в том числе и на хабре, но как раз из-за обилия информации сложно найти действительно полезный контент. Кроме того, данные понятия часто смешивают и/или путают. Проанализировав множества материалов я решил изложить вам свое видение предмета.
Разработка под Android → Шаблоны проектирования при разработке под Android. Часть 1 — Введение из песочницы
Писать программки для смартфонов — мое хобби. Все началось с того, что я купил свой первый смартфон Nokia E51 на Symbian и мне очень нравилось что его функционал можно было расширить через установку дополнительных программ.
Но однажды я не нашел необходимой программы и решил написать ее сам. Так и началось мое увлечение программами для смартфонов.
После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.
Для лучшего усвоения материала я решил написать полезную, хотя бы для себя, программку. Но написать ее не по детски, когда куски примитивного кода копируются из документации, а по взрослому с разработкой архитектуры, и использованием современных технологий программирования TDD, MVP и IoС.
Но однажды я не нашел необходимой программы и решил написать ее сам. Так и началось мое увлечение программами для смартфонов.
После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.
Для лучшего усвоения материала я решил написать полезную, хотя бы для себя, программку. Но написать ее не по детски, когда куски примитивного кода копируются из документации, а по взрослому с разработкой архитектуры, и использованием современных технологий программирования TDD, MVP и IoС.
.NET → StructureMap — краткий справочник для работы (3/3)
Теперь наступило время для:
С версии 2.5+ появилась возможность постобработки только что созданного объекта, либо полной его замены. В данном случае не ставится целью создать еще одни AOP фреймворк, так как их уже достаточно в мире, просто это может облегчить жизнь.
Для постобработки существует два+ метода:
- Перехватчики (OnCreation, EnrichWith)
- Дженерик типы
- Аттрибуты (DefaultConstructor, ValidationMethod, Все остальные)
- Немного о тестах
Перехватчики
С версии 2.5+ появилась возможность постобработки только что созданного объекта, либо полной его замены. В данном случае не ставится целью создать еще одни AOP фреймворк, так как их уже достаточно в мире, просто это может облегчить жизнь.
Для постобработки существует два+ метода:
- OnCreation – принимает в качестве параметра Action, позволяет провести свою (custom) инициализацию объекта. Есть доступ к контексту SturctureMap.
- EnrichWith – принимает в качестве параметра Function. Может возвращать любой тип совместимый с запрашиваемым.
- Свои перехватчики
.NET → StructureMap — краткий справочник для работы (2/3)
Продолжение первого поста о StructureMap
В первой части были освещены темы:
В этой части пойдет речь о:
Очень важный вопрос в реальном программировании применительно к разрешению зависимостей в IoC контейнерах, как быть с классами, у которых несколько конструкторов. Как их инициализировать, как задавать параметры, как дорабатывать и прочее и прочее. Надеюсь что на большинство вопросов ниже будет дан ответ. StructureMap действительно мощная и гибкая штука.
Перед тем как начать описывать возможности фреймворка, надо поговорить о тестовых классах. В этот раз они будут сложнее. Наследование, конструкторы с простыми типами, с составными.
В первой части были освещены темы:
- Установка
- Регистрация (Основа, Профили, Плагины, Сканирование, Внедрение)
В этой части пойдет речь о:
- Конструкторы (Простые типы, Конструктор по умолчанию, Составные типы, Приведение типов, Задание аргументов)
- Свойства (Простое задание свойств, Встроенное задание свойств, Задание свойств фреймворком, Допостроение существующих классов)
- Время жизни
Конструкторы
Очень важный вопрос в реальном программировании применительно к разрешению зависимостей в IoC контейнерах, как быть с классами, у которых несколько конструкторов. Как их инициализировать, как задавать параметры, как дорабатывать и прочее и прочее. Надеюсь что на большинство вопросов ниже будет дан ответ. StructureMap действительно мощная и гибкая штука.
Перед тем как начать описывать возможности фреймворка, надо поговорить о тестовых классах. В этот раз они будут сложнее. Наследование, конструкторы с простыми типами, с составными.
.NET → StructureMap — краткий справочник для работы (1/3)
Сегодня я хочу рассказать о IoC контейнере StructureMap (и это не перевод устаревшей официальной документации), который мне приглянулся гораздо больше чем Unity. Хотя, честно сказать, мои взаимоотношения с Unity не сложились с самого начала, когда я увидел километровые файлы конфигурации к нему или же двухсот знаковые строки конфигурации в коде. Не будем о грустном.
StructureMap не только мне показался более удобным чем другие реализации DI\IoC, достаточно набрать в гугле StructureMap vs Unity и получить кучу ссылок, где люди обсуждают и показывают наглядно, что в работе самым удобным, гибким и естественным является StructureMap.
Ссылка раз, два и три. Ко всему прочему StructureMap еще и достаточно быстрый.
Вот еще очень интересные подборки материалов по сравнению фреймворков http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net
Я думаю можно опустить рассуждения о том, стоит ли такие контейнеры использовать в своем проекте или нет, и стоит ли писать свою реализацию. Я могу сказать, что в моей практике сначала случилось так, что были самописные реализации, которые заметно уступали по возможностям и удобству, но они решали свои конкретные задачи и этого на тот момент хватало. С развитием проекта, как-то было недосуг переводить все на какую-то другую технологию. Потом был Unity, Unity, но в конце концов я пришел к тому, что надо попробовать StructureMap и не пожалел об этом ни разу.
В чем, на мой взгляд, плюсы StructureMap:
Еще много есть интересных и полезных вещей в StructureMap, но их было бы неправильно отнести к плюсам, лучше назвать их приятным дополнением, которые только облегчают жизнь.
StructureMap не только мне показался более удобным чем другие реализации DI\IoC, достаточно набрать в гугле StructureMap vs Unity и получить кучу ссылок, где люди обсуждают и показывают наглядно, что в работе самым удобным, гибким и естественным является StructureMap.
Ссылка раз, два и три. Ко всему прочему StructureMap еще и достаточно быстрый.
Вот еще очень интересные подборки материалов по сравнению фреймворков http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net
Я думаю можно опустить рассуждения о том, стоит ли такие контейнеры использовать в своем проекте или нет, и стоит ли писать свою реализацию. Я могу сказать, что в моей практике сначала случилось так, что были самописные реализации, которые заметно уступали по возможностям и удобству, но они решали свои конкретные задачи и этого на тот момент хватало. С развитием проекта, как-то было недосуг переводить все на какую-то другую технологию. Потом был Unity, Unity, но в конце концов я пришел к тому, что надо попробовать StructureMap и не пожалел об этом ни разу.
В чем, на мой взгляд, плюсы StructureMap:
- Настройка с помощью DSL
- Очень гибкая настройка всего
- Простота конечного использования
- Возможности для проверки внутренних связей
- Поддержка тестирования out-of-the-box
Еще много есть интересных и полезных вещей в StructureMap, но их было бы неправильно отнести к плюсам, лучше назвать их приятным дополнением, которые только облегчают жизнь.
.NET → PostSharp. Отложенная загрузка зависимостей
Кусок кода, представленный ниже, вы наверняка писали не один раз. А что более вероятно – десятки раз. Обычно это пишется, когда необходимо использовать некий репозиторий, который будет предоставлять данные для вашего приложения. Если у вас мало времени, и вы торопитесь, это отличный способ получить что-либо таким образом, что это будет загружено в память только тогда, когда это вам понадобится, но не раньше (например, операция сохранения повлекла за собой обращение к подсистеме сериализации, однако до этого она не была нужна). И ведь на самом деле получается, что этот кусок кода с одной стороны одинаков, а с другой – его приходится писать не один раз. Как правило, я и многие программисты, предпочитаем использовать в данном месте IoC контейнер, чтобы решать задачи такого рода. Однако это не всегда так просто сделать, особенно когда я программирую в рамках отсутствия Dependency Injection в библиотеке, которую я использую (WinForms, WebForms, …). Давайте разберемся, почему решая эту задачу без использования PostSharp, вы потратите гораздо больше времени и проделаете больше работы.
Совершенный код → Инверсия управления/Inversion of Control
Инверсия управления является распространенным явлением, с которым вы столкнетесь при использовании фреймворков. И действительно, она часто рассматривается как определяющая характеристика фреймворка.
Давайте рассмотрим простой пример. Представьте себе, что я пишу программу, которая получает некоторую информацию от пользователя с помощью командной строки. Я мог бы сделать это как-то так:
В этой ситуации мой код управляет исполнением: он решает, когда задавать вопросы, когда считывать ответы, а когда обрабатывать результаты.
Однако если бы я использовал оконную систему для чего-то похожего, я написал бы что-то, что работает с окном:
Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем, когда вызываются методы process_name и process_quest. В примере с коммандной строкой я контролирую, когда эти методы вызываются, но в примере с оконным приложением нет. Вместо этого я передаю контроль оконной системе (команда Tk.mainloop). Далее она решает, когда вызвать мои методы, основываясь на связях, которые я настроил при создании формы. Управление инвертировано — управляют мной, а не я управляю фреймворком. Это явление и называется инверсией управления (также известно как Принцип Голливуда — «Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»).
Давайте рассмотрим простой пример. Представьте себе, что я пишу программу, которая получает некоторую информацию от пользователя с помощью командной строки. Я мог бы сделать это как-то так:
#ruby
puts 'What is your name?'
name = gets
process_name(name)
puts 'What is your quest?'
quest = gets
process_quest(quest)
В этой ситуации мой код управляет исполнением: он решает, когда задавать вопросы, когда считывать ответы, а когда обрабатывать результаты.
Однако если бы я использовал оконную систему для чего-то похожего, я написал бы что-то, что работает с окном:
require 'tk'
root = TkRoot.new()
name_label = TkLabel.new() {text "What is Your Name?"}
name_label.pack
name = TkEntry.new(root).pack
name.bind("FocusOut") {process_name(name)}
quest_label = TkLabel.new() {text "What is Your Quest?"}
quest_label.pack
quest = TkEntry.new(root).pack
quest.bind("FocusOut") {process_quest(quest)}
Tk.mainloop()
Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем, когда вызываются методы process_name и process_quest. В примере с коммандной строкой я контролирую, когда эти методы вызываются, но в примере с оконным приложением нет. Вместо этого я передаю контроль оконной системе (команда Tk.mainloop). Далее она решает, когда вызвать мои методы, основываясь на связях, которые я настроил при создании формы. Управление инвертировано — управляют мной, а не я управляю фреймворком. Это явление и называется инверсией управления (также известно как Принцип Голливуда — «Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»).
Персональные блоги → Swiz Framework (краткий обзор)
Swiz это фреймворк для Flex, AIR и Flash который был создан для быстрой разработки RIA приложений. Основные фичи swiz это:
В сравнении с другими фреймворками для Flex:
- Инверсия управления (IoC) / Внедрение зависимостей
- Управление событиями и медиаторы
- Простой жизненный цикл для удаленных вызовов
- Фреймворк который не зависит от вашего кода
В сравнении с другими фреймворками для Flex:
- Отсутствие необходимости JEE паттернов
- Нет необходимости в куче повторяющихся папок
- Нет кучи копипастеных кусков кода
- Не обязательно наследовать классы фреймворка