Кстати, еще один напряг от ООП - зависимости Я думаю все прописывают зависимости в конструкторе (через DI), тк неявные зависимости это ужас. При этом я не могу сказать "мне нужно что-то с сигнатурой: User => List<Messages>" И вот тут начинается Interface-HELL. На одном из Xamarin митапов видел код, где к каждому классу Service обязательно создается IService, в котором тупо перечислены все публичные методы этого класса. В итоге в вызывающий класс попадет не только ссылка на нужный метод, но еще 100500 для него не нужных.

Кстати, еще один напряг от ООП - зависимости Я думаю все прописывают зависимости в конструкторе (через DI), тк неявные зависимости это ужас. При этом я не могу сказать "мне нужно что-то с сигнатурой: User => List<Messages>" И вот тут начинается Interface-HELL. На одном из Xamarin митапов видел код, где к каждому классу Service обязательно создается IService, в котором тупо перечислены все публичные методы этого класса. В итоге в вызывающий класс попадет не только ссылка на нужный метод, но еще 100500 для него не нужных.

На эту тему был отличный пост\

он был давно надо потратить время на поиск. Но он как раз про DI и "сигнатурные" сервисы в C#

А в чем именно ад с интерфейсами?

руками их набирать не надо

все делает Resharper

и при этом упрощает тестирование

А в чем именно ад с интерфейсами?

на самом деле часто интерфейсы можно было бы заменить на сигнатуру функции

это правильно

А в чем именно ад с интерфейсами?

В итоге в вызывающий класс попадет не только ссылка на нужный метод, но еще 100500 для него не нужных. Вообще по дяде Бобу нужно "инвертировать зависимости" и "юзать тонкие интерфейсы (хоть из 1 метода (которые факт. являются функцией))", но так никто не делает ибо будет уж слишком много интерфейсов.

на самом деле часто интерфейсы можно было бы заменить на сигнатуру функции

Вот хороший доклад на эту тему:%

https://vimeo.com/113588389

В итоге в вызывающий класс попадет не только ссылка на нужный метод, но еще 100500 для него не нужных. Вообще по дяде Бобу нужно "инвертировать зависимости" и "юзать тонкие интерфейсы (хоть из 1 метода (которые факт. являются функцией))", но так никто не делает ибо будет уж слишком много интерфейсов.

вот доклад что скинул выше ровно о том же

все делает Resharper

Это как в Java говорить "проперти не нужны, IDEA генерирует get/set методы автоматически". Но "бойлерплейта" меньше в код это этого не становится.

http://bartoszsypytkowski.com/c-a-different-look-at-service-design/ смотри как круто сделано.

нашел!

я согласен. Не спорю что если довести до абсолюта ООП подход постепенно выраждается в функциональный подход

http://bartoszsypytkowski.com/c-a-different-look-at-service-design/ смотри как круто сделано.

Я так и не смог попробовать на c# такое написать, сразу переходил на f#

но тем не менее - в проекте с 2860 файлами cs не кажется адом

Это как в Java говорить "проперти не нужны, IDEA генерирует get/set методы автоматически". Но "бойлерплейта" меньше в код это этого не становится.

Но если выбора нет, то хорошая альтернатива. И решает именно проблему описанную тобой выше.

Но если выбора нет, то хорошая альтернатива. И решает именно проблему описанную тобой выше.

Проблема не в "сгенерировать", а в захламление кода.

Но если выбора нет, то хорошая альтернатива. И решает именно проблему описанную тобой выше.

Я про статью

http://i.imgur.com/guFkuoF.png - вот у меня пока не хватает скила переписать этот проект на F# )

командой в 7 человек почти два года писали проект и только сейчас уже более менее закончились новые фичи

И как меня убивает вот это https://i.gyazo.com/3c14032703d7c69c1263bf147d5c7066.png

И как меня убивает вот это https://i.gyazo.com/3c14032703d7c69c1263bf147d5c7066.png

зато тонкие интерфейсы, тут подход верный и он во всю используется в F#, но тут не получается write less do more. Тут получается сам пиши типы, которые глупый компиолятор не способен вывести.

зато тонкие интерфейсы, тут подход верный и он во всю используется в F#, но тут не получается write less do more. Тут получается сам пиши типы, которые глупый компиолятор не способен вывести.

В каком нибудь Scala/Kotlin я могу объявить конструктор который будет сразу объявлением полей. https://i.gyazo.com/8975191765cd252b9609e6affc7c0368.png

сама по себе консутркция убивает. Но в качестве альтернативы мы вообще не вызываем конструктор

и если объект вызывается из 100500 мест то добавление или удаление лишнего аргумента в конструктор никак не влияет на остальной код

все пользователи класса ничего не знают о его конструкторе

сама по себе консутркция убивает. Но в качестве альтернативы мы вообще не вызываем конструктор

В C# 7.0 обещали сделать primary constructor который это решал, но так и не сделали.

но если надо заменить одну компоненту на другую?

