Здравствуйте, RusDady, Вы писали:

RD>Dependency Injection
RD>В каких случаях обосновано реальное/практическое использование патерна?
Нормальное использование — когда ты хочешь сделать сервисно-ориентированную архитектуру в программе.
SOA от классического ООП отличается:
1) Отсутствием "экземпляров" объектов. Каждый сервис существует в "единственном" экземпляре и всегда доступен по (типу, имени).
2) Управление временем жизни находится вне сервисов.
3) Отсутствием рекурсивной композиции — как следствие 1 и 2.

Эти ограничения упрощают проектирование, но делают код более запутанным.


Когда не стоит использовать DI:
1) Когда хочешь покрыть программу юнит-тестами
2) Когда ты пишешь сложную программу и считаешь, что DI поможет в борьбе со сложностью

RD>И как это использование выглядит?
Вот так — http://blog.gandjustas.ru/2009/01/19/ioc/

Здравствуйте, gandjustas, Вы писали:


G>Когда не стоит использовать DI:
G>1) Когда хочешь покрыть программу юнит-тестами

кгм, это юмор такой специфический?

Здравствуйте, Sinix, Вы писали:

S>Там ещё несколько граблей впереди поджидает, чтоб не портить интригу — просто изучите как ETW/EventSource работают. Иначе вы всё равно это изучите, только сложным способом

А можно еще взять Statsify и рисовать графики.

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>Когда не стоит использовать DI:
G>>1) Когда хочешь покрыть программу юнит-тестами

I>кгм, это юмор такой специфический?

Жестокая правда жизни DI впендюривают объясняя мечтами о юнит тестах. До юнит тестов руки как правило так и не доходят, а типичная реализация архитектуры типа "спагетти-код" существенно усложняется инвалидным использованием псевдо-плагинов и интейфейсным оверхедом.

Так что... как говорил ув. Кент Бек — сначала тесты, потом код. Нет тестов — значит DI для тестов не нужен.

Здравствуйте, IQuerist, Вы писали:

G>>>Когда не стоит использовать DI:
G>>>1) Когда хочешь покрыть программу юнит-тестами

I>>кгм, это юмор такой специфический?

IQ>Жестокая правда жизни DI впендюривают объясняя мечтами о юнит тестах. До юнит тестов руки как правило так и не доходят, а типичная реализация архитектуры типа "спагетти-код" существенно усложняется инвалидным использованием псевдо-плагинов и интейфейсным оверхедом.
Правда жизни у каждого своя. Вот я например организовал такую: нет юнит тестов — нет мержа в мастер.

Здравствуйте, IQuerist, Вы писали:

IQ>Здравствуйте, itslave, Вы писали:

I>>Здравствуйте, gandjustas, Вы писали:


G>>>Когда не стоит использовать DI:
G>>>1) Когда хочешь покрыть программу юнит-тестами

I>>кгм, это юмор такой специфический?

IQ>Жестокая правда жизни DI впендюривают объясняя мечтами о юнит тестах. До юнит тестов руки как правило так и не доходят, а типичная реализация архитектуры типа "спагетти-код" существенно усложняется инвалидным использованием псевдо-плагинов и интейфейсным оверхедом.

IQ>Так что... как говорил ув. Кент Бек — сначала тесты, потом код. Нет тестов — значит DI для тестов не нужен.

Гы. Тенденция: "если не умею делать, значит работа дурацкая" не знаю паттерн значит идиотский паттерн. и так на все перенести...

Здравствуйте, another_coder, Вы писали:

IQ>>Так что... как говорил ув. Кент Бек — сначала тесты, потом код. Нет тестов — значит DI для тестов не нужен.

_>Гы. Тенденция: "если не умею делать, значит работа дурацкая" не знаю паттерн значит идиотский паттерн. и так на все перенести...

Я вижу другую тенденцию — не иметь представления о контексте применимости паттернов эдакий повсеместный паттерн-фетишизм. Особенно забавно это выглядит на фоне набитых бизнес правилами sql скриптов и клиентского javascript.

Здравствуйте, itslave, Вы писали:

IQ>>Жестокая правда жизни DI впендюривают объясняя мечтами о юнит тестах. До юнит тестов руки как правило так и не доходят, а типичная реализация архитектуры типа "спагетти-код" существенно усложняется инвалидным использованием псевдо-плагинов и интейфейсным оверхедом.
I>Правда жизни у каждого своя. Вот я например организовал такую: нет юнит тестов — нет мержа в мастер.

Без упоминания о критериях покрытия звучит довольно странно.

Здравствуйте, IQuerist, Вы писали:

IQ>Я вижу другую тенденцию — не иметь представления о контексте применимости паттернов эдакий повсеместный паттерн-фетишизм. Особенно забавно это выглядит на фоне набитых бизнес правилами sql скриптов и клиентского javascript.

javascript отлично покрывается юнит тестами
а за логику в sql скриптах без веских причин надо руки откручивать.

Здравствуйте, IQuerist, Вы писали:

IQ>Здравствуйте, itslave, Вы писали:

IQ>>>Жестокая правда жизни DI впендюривают объясняя мечтами о юнит тестах. До юнит тестов руки как правило так и не доходят, а типичная реализация архитектуры типа "спагетти-код" существенно усложняется инвалидным использованием псевдо-плагинов и интейфейсным оверхедом.
I>>Правда жизни у каждого своя. Вот я например организовал такую: нет юнит тестов — нет мержа в мастер.

IQ>Без упоминания о критериях покрытия звучит довольно странно.
новый код — 100% бизнес логики. Легаси — покрыть то что менялось + еще немного на мое усмотрение.