Re[6]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.13 16:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Как по-твоему где больше зависимостей?


Без вызывающего кода сложно сказать.

Вот вызывающй код для первого случая
  var instance = new PrimitiveClass();

  instance.MyVeryPrimitiveMethod();



Вот для второго:
  var instance = new PrimitiveClass();

 _service3.SetResult(instance.MyVeryPrimitiveMethod(_service1.GetValue1(), _service2.GetValue2()));


Где меньше зависимостей ?
Re[21]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 16.10.13 18:29
Оценка:
Здравствуйте, Doc, Вы писали:

IT>>Кто тебе вообще сказал, что сервис должен быть изначально?

Doc>Ага, т.е. сервис в том примере вообще лишний?

В каком примере?

IT>>Не надо путать божий дар с яичницей. Или тебе ообъяснить разницу между System.String и GetcustomerByID?

Doc>Если GetcustomerByID проходит unit test — мне без разницы что внутри, до того момента, как будут основания это проверить.

Понятно. Разницы между библиотечной функцией общего назначения и логикой бизнес-приложения для тебя не существует.

Doc>Во, начни с себя и завязывай раздавать диагнозы


Опять начался детский сад. Судя по нашему предыдущему общению дальнейшая дискуссия с тобой начинает тепять всякий смысл. Пока.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 16.10.13 18:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Где меньше зависимостей ?


Здесь:

  var n = MyVeryPrimitiveMethod(1, 2);
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: своё vs. сторонее
От: Dziman США http://github.com/Dziman
Дата: 16.10.13 19:20
Оценка:
Здравствуйте, IT, Вы писали:

IT> I>Где меньше зависимостей ?


IT> Здесь:


IT>
IT>   var n = MyVeryPrimitiveMethod(1, 2);
IT>


Я вот не могу понять это троллинг или что-то еще? Если 1 и 2 это константы то там DI делать нечего, но если эти значения приходят 'извне', то рано или поздно надо будет сделать getParam1 и getParam2. И там есть вероятность, что DI пригодится.
avalon 1.0rc3 build 430, zlib 1.2.5
Re[10]: своё vs. сторонее
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 16.10.13 20:05
Оценка: 4 (2)
Здравствуйте, IT, Вы писали:

IT> Так себе, не самый лучший паттерн, от которого проблемы возникают сразу и по всему коду, а что он даёт ценного внятно не может объяснить ни один из его апологетов.


Согласен полностью и не могу не поделиться.

Имею вот щас на руках проект. Сервис обрабатывает разнообразные сообщения. DI доведен до абсурда. Ну т.е. вот буквально была поставлена цель — ни одного оператора new в коде. И казалось бы, оно имеет смысл — messaging же!

По принципу: обработчик резолвится через DI, получает в свой конструктор толпу объектов из DI, те, в свою очередь, тоже получают в свои конструкторы что-то из DI и т.д.

И что мы имеем? Несколько самых зубодробительных и в то же время самых критичных для юзера багов были связаны с ошибочным расшариванием непотокобезопасных объектов между обработчиками.

Тестами это дело, понятно, не детектируется никак. Ревью тоже бесполезен: попробуй-ка в уме сформируй этот развесистый граф объектов и пойми, что в нем не так. И выявляется только на продакшене, только под нагрузкой и только по абсолютно невразумительным ошибкам в логах.

И вот ты сидишь потом сутки, тупо глядя в лог и мозгуя, как же там могло образоваться именно такое вот исключение...

Повысили, в общем, тестируемость кода, ага.
Re[8]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.13 20:07
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Здесь:


IT>
IT>  var n = MyVeryPrimitiveMethod(1, 2);
IT>


Это больше на фобию похоже.
Re[9]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 01:37
Оценка: +1
Здравствуйте, Dziman, Вы писали:

D>Я вот не могу понять это троллинг или что-то еще? Если 1 и 2 это константы то там DI делать нечего, но если эти значения приходят 'извне', то рано или поздно надо будет сделать getParam1 и getParam2. И там есть вероятность, что DI пригодится.


Может быть пригодится, а может быть скорее всего нет. Почему-то все понимают, что преждевременная оптимизация — это плохо, но решительно не понимают, что преждевременный дизайн — ещё хуже.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 01:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это больше на фобию похоже.


Фобия — это боязнь, а бояться тут нечего. У меня стойкое отвращение. Фууу!
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: своё vs. сторонее
От: Doc Россия http://andrey.moveax.ru
Дата: 17.10.13 06:21
Оценка:
Здравствуйте, IT, Вы писали:

IT>В каком примере?


Который ты и привел, и про который говорим
http://www.rsdn.ru/forum/design/5329186.1
Автор: IT
Дата: 13.10.13