но в целом я согласен что функциональных подход проще

просто я не до конца осмыслил какие могут возникнуть проблемы если заюзать это в enterpise

но если надо заменить одну компоненту на другую?

В смысле? Там все передается как и раньше https://i.gyazo.com/6a686f79ba319f2359d7ce26acdedf82.png (В Kotlin нет ключевого слова new)

так вот это new (не важно с ним или без) - любое явное создание конструктора это зло

ну т.е. прямое конструирование объекта

так вот это new (не важно с ним или без) - любое явное создание конструктора это зло

Так я про то что не надо явно приравнивать "параметры контсруктора" в "поля". DI это отдельная тема (и с этим все в порядке).

так вот это new (не важно с ним или без) - любое явное создание конструктора это зло

а вы без конструктора его как добавляете? Статический метод Create и кучу перегрузок?

этим занимается контейнер

этим занимается контейнер

чем?

мы просто регистрируем в контейнере реализацию на интерфейс и контейнер сам резолвит интерфейс

так например можно одной строчкой кода сделать из объекта тот же синглтон

или синглотон на поток

или новый инстанс на каждый вызов

и т.д. и т.п.

мы просто регистрируем в контейнере реализацию на интерфейс и контейнер сам резолвит интерфейс

это-то понятно у самог ов наследстве код с Unity и хз сколкьо инетрфейсов и на каждый по 150 реализаций

но это не совсем не используем конструктор. Я хчоу получить объект X как мне это можно сделать?

если речь о DTO то для них сделано исключение

и то их не везде можно порождать - только в сервисах

ок, а если не DTO?

все остальное только через абстракцию

Вот я хочу получить обект с интерфейсом IX

просто передаем его в конструктор и все

больше ничего не надо делать

ну кроме как в контейнере зарегать этот интерфейс

В конструктор к объекту IXX?

я немного запутался с вопросом

минутку

да и ок, я хочу этот IX параметризировать своим личным IService

пример приведу

В конструктор к объекту IXX?

Кстати (вы наверное в курсе), это так любят в интерпрайзе, что даже в .NET/JVM зашили паттерн "1 интерфейс - 1 реализация" (называется девертуализация)`.

Кстати (вы наверное в курсе), это так любят в интерпрайзе, что даже в .NET/JVM зашили паттерн "1 интерфейс - 1 реализация" (называется девертуализация)`.

зашили? Не понял, ты про конвенцию?

зашили? Не понял, ты про конвенцию?

Про то что в runtime если существует только одна реализация интерфейса (для 2 и больше не работает), то все виртуальне методы JIT заменяет на прямые. Это есть и в Java и .NET, но для Java это важнее тк там по умолчанию все методы виртуальные.

вот пример

public DownloadService(IFileManager fileManager, ILogger logger, ) { _logger = logger; _fileManager = fileManager; }

Про то что в runtime если существует только одна реализация интерфейса (для 2 и больше не работает), то все виртуальне методы JIT заменяет на прямые. Это есть и в Java и .NET, но для Java это важнее тк там по умолчанию все методы виртуальные.

Ааа. Интересно

теперь

для WPF

cb.RegisterType<FileManagerWpf?).As<IFileManager?).SingleInstance();

кто нить знает как тут код без смайлов вливать? )

кто нить знает как тут код без смайлов вливать? )

используй обратыней кавычки, Люк

(<>)

` вот такие

cb.RegisterType<FileManagerDroid>().As<IFileManager>().SingleInstance();

это для андроида

ну и т.д.

нигде нет такого вроде new FileManagerDriod() и т.п.

нигде нет такого вроде new FileManagerDriod() и т.п.

допустим твой FileManager зависит от драйвера. Если надо лезть на флешку то парамтеризуется одним драйвером, а если надо лезть на внутренний ssd, например, то тогда другим драйвером.

А все

понял вопрос

в умных DI контейнерах это все разруливается

минутку

да, Ninject по имени например , stracturemap можно явгно указать что если инжектимся в этот тип, то используй это, если в другой то то.

Но если я пишу плагин, например и у меян нет доступа к настройке вашего DI фреймворка

на самом деле есть несколько готовых решений

по имени

через декоратор/адаптер

и т.п.

минутку

тогда вым надо высатвить api своего DI контейнера, чтоб я мог зарегистрировать свой адаптер например.

http://docs.autofac.org/en/latest/advanced/keyed-services.html

http://docs.autofac.org/en/latest/advanced/keyed-services.html

резолвить по имени не лучшая идея кончено)

ну там и другие варианты есть - можно какой нить enum сделать и по нему резолвить если точно известен все возможные варианты

ну там и другие варианты есть - можно какой нить enum сделать и по нему резолвить если точно известен все возможные варианты

Да, но вы то не знаете какой я свой тип сделаю в который буду инжектить ваши FileManager.

т.е. я его должен регистрировать сам.

в том то весь и замес что я знаю только об обстракции

хорошо написанной компоненте должно быть все равно какая именно реализация у него будет