Pull to refresh

Comments 10

Что может быть обязательной зависимостью и необязательной, примеры? Можно несколько примеров, если не сложно.

Например, для PersonService обязательно зависимостью может быть IPersonRepository, а для PersonRepository — IDbContext.


Для некоторой сущности необязательной зависимостью может быть Style, а при отсутствии значения будет использоваться Container.Style.

«Необязательные зависимости» довольно часто свидетельствуют о нарушении SRP и приводят к NRE. Так что лучше без них.
Почему? Приведите пример.
Как гарантировать, что вызов DoSomething из вашего примера произойдет после того как Dependency будет установлен?
Зачем я должен это гарантировать? Если я пробрасываю зависимость через свойство, то я тем самым говорю «Есть поведение и вы можете менять его в любой момент». Яркий пример — зазоры для тестирования. Вы же не хотите передавать все параметры включая NowTimeLocator, ThreadSleeper, итд каждый раз.
В property injection:
Трудность возникает, если клиентам будет позволено менять значение зависимости в течение жизненного цикла класса.
Вы запретили клиентам вызывать сеттер более одного раза, но между вызовом конструктора и вызовом сеттера есть промежуток времени, в течении которого значения будет «изменено» со значения по умолчанию на новое. Особенно мне не нравится установка дефолтового значения в геттере. Почему яно не использовать Lazy?

Property-injection используется для необязательной зависимости и в зависимости от того, что делает дефолтовая реализация, может даже имеет смысл делать null-проверки в коде локально, каждый раз при обращении к экземпляру. Всегда имплементировать реализацию, которая «ничего не делает» — как-то накладно.

По-моему лучше необязательную injection делать через оверлоад конструктора, для property-injection требуется, чтобы зависимость обладала «некими» специфическими свойствами, к примеру, чтобы уже существовала дефолтовая имплементация, которая позволит избежать спагетти-кода из-за null-проверок.
придется либо делать свойство только для записи (set-only property), что противоречит общепринятым принципам проектирования на платформе .NET
Каким таким «общепринятым» принципам? Есть guidelines, где написано "X DO NOT provide set-only properties"
Only those users with full accounts are able to leave comments. Log in, please.