Версия для мобильногоЭто перевод публикации Ника Ходжеса от 08 октября 2011 года: Getting Giddy with Dependency Injection and Delphi Spring #7 – Controlling Construction.
Все переводы по Spring
- Я не переводил части с 1й по 5ю, потому что мне было лень - там очень много текста, и, по моему скромному мнению, эти части не содержат конкретной информации об использовании Delphi Spring, а постепенно подводят к необходимости использования Dependency Injection. Причём, Ник ведёт к этому слишком длинным и запутанным путём. См. Ссылки по теме.
- DI и Delphi Spring. Часть 5. Основы Delphi Spring.
- DI и Delphi Spring. Часть 6. Обойдёмся без конструктора.
- DI и Delphi Spring. Часть 7. Контроль над созданием.
- DI и Delphi Spring. Часть 8. Разное.
- DI и Delphi Spring. Часть 9. Один интерфейс несколько реализаций.
Как обычно, Delphi Spring Framework можно скачать с GoogleCode.
К настоящему времени вы получили представление о внедрении зависимостей и о том, как его использовать для разрывания связей в коде и создания объектов. Надеюсь, вы понимаете преимущества от написания кода ориентированного на интерфейсы, а не на реализацию. И если дела идут действительно хорошо, то вы уже с легкостью пишете модульные тесты, ведь ваш код теперь так легко тестировать.
Держу пари, что некоторые из вас думают, что тут не обошлось без магии и наверняка там, за кулисами, происходит слишком много всего.
Вы правы на этот счёт – там действительно много всего происходит. Delphi Spring Framework делает за вас кучу работы – в основном за счёт создания экземпляров классов используя RTTI (информацию о типах времени выполнения). Spring контролирует создание, но при этом, оставляет программисту возможность управлять жизненным циклом объектов.
Я также держу пари, что не все из вас готовы положиться на магию. Несмотря на то, что передача управления хорошо работает во многих случаях, вы можете захотеть не отдавать контроль над созданием объектов во всех случаях.
Хорошая новость здесь в том, что вам и не придётся. Фреймворк, при желании, позволяет управлять созданием объектов. В большинстве случаев если классы хорошо спроектированы, то их конструкторы просты, и в них не происходит ничего, кроме присвоения значений. Но иногда возникает нужда сделать при создании объекта что-то особенное. Иногда, классу требуется динамический параметр – объект, чьё состояние будет известно только при выполнении. (Примечание переводчика: мне очень не нравится слово динамический в этом контексте и примеры Ника, но я не придумал лучшего объяснения. Есть идеи, читатель? Пиши в комментарии!) Например, у нас может быть класс Клиент, и у этого Клиента могут быть Счета. И у нас есть класс, который мы хотим передать этому клиенту, но при этом мы не хотим связывать эти классы. Наш Клиент динамический – мы можем запускать запрос и выполнять эту операцию на каждом клиенте в нашей базе данных. Или Клиент может что-то делать на нашем сайте, и таким образом наш объект Клиента будет относиться именно к этому конкретному клиенту. В любом случае, данные нашего Клиента динамичны во время выполнения, и поэтому мы не можем загнать создание объекта в жёсткие рамки. Он должен быть уникальным, каждый раз, когда нам нужен экземпляр объекта, который выполняет действие над данным клиентом.
Читать дальше..