IT>Понятно. Разницы между библиотечной функцией общего назначения и логикой бизнес-приложения для тебя не существует.


Зависит от цели изучения кода и покрытия его логики тестами. Но то, что я не буду при каждом изучении кода смотреть что внутри каждого вызова — это факт. Сначала максимально локализовать проблему, а потом уже копаться.

IT>Опять начался детский сад. Судя по нашему предыдущему общению дальнейшая дискуссия с тобой начинает тепять всякий смысл. Пока.


Ну да, прошу не вешать ярлыки и смысл у тебя пропал сразу. Бывает
Re[10]: своё vs. сторонее
От: evgeny.e Китай  
Дата: 17.10.13 09:11
Оценка:
IT>Может быть пригодится, а может быть скорее всего нет. Почему-то все понимают, что преждевременная оптимизация — это плохо, но решительно не понимают, что преждевременный дизайн — ещё хуже.

преждевременный дизайн это плохо??
по всем исследованиям стоимость ошибки тем меньше, чем раньше она обнаружена, а раньше дизайна некуда,
разница между преждевременным дизайном и оптимизацией в том, что оптимизация это реально работающий (в продакшене) код, а дизайн это обычно писульки в визио,
задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов

лично я предпочитаю без DI, но, на мой взгляд, архитектура с DI будет лучше чем архитектура созданная средним разработчиком без DI, но лучше чем хорошим разработчиком без DI
Re[8]: своё vs. сторонее
От: . Великобритания  
Дата: 17.10.13 09:34
Оценка:
Здравствуйте, IT, Вы писали:

I>>Где меньше зависимостей ?


IT>Здесь:


IT>
IT>  var n = MyVeryPrimitiveMethod(1, 2);
IT>

Зачем так всё сложно? Может уж сразу
  var n = 1 * 2;

Или даже так?
  ;
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.13 12:13
Оценка:
Здравствуйте, IT, Вы писали:

I>>Это больше на фобию похоже.


IT>Фобия — это боязнь, а бояться тут нечего. У меня стойкое отвращение. Фууу!


Ладно, годная отмазка. Вот другой пример

Есть задача — для кастомных модулей подменять функционал. Например у одного кастомера открытие документа это один воркфлоу, у другого — другой, у третьего — третий. Разница слишком большая что бы обкладывать ифами.
Есть некоторый АПИ, используемый внешними расширениями или скриптами, и есть АПИ внутренний, который наружу недоступен.

Вызов открытия документа снаружи достаточно простой — Application.Documents.Open(args);
Все что нужно сделать для другого кастомера — поменять логику открытия документа без необходимости городить конские иерархии наследования и тд.

Весь внутренний АПИ сделан примерно так. Есть N компонентов, похожих на команды или транзакции, интерфейс с вызывающей стороны примерно такой

interface ICommandXXX<TArgs> {
  void Execute(TArgs args);
  void CanExecute(TArgs args);
}


Documents.Open имеет вот такую реализацию

IDocument Open(OpenDocumentArgs args)
{
  var cmd = Resolve<IOpenDocument>();

  if(cmd.CanExecute(args))
     cmd.Execute(args);
}


Вот эта логика не меняется, её в принципе можно и генерить.
Скажем часть UI, это тулбары и меню, обновляется в зависимости от состояния приложения. Это всего лишь конфигурирование, при том в итоге вызывается чтото навроде barItem.StateFrom(cmd.Status) и конкретный итем будет исправно менять своё состояние без каких либо проблем.
Таких итемов примерно несколько сотен, может даже больше. Выписывать вьюмодельки совершенно неинтересно — вспотеешь учитывать все детали.

Фокус в том, что такие компоненты, как IOpenDocument, требуют целую кучу депенденсов, фактически, нужен весь АПИ приложения, и куча фунционала навроде зипа, скриптов и тд и тд и тд. Причем каждому нужно свое.
Внешний АПИ приложения не дает доступа ко всем сервисам, что очевидно. Внутренний сделан так, чт бы его можно было конфигурировать прозрачно для вызывающего кода
Решение получается такое

interface ICommandXXX<TArgs> {
...
  IScriptHost ScriptHost {get; set;}
  IRemoteHost RemoteHost {get; set;}
  IStatus Status {get; set;}
  IValidation Validator {get; set;}
}


Все депенденсы при желании можно подложить свои собственные, отличные от дефолтных
Кроме того, каждый из компонентов может дергать и другие, такие же. Вызов по ряду причин, обычно делается не напрямую, т.к. для каждого компонента создается свой контекст и тд.
Вот так

var cmd = Resolve<ICommandYYY<TArgs>>();

cmd.Execute(args);


Очевидно, реализация ICommandYYY<TArgs> может варьироваться в зависимости от приложения. т.е. достаточно сконфигурировать.
На старте приложения DI подымает конфигурацию, а во время работы расставляет нужные депенденсы по требованию.
В итоге, со стороны кастомерского кода не надо возить с депенденсами. Со стороны внутреннего АПИ надо всего лишь объявить требуемые депенденсы. Унутре компонента все депенденсы уже будут в наличии.
Написание нового функционала сводится к таким вещам — объявить интерфейс, объявить депенденсы, написать внутреннюю логику. Вся инициализация и связывание перекладывается на DI.
БОлее того, на этот DI можно переложить контроль времени жизни некоторых объектов, можно сделать вложеные контексты и много чего другого.
Re[11]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 15:23
Оценка:
Здравствуйте, evgeny.e, Вы писали:

EE>преждевременный дизайн это плохо??


Плохо. Всё преждевременное плохо. Послевременное тоже плохо. Хорошо только своевременное.

EE>по всем исследованиям стоимость ошибки тем меньше, чем раньше она обнаружена, а раньше дизайна некуда,


Ты говоришь про ошибочный дизайн, который чего-то не учитывает. Я говорю о дизайне, который учитыват всё подряд, но никому не нужное, т.е. представляет собой over design.

EE>разница между преждевременным дизайном и оптимизацией в том, что оптимизация это реально работающий (в продакшене) код, а дизайн это обычно писульки в визио,


Нет. Дизайн — это компоновка реально работающего. Есть алгоритмы и бизнес логика, есть их компоновка в классы, иерархии, компоненты, слои и т.п. Дизайн — это части и, самое глвное, связи между частями системы, код — это содержимое частей.

EE>задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов


Хренов. Потому что препятствует отчуждению кода (части системы) от его контекста. Если статика прибивает гвоздями код к его контексту и не позволяет его в результате безболезненно отчуждать, то DI этот контекст наполняет и инициализирует неявно и непредсказуемо. Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.

EE>лично я предпочитаю без DI, но, на мой взгляд, архитектура с DI будет лучше чем архитектура созданная средним разработчиком без DI, но лучше чем хорошим разработчиком без DI


Это как?
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 17:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Есть задача — для кастомных модулей подменять функционал.


Ну подменяй. Что требуется от меня?
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.13 17:11
Оценка:
Здравствуйте, IT, Вы писали:

I>>Есть задача — для кастомных модулей подменять функционал.


IT>Ну подменяй. Что требуется от меня?


Как аргумент в пользу DI годится или как ?
Re[11]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.13 17:13
Оценка:
Здравствуйте, evgeny.e, Вы писали:

EE>задизайнить использование DI там где он не нужен это плохо не потому что дизайн преждевременный, а потому что такой дизайн — хренов


плохой потому что плохой. Сильная идея. DI, там где он не нужен, плохой потому, что DI не нужен. Как-то так
Re[12]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.13 17:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.


Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.

Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"
Re[13]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 18:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Есть задача — для кастомных модулей подменять функционал.

IT>>Ну подменяй. Что требуется от меня?
I>Как аргумент в пользу DI годится или как ?

Надо смотреть. По крайней мере ты это используешь не для тестирования. Похоже, что у тебя нет другого выхода и ты вынужден использвать DI.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 17.10.13 18:24
Оценка: 6 (1)
Здравствуйте, Ikemefula, Вы писали:

IT>>Самый лучший код — это код, который при вызове получает весь необходимый контекст и внутри себя не пытается шаманить со статикой или DI. Такой код легко изолировать и перекомпоновывать под любой дизайн.


I>Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.


Ты видимо прочитал лишь то, что хотел. Это бывает. Объясняю ещё раз. В случае DI объект получает не весь необходимый контекст, а вообще всё, что можно. При этом понять что именно объекту нужно, а что ему передали просто нереально. Поэтому при изучении кода, при его рефакторингах и модификациях, в случаях когда требуется отчуждение кода от системы, работа с таких кодом превращается в одну сплошную невыносимую головную боль.

I>Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"


Вас очень сложно тролить. На любое моё "покажите код" у вас один ответ — "ты не понимаешь".
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: своё vs. сторонее
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.13 18:29
Оценка:
Здравствуйте, IT, Вы писали:

I>>>>Есть задача — для кастомных модулей подменять функционал.

IT>>>Ну подменяй. Что требуется от меня?
I>>Как аргумент в пользу DI годится или как ?

IT> Надо смотреть. По крайней мере ты это используешь не для тестирования. Похоже, что у тебя нет другого выхода и ты вынужден использвать DI.


Примерно так, да.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.