Комментарии 10
Что может быть обязательной зависимостью и необязательной, примеры? Можно несколько примеров, если не сложно.
0
«Необязательные зависимости» довольно часто свидетельствуют о нарушении SRP и приводят к NRE. Так что лучше без них.
0
Почему? Приведите пример.
0
Как гарантировать, что вызов
DoSomething
из вашего примера произойдет после того как Dependency
будет установлен?0
Можно было бы дать ссылки на посты Сергея Теплякова, откуда текст перекочевал целыми абзацами:
sergeyteplyakov.blogspot.com/2013/01/di-property-injection.html
sergeyteplyakov.blogspot.com/2012/12/di-constructor-injection.html
sergeyteplyakov.blogspot.com/2013/01/di-property-injection.html
sergeyteplyakov.blogspot.com/2012/12/di-constructor-injection.html
0
В property injection:
Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.
По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.
Трудность возникает, если клиентам будет позволено менять значение зависимости в течение жизненного цикла класса.Вы запретили клиентам вызывать сеттер более одного раза, но между вызовом конструктора и вызовом сеттера есть промежуток времени, в течении которого значения будет «изменено» со значения по умолчанию на новое. Особенно мне не нравится установка дефолтового значения в геттере. Почему яно не использовать Lazy?
Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.
По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.
придется либо делать свойство только для записи (set-only property), что противоречит общепринятым принципам проектирования на платформе .NETКаким таким «общепринятым» принципам? Есть guidelines, где написано "X DO NOT provide set-only properties"
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны внедрения зависимостей. Часть 1