Здравствуйте, ·, Вы писали:
IQ>>>>Компилятор гарантирует? Мне казалось DI работает исключительно в динамике. IQ>>·>Если кажется — крестись, или хотя бы учебники читай. Я же уже ссылку давал на вики, читал? Где там динамика? IQ>>Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты??? ·>Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта, и защищает доступ к приватным полям классов, не давая доступ к зависимостям, которых у тебя не предусмотрено. Тем самым в рантайме обеспечивает гарантию.
Вероятно вы начинали с javascript...
IQ>>·>Это далеко не единственный ответ. IQ>>Имхо единственный, остальное — отмазы. ·>Самый главный ответ — альтернативы DI+CI хуже по многим критериям.
да никто не обещал что будет хорошо говорили — будет еще лучше
IQ>>·>Какой конкретный вариант? Забудь множественные имплементации, не в них дело. Дело в том, что "конкретный вариант" тоже откуда-то должен взяться, у него можеть быть специфичный lifespan и у него могут быть свои зависимости. IQ>>А вот это отличный ответ... проясняет почему разговор идет именно о сервисах. Спасибо. Конечно остается вопрос — почему в виденом мною коде где использовался DI ничего из этого не использовалось... Это конечно не к вам претензия, а к "мейнстриму". ·>Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал.
Ну кто-то же должен, раз все остальные стыдливо молчат
·>Вместо того чтобы внести ясность, поделиться как же делать правильно, дискредитируешь хорошие техники всякими уничижительными словечками типа Colonoscopy Injection.
Поверьте код из за которого написан пост этого стоит. Однако как правильно вы тоже так и не сформулировали
·>И так тут сплошное невежество в "мейнстриме", а ты только усугубляешь.
Складывается у меня стойкое ощущение, что это тот "мейнстрим" порожден невежеством... (это я не на вас намекаю)
Re[22]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>>>>>·>Короче, stateless и static — совершенно независимые непересекающиеся понятия. IQ>>>>>Обратного я и не утверждал IQ>>>·>И как твой ServiceLocator.GetCurrentUserInfo согласуется с твоей любовью к stateless? IQ>>>Нда... а у меня оказывается не вульгарный ServiceLocator, а кошерный Ambient Context... IQ>·>Оппа. Класс называется ServiceLocator, но это не Service Locator. Клёво чё, жоб секьюрити себе обеспечиваешь? IQ>Честно нет... я искренне не ожидал, что одинаковые вещи могут по разному называться и по разному оцениваться. Для меня это честно было сюрпризом. Но в мутной теме обязаны быть грязные хаки надо лишь поискать.
Ничего не понял. Тема не мутная, похоже муть у тебя в голове. ServiceLocator и Ambient Context вещи не одинаковые, вообще ничего общего.
Ambient Context это хипстерская обёртка для обеспечения более вменяемого использования глобальных переменных.
А Service Locator это фактически такая мапа [serviceId -> serviceImplementation], называемая Registry. Притом сама мапа может протягиваться как через те же глобальные переменные (и даже с использованием Ambient Context), через DI, тупо через арументы метода или ещё как.
IQ>·>Но не важно. Контекст — это состояние. На вопросик-то ответь. IQ>Состояние у бизнес-операции. Ее обработка создает все нужные контексты и раздает используемым модулям.
Причём тут бизнес-операция? Это вообще не в тему. Смотрим что ты написал:
"и с десяток совершенно очевидных хелперных stateless методов типа: GetBoringItemById". Вот как такой метод может быть stateless? Как мне доводилось видеть, сигнатура такого метода типично public BoringItem GetBoringItemById(long id)
или у тебя другие варианты?
Покажи как ты видишь этот метод сделать stateless. Ему как минимум нужен borrowed DbConnection и активный TransactionContext, а ещё, бывает, какой-нибудь security context и audit recorder.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>>>Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты??? IQ>·>Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта, и защищает доступ к приватным полям классов, не давая доступ к зависимостям, которых у тебя не предусмотрено. Тем самым в рантайме обеспечивает гарантию. IQ>Вероятно вы начинали с javascript...
Я начинал с С++, а javascript был в новинку и его обычно отключали в браузере.
А к чему это всё?
IQ>·>Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал. IQ>Ну кто-то же должен, раз все остальные стыдливо молчат
Критиковать — пожалуйста, но критикуя — предлагай, неконструктивная критика только увеличивает невежество.
IQ>·>Вместо того чтобы внести ясность, поделиться как же делать правильно, дискредитируешь хорошие техники всякими уничижительными словечками типа Colonoscopy Injection. IQ>Поверьте код из за которого написан пост этого стоит. Однако как правильно вы тоже так и не сформулировали
Как не сформулировал? Перечитай внимательно топик.
Подытожу: "По умолчанию используйте DI+CI везде где возможно, а где невозможно — делайте рефакторинг, чтобы стало возможно".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IQuerist, Вы писали:
IQ>Мое имхо по итогам обсуждения поста: IQ>Ребята это секта...
Тебя уже два месяца просят раскрыть им глаза и показать как же надо, но гуру так и не снизошол
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[23]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>>>>>·>Короче, stateless и static — совершенно независимые непересекающиеся понятия. IQ>>>>>>Обратного я и не утверждал IQ>>>>·>И как твой ServiceLocator.GetCurrentUserInfo согласуется с твоей любовью к stateless? IQ>>>>Нда... а у меня оказывается не вульгарный ServiceLocator, а кошерный Ambient Context... IQ>>·>Оппа. Класс называется ServiceLocator, но это не Service Locator. Клёво чё, жоб секьюрити себе обеспечиваешь? IQ>>Честно нет... я искренне не ожидал, что одинаковые вещи могут по разному называться и по разному оцениваться. Для меня это честно было сюрпризом. Но в мутной теме обязаны быть грязные хаки надо лишь поискать. ·>Ничего не понял. Тема не мутная, похоже муть у тебя в голове. ServiceLocator и Ambient Context вещи не одинаковые, вообще ничего общего. ·>Ambient Context это хипстерская обёртка для обеспечения более вменяемого использования глобальных переменных. ·>А Service Locator это фактически такая мапа [serviceId -> serviceImplementation], называемая Registry. Притом сама мапа может протягиваться как через те же глобальные переменные (и даже с использованием Ambient Context), через DI, тупо через арументы метода или ещё как.
Ambient Context сходный по структуре с анти-паттерном Service Locator, который я опишу в главе 5. Разница состоит в том, что Ambient Context предоставляет экземпляр только одной, строго типизированной зависимости, в то время как Service Locator предположительно должен обеспечить экземпляры для каждой зависимости, которую вы можете запросить. Различия являются тонкими, так что убедитесь, что вы полностью понимаете, когда следует применять Ambient Context, прежде чем сделать это. Если вы сомневаетесь, выберите другой DI паттерн.
Хипстер — Марк Симан
Кстати там же про Thread Local Storage и HttpContext
IQ>>·>Но не важно. Контекст — это состояние. На вопросик-то ответь. IQ>>Состояние у бизнес-операции. Ее обработка создает все нужные контексты и раздает используемым модулям. ·>Причём тут бизнес-операция? Это вообще не в тему. Смотрим что ты написал: ·>"и с десяток совершенно очевидных хелперных stateless методов типа: GetBoringItemById". Вот как такой метод может быть stateless? Как мне доводилось видеть, сигнатура такого метода типично ·>public BoringItem GetBoringItemById(long id) ·>или у тебя другие варианты? ·>Покажи как ты видишь этот метод сделать stateless. Ему как минимум нужен borrowed DbConnection и активный TransactionContext, а ещё, бывает, какой-нибудь security context и audit recorder.
GetBoringItemById не имеет состояния, состояние "DbConnection и активный TransactionContext" предоставляются ему внешними сервисами. Да в моем случае этот сервис глобальный (как и loggingContext). Ваш пример конечно интересен, хотя на мой взгляд никаких явных TransactionContext, security context и audit recorder и т.д. в DAL быть не должно — не тот уровень абстракции Они все же должны быть в высокоуровневом сервисе и это имхо очевидный маркер того, что в случае GetBoringItemById DI используется неверно.
Re[27]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>>>Нда... а вы вообще программированием занимаетесь? "то ты смело можешь использовать любые его методы, т.к. объект уже сконструирован, компилятор гарантирует" компилятор по вашему конструирует объекты??? IQ>>·>Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта, и защищает доступ к приватным полям классов, не давая доступ к зависимостям, которых у тебя не предусмотрено. Тем самым в рантайме обеспечивает гарантию. IQ>>Вероятно вы начинали с javascript... ·>Я начинал с С++, а javascript был в новинку и его обычно отключали в браузере. ·>А к чему это всё?
Это ужосъ ))) "Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта" как такое может говорить C++ программер? А ведь я в последний раз кодил на C++ 14 лет назад.
IQ>>·>Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал. IQ>>Ну кто-то же должен, раз все остальные стыдливо молчат ·>Критиковать — пожалуйста, но критикуя — предлагай, неконструктивная критика только увеличивает невежество.
Дружища, здесь не запукинский митинг. Вы предлагаете задавать вопрос только когда известен ответ? Но базовый ответ известен всем и всегда — "контрагент идиот не желает признавать очевидного" Вспоминайте об этом каждый раз когда повторяете глупость — "критикуя — предлагай".
IQ>>·>Вместо того чтобы внести ясность, поделиться как же делать правильно, дискредитируешь хорошие техники всякими уничижительными словечками типа Colonoscopy Injection. IQ>>Поверьте код из за которого написан пост этого стоит. Однако как правильно вы тоже так и не сформулировали ·>Как не сформулировал? Перечитай внимательно топик. ·>Подытожу: "По умолчанию используйте DI+CI везде где возможно, а где невозможно — делайте рефакторинг, чтобы стало возможно".
Здравствуйте, Dziman, Вы писали:
D>Здравствуйте, IQuerist, Вы писали:
IQ>>Мое имхо по итогам обсуждения поста: IQ>>Ребята это секта... D>Тебя уже два месяца просят раскрыть им глаза и показать как же надо, но гуру так и не снизошол
А вы пост-то вообще читали? Смысл поста — обозначить очевидную проблему. В результате обсуждения, "адепты DI" наличие описанной в посте проблемы признавать отказались. Нет никакой проблемы, пишите как писали и не замарачивайтесь.
Re[24]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>>>Честно нет... я искренне не ожидал, что одинаковые вещи могут по разному называться и по разному оцениваться. Для меня это честно было сюрпризом. Но в мутной теме обязаны быть грязные хаки надо лишь поискать. IQ>·>Ничего не понял. Тема не мутная, похоже муть у тебя в голове. ServiceLocator и Ambient Context вещи не одинаковые, вообще ничего общего. IQ>·>Ambient Context это хипстерская обёртка для обеспечения более вменяемого использования глобальных переменных. IQ>·>А Service Locator это фактически такая мапа [serviceId -> serviceImplementation], называемая Registry. Притом сама мапа может протягиваться как через те же глобальные переменные (и даже с использованием Ambient Context), через DI, тупо через арументы метода или ещё как.
IQ>Читаем талмудъ: IQ>https://smarly.net/dependency-injection-in-net/di-catalog/di-patterns/ambient-context
IQ>
IQ>Ambient Context сходный по структуре с анти-паттерном Service Locator,
Выражения "Сходный по структуре" и "одинаковые вещи" — не одинаковые вещи, и даже не сходны по структуре. Сходность по структуре не означает, что можно ambient context в коде называть как service locator.
Почему для тебя это сюрприз — я до сих пор не понимаю. Ведь даже в этом талмуде это по-разному оценивается: Service Locator записали в анти-паттерн, а Ambient Context как паттерн.
IQ>Кстати там же про Thread Local Storage и HttpContext
А ещё там написано "Ambient Context должен быть использован только в редчайших случаях". А ты предлагаешь это как дефолтное решение.
У меня был опыт, что даже приведённый в этом талмуде пример с TimeProvider как глобальня переменная (или ambient context, что почти то же самое) дал сбой. У нас в приложении оказалось нужно два вида часов — физические для текущего запуска и логические, определяемые проигрыванием исторических событий из лога и для реализации "машины времени", применяемой для системного тестирования (а как ещё протестировать, например, что некий отчёт создаётся по пятницам?). Поэтому нам пришлось дружно заменять по всему коду статики на DI+CI.
IQ>·>Причём тут бизнес-операция? Это вообще не в тему. Смотрим что ты написал: IQ>·>"и с десяток совершенно очевидных хелперных stateless методов типа: GetBoringItemById". Вот как такой метод может быть stateless? Как мне доводилось видеть, сигнатура такого метода типично IQ>·>public BoringItem GetBoringItemById(long id) IQ>·>или у тебя другие варианты? IQ>·>Покажи как ты видишь этот метод сделать stateless. Ему как минимум нужен borrowed DbConnection и активный TransactionContext, а ещё, бывает, какой-нибудь security context и audit recorder. IQ>GetBoringItemById не имеет состояния, состояние "DbConnection и активный TransactionContext" предоставляются ему внешними сервисами.
Они ему не предоставляются, а он их сам находит. Если бы сигнатура была public BoringItem GetBoringItemById(long id, DbConnection db, TransactionContext tx) — вот это stateless.
Иначе у тебя получается, что любая функция на C — stateless, т.к. классов нет, все функции "статические".
IQ>Да в моем случае этот сервис глобальный (как и loggingContext). Ваш пример конечно интересен, хотя на мой взгляд никаких явных TransactionContext, security context и audit recorder и т.д. в DAL быть не должно — не тот уровень абстракции Они все же должны быть в высокоуровневом сервисе и это имхо очевидный маркер того, что в случае GetBoringItemById DI используется неверно.
Это просто самые очевидные и понятные примеры, не придирайся к конкретным названиям. Суть в том, что такие зависимости или что-то подобное может появиться когда-то и "We still get no help if we need to add a new dependency: is it a breaking change or not?".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>Это ужосъ ))) "Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта" как такое может говорить C++ программер? А ведь я в последний раз кодил на C++ 14 лет назад.
Сейчас я Java-програмер. У тебя есть что по существу возразить или так и будешь прикапываться к личности собеседника?
IQ>>>·>Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал. IQ>>>Ну кто-то же должен, раз все остальные стыдливо молчат IQ>·>Критиковать — пожалуйста, но критикуя — предлагай, неконструктивная критика только увеличивает невежество. IQ> Дружища, здесь не запукинский митинг. Вы предлагаете задавать вопрос только когда известен ответ? Но базовый ответ известен всем и всегда — "контрагент идиот не желает признавать очевидного" Вспоминайте об этом каждый раз когда повторяете глупость — "критикуя — предлагай".
Я что-то пропустил, ты разве задавал какие-то вопросы? По-моему просто поворчал, пожаловался на жизнь и участие в говнопроектах.
IQ>·>Как не сформулировал? Перечитай внимательно топик. IQ>·>Подытожу: "По умолчанию используйте DI+CI везде где возможно, а где невозможно — делайте рефакторинг, чтобы стало возможно". IQ>Таки да, это секта...
Таки да, упёртый невежда, смотрит в книгу видит фигу. В конце концов, почитай хотя бы приведённый тобой же талмуд:
Внедрение в конструктор должно быть вашим выбором по умолчанию для DI.
Почти дословно мой вывод.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, #John, Вы писали:
J>·>Почему редко такой код встречается?.. J>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers, J>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.). J>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
Оказывается это называется Constructor Over-injection
тут вот разжевано с примерами: https://smarly.net/dependency-injection-in-net/di-catalog/di-refactorings/dealing-with-constructor-over-injection
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>Это ужосъ ))) "Компилятор проверяет, что вызов конструктора выполнен с правильными аргументами, обеспечивает невозможность обратиться к методам несконструированного объекта" как такое может говорить C++ программер? А ведь я в последний раз кодил на C++ 14 лет назад. ·>Сейчас я Java-програмер. У тебя есть что по существу возразить или так и будешь прикапываться к личности собеседника?
К личности — не буду, вы вполне симпатичны
IQ>>>>·>Собственно моя претензия в том, что ты лишь на основании своего негативного опыта с говнопроектами в одну кучу всё свалил и раскритиковал. IQ>>>>Ну кто-то же должен, раз все остальные стыдливо молчат IQ>>·>Критиковать — пожалуйста, но критикуя — предлагай, неконструктивная критика только увеличивает невежество. IQ>> Дружища, здесь не запукинский митинг. Вы предлагаете задавать вопрос только когда известен ответ? Но базовый ответ известен всем и всегда — "контрагент идиот не желает признавать очевидного" Вспоминайте об этом каждый раз когда повторяете глупость — "критикуя — предлагай". ·>Я что-то пропустил, ты разве задавал какие-то вопросы? По-моему просто поворчал, пожаловался на жизнь и участие в говнопроектах.
А должен был поднять зеленое знамя с надпись — будем за такое руки отрубать?
IQ>>·>Как не сформулировал? Перечитай внимательно топик. IQ>>·>Подытожу: "По умолчанию используйте DI+CI везде где возможно, а где невозможно — делайте рефакторинг, чтобы стало возможно". IQ>>Таки да, это секта... ·>Таки да, упёртый невежда, смотрит в книгу видит фигу. В конце концов, почитай хотя бы приведённый тобой же талмуд:
Вот нету у меня понимания примеров полезности DI. Все предлагают какой-то академический мусор за который в реальном проекте лупят ссаными тряпками. Да я сам похожий мусор когда-то плодил и довольно быстро увидел минусы. Плюсов пока разглядеть не получается, конечно я признаю, что повышение абстрактности кода потенциально полезно, но не понимаю — для чего, хотя я допускаю, что в некоторых проектах (которых я не видел) это может быть очень важно.
Пеар buzz на меня не действует.
·>
Внедрение в конструктор должно быть вашим выбором по умолчанию для DI.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #John, Вы писали:
J>>·>Почему редко такой код встречается?.. J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers, J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.). J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами? ·>Оказывается это называется Constructor Over-injection ·>тут вот разжевано с примерами: https://smarly.net/dependency-injection-in-net/di-catalog/di-refactorings/dealing-with-constructor-over-injection
Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы. Может это дело потенциально полезное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.
Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, а искать ее приходится как правило по интерфейсу.
Здравствуйте, IQuerist, Вы писали:
IQ>·>Сейчас я Java-програмер. У тебя есть что по существу возразить или так и будешь прикапываться к личности собеседника? IQ>К личности — не буду, вы вполне симпатичны
Вместо того, чтобы сказать что не так в моих словах, к чему тогда вопросы о моём знании С++ и js?
IQ>·>Я что-то пропустил, ты разве задавал какие-то вопросы? По-моему просто поворчал, пожаловался на жизнь и участие в говнопроектах. IQ>А должен был поднять зеленое знамя с надпись — будем за такое руки отрубать?
Это тоже не конструктивно.
IQ>>>Таки да, это секта... IQ>·>Таки да, упёртый невежда, смотрит в книгу видит фигу. В конце концов, почитай хотя бы приведённый тобой же талмуд: IQ>Вот нету у меня понимания примеров полезности DI. Все предлагают какой-то академический мусор за который в реальном проекте лупят ссаными тряпками. Да я сам похожий мусор когда-то плодил и довольно быстро увидел минусы. Плюсов пока разглядеть не получается, конечно я признаю, что повышение абстрактности кода потенциально полезно, но не понимаю — для чего, хотя я допускаю, что в некоторых проектах (которых я не видел) это может быть очень важно.
Ага, понимания нет, но используешь что попалось под руку. На каком основании ты именно ambient context выбрал? Почему? Привычнее? Выбираешь сердцем?
IQ>Пеар buzz на меня не действует.
Ты даже чайнико-адаптированную книгу привёл с разжевыванием и примерами что и как делается, почему так делается и чем это грозит. Причём тут баззворды?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>·>Оказывается это называется Constructor Over-injection IQ>·>тут вот разжевано с примерами: https://smarly.net/dependency-injection-in-net/di-catalog/di-refactorings/dealing-with-constructor-over-injection
IQ>Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы.
Надо понимать, что вот это вся интерфейсизация рассказывает о решениях в больших многомодульных проектах, которые пишутся разными командами и т.п. Однако, если с умом такие вещи использовать даже в hello-world приложении, то можно писать расширяемый при необходимости код.
Тот же ненависный твой аргумент про юнит-тесты. Даже если юнит-тестов нет и не предвидится, то писать легко покрываемый тестами код не сложнее, чем говнокодить макароны, просто нужно разобраться и понимать что как можно делать и чем это грозит.
IQ>Может это дело потенциально полезное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни.
У меня был опыт с такими конструкторами. Рекорд толи 37 толи 47 параметров было, я не помню. И знаешь — это был вариант лучше остальных мною виденных. Была уверенность — если что-то не так сделаю — код просто не сможет скомпилиться, а не грохнется в проде ВНЕЗАПНО.
IQ>А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами. IQ>Да... метод наименьшего сопротивления.
Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается. Это лишь такой явный индикатор того, что вот эта часть приложения плохо продумана, были дед-лайны и всё такое, что туда нужно вложить ещё сколько-то времени.
IQ>Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
Воплощение должно быть таким, чтобы код был всё ещё понимаемым и легко при желании изменяемым. Явные зависимости этому делу хорошо способствуют.
IQ>PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию,
Вот уж это совсем не проблема. Рефакторинг rename method/class — занимает около 1 минуты, включая коммит+пуш.
IQ>а искать ее приходится как правило по интерфейсу.
Открой для себя рефакторинг inline interface.
Ты считаешь это проблемой потому что у тебя плохое качество кода и абсолютно любое его изменение — страшно, ты не понимаешь что где может поломаться. Это звоночек.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
IQ>>>>Таки да, это секта... IQ>>·>Таки да, упёртый невежда, смотрит в книгу видит фигу. В конце концов, почитай хотя бы приведённый тобой же талмуд: IQ>>Вот нету у меня понимания примеров полезности DI. Все предлагают какой-то академический мусор за который в реальном проекте лупят ссаными тряпками. Да я сам похожий мусор когда-то плодил и довольно быстро увидел минусы. Плюсов пока разглядеть не получается, конечно я признаю, что повышение абстрактности кода потенциально полезно, но не понимаю — для чего, хотя я допускаю, что в некоторых проектах (которых я не видел) это может быть очень важно. ·>Ага, понимания нет, но используешь что попалось под руку. На каком основании ты именно ambient context выбрал? Почему? Привычнее? Выбираешь сердцем?
Я его не выбирал я использую решение 12 летней давности. Просто ambient context более подходит по описанию.
IQ>>Пеар buzz на меня не действует. ·>Ты даже чайнико-адаптированную книгу привёл с разжевыванием и примерами что и как делается, почему так делается и чем это грозит. Причём тут баззворды?
При том, что на мой взгляд, "как надо" эти техники использоваться не будут...
Здравствуйте, ·, Вы писали:
IQ>>Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы. ·>Надо понимать, что вот это вся интерфейсизация рассказывает о решениях в больших многомодульных проектах, которые пишутся разными командами и т.п.
Не надо рассказывать о "больших многомодульных проектах" в топиках где обсуждают малые проекты плохого качества. Стартуйте свой топик о "больших многомодульных проектах" и мне, там стыдно будет предлагать вам не использовать DI. Но в этом топике разговор о другом.
IQ>>Может это дело потенциально полезное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни. ·>У меня был опыт с такими конструкторами. Рекорд толи 37 толи 47 параметров было, я не помню. И знаешь — это был вариант лучше остальных мною виденных. Была уверенность — если что-то не так сделаю — код просто не сможет скомпилиться, а не грохнется в проде ВНЕЗАПНО.
Совсем не понятно откуда такая уверенность.
IQ>>А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами. IQ>>Да... метод наименьшего сопротивления. ·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.
Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
IQ>>Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное. ·>Воплощение должно быть таким, чтобы код был всё ещё понимаемым и легко при желании изменяемым. Явные зависимости этому делу хорошо способствуют.
Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
IQ>>PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, ·>Вот уж это совсем не проблема. Рефакторинг rename method/class — занимает около 1 минуты, включая коммит+пуш.
Шпасиба друг! А я и не знал, что "Рефакторинг rename method/class" поможет придумать грамотные, понятные и верные названия для сервисов.
IQ>>а искать ее приходится как правило по интерфейсу. ·>Открой для себя рефакторинг inline interface.
·>Ты считаешь это проблемой потому что у тебя плохое качество кода и абсолютно любое его изменение — страшно, ты не понимаешь что где может поломаться. Это звоночек.
Лично у меня, я считаю, приемлемое качество кода, потому что бизнес логика моих систем активно расширяется многие годы без рисков того, что проект деградирует настолько, что единственным верным решением будет — переписать его с нуля. Это обеспечивается всего лишь грамотной декомпозицией.
Re[13]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>>>Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы. IQ>·>Надо понимать, что вот это вся интерфейсизация рассказывает о решениях в больших многомодульных проектах, которые пишутся разными командами и т.п. IQ>Не надо рассказывать о "больших многомодульных проектах" в топиках где обсуждают малые проекты плохого качества. Стартуйте свой топик о "больших многомодульных проектах" и мне, там стыдно будет предлагать вам не использовать DI. Но в этом топике разговор о другом.
Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>·>У меня был опыт с такими конструкторами. Рекорд толи 37 толи 47 параметров было, я не помню. И знаешь — это был вариант лучше остальных мною виденных. Была уверенность — если что-то не так сделаю — код просто не сможет скомпилиться, а не грохнется в проде ВНЕЗАПНО. IQ>Совсем не понятно откуда такая уверенность.
Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.
IQ>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается. IQ>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные. В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное. IQ>·>Воплощение должно быть таким, чтобы код был всё ещё понимаемым и легко при желании изменяемым. Явные зависимости этому делу хорошо способствуют. IQ>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.
IQ>>>PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, IQ>·>Вот уж это совсем не проблема. Рефакторинг rename method/class — занимает около 1 минуты, включая коммит+пуш. IQ>Шпасиба друг! А я и не знал, что "Рефакторинг rename method/class" поможет придумать грамотные, понятные и верные названия для сервисов.
Конечно помогает. Как только придумаешь — зафиксируешь это в коде. Если не придумаешь сразу — придумай хоть что-нибудь и запиши как кажется на текущий момент, отливать в граните ничего не надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>>>Вот нету у меня понимания примеров полезности DI. Все предлагают какой-то академический мусор за который в реальном проекте лупят ссаными тряпками. Да я сам похожий мусор когда-то плодил и довольно быстро увидел минусы. Плюсов пока разглядеть не получается, конечно я признаю, что повышение абстрактности кода потенциально полезно, но не понимаю — для чего, хотя я допускаю, что в некоторых проектах (которых я не видел) это может быть очень важно. IQ>·>Ага, понимания нет, но используешь что попалось под руку. На каком основании ты именно ambient context выбрал? Почему? Привычнее? Выбираешь сердцем? IQ>Я его не выбирал я использую решение 12 летней давности. Просто ambient context более подходит по описанию.
Повезло, что проект сильно не развивается 12 лет.
IQ>>>Пеар buzz на меня не действует. IQ>·>Ты даже чайнико-адаптированную книгу привёл с разжевыванием и примерами что и как делается, почему так делается и чем это грозит. Причём тут баззворды? IQ>При том, что на мой взгляд, "как надо" эти техники использоваться не будут...
Up to you. Причём тут техники?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, IQuerist, Вы писали:
IQ>Забавный ответ от uncle Bob IQ>https://youtu.be/Nltqi7ODZTM?t=2025 IQ>Я признаться был готов перестать его уважать, но после этого видео зауважал еще больше. Рекомендую смотреть сначала мне очень понравилось.
Он говорит о Dependency Injection Framework (ака IoC-container), то же самое, что я и писал в этом топике
да никто не обещал что будет хорошо 
Но базовый ответ известен всем и всегда 
