Используете ли?

hVostt,

Мне сама идея не особо как-то сначала понравилась. Но есть очень типичная ситуация, когда для удобства хочется в интерфейсе иметь больше методов, но при этом большая их часть всегда и везде будет реализовываться просто через другие методы того же интерфейса. И типовым решением для этого было использовать методы-расширения - можно посмотреть, например, как устроены интерфейсы IServiceProvider или ILogger - в них самих всего по одному методу, а все остальные "их" методы это методы-расширения. (Я сам не большой любитель расширений, но вот это, как раз случай, где расширения подходят просто идеально.) И вот, я подумал, что DIM в таких случаях могут быть удобной альтернативой:

1) Нет риска поломки из-за конфликта с "обычным" методом.
2) Нет зависимости от наличия using.
3) Можно определять свойства.

Попробовал заменять расширения дефолтными методами и сразу же наткнулся на проблемы:

1) Дефолтный метод доступен только через интерфейс, но не через класс, который этот интерфейс реализует (точь в точь как explicit method implementation). Обычно это проблем вызывать не должно, т.к. DI и все используется через интерфейсы. Но, есть, все-таки, ситуации когда это может быть проблемой. Допустим, я пишу какой-то библиотечный класс и просто не хочу закладываться на то, что тот, кто его будет использовать обязательно будет использовать его через интерфейс, а не напрямую.

2) Моки. Вот это проблема уже настоящая. Castle (по крайней мере в текущей версии) не может создавать dynamic proxy для интерфейсов с дефолтными методами. Нашел в итоге обходной путь:




Так работает, но вся конструкция в целом несколько уродливая, все это приходится делать везде где нужен мок для IFoo, и всегда надо помнить что IFoo (и другие подобные) надо мокать не напрямую, а только через вспомогательную абстрактную реализацию.

В общем, покрутил я все это так и сяк, и, в том, что касается того о чем я сначала писал (заменить методы-расширения дефолтными реализациями) вернулся все-таки к старым добрым расширениям.

И еще, с т.з. идеологии. Само по себе наличие у метода интерфейса реализации по-умолчанию это вполне нормально, почему бы и нет. Но синтаксически все это сделано как-то некрасиво. Интерфейс, по своей сути, это просто спецификация какого-то public API компонента. И смешивать её с кодом реализации смотрится как-то не очень. Это как если бы в файл OpenAPI сваггера можно было бы вписать какой-нибудь код на PHP с реализацией описанного там вызова :)

Вот в чем. Возьмем интерфейс из моего примера выше и его реализацию:


А теперь, допустим, что это часть библиотеки, которую использует кто-то другой. И такой код:

у него вообще не соберется. Т.е. надо будет либо указывать в доках (которые никто не читает :), что писать можно только так:

либо как-то вообще запретить использовать класс Foo напрямую (например, заставить создавать только через фабрику или фабричный метод, что отдает какими-то лишними костылями)


Я это знаю. Я и имел в виду не "то же самое" а "ведет себя так же в плане доступа к методу".

Нет. Но это близко к "traits".

Если все это свой собственный проект, то:

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

2) Если же мы решаем проблему из п.1 через DIM, то мы сразу же переносим её на юнит-тесты, в которых интерфейс мокается (как я писал выше). Все юнит-тесты которые мокают этот интерфейс сразу же поломаются.

Проблемы могут быть, если этот интерфейс публикуется в составе библиотеки в качестве точки расширения (т.е. чтобы пользователь либы мог её расширить своей реализацией этого интерфейса).

Сценарий, например, такой:

1) Вася создал мегафреймворк "Foo" в котором есть интерфейс IFoo для его расширения и публикует его как NuGet пакет Foo с версией 1.0.0.

2) Петя цепляет версию Foo.1.0.0 в свою либу Bar, реализует в ней свой компонент-расширение с интерфейсом IFoo, и публикует свое творение как Bar.1.0.0.

3) Васин фреймворк очень успешен, у него куча идей по его развитию, и он добавляет к своему интерфейсу IFoo еще один метод. Вася успешный инвестор опытный разработчик соблюдающий заветы SemVer, поэтому, зная, что изменение интерфейса может поломать совместимость, увеличивает мажорную версию, и свое новое произведение публикует уже как Foo.2.0.0. У Пети с этим проблем нет, потому что его пакет зависит от версии Foo.1.0.0 где интерфейс еще прежний.

4) А вот теперь мы в своем проекте цепляем одновременно либу Пети Bar.1.0.0 и фреймворк Васи Foo.2.0.0 (мы же хотим быть на острие прогресса и берем все самое последнее). И вот как раз тогда у нас все действительно падает.

Но такой сценарий, все-таки, не отнесешь к тому, с чем каждый день сталкиваешься.

Нет. На практике проверено. И проблема упирается как раз в Кастел (который все мок-фреймворки используют). В крайней версии Moq какой-то workaround уже встроили, но, вот, в FakeItEasy (кторым я как раз и пользуюсь) этого еще нет - по обсуждению в issues их позиция - "подождем, пока это будет поддерживаться нативно в Castle".

Я, в общем, подумал тут, что может быть форкну на выходных FakeItEasy и заплатку поставлю, чтобы он с DIM работал - у меня идея уже есть как это сделать.

Впрочем, ты, м.б. о том, что руками они "мокаются на ура" - но ведь это же совсем колхоз-совхоз :))

Да, я об этом и написал, но, как видишь, там свои проблемы при этом возникают.


Я их не использую сам, но их используют мок-фреймворки. Проблема с ними. Вот такой код сразу же кидает ексепшен:


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

hVostt,

Что обидно, с Moq моки работают. Вот это вот вполне ок:


Но, я, вот, Moq уже разлюбил и полюбил вместо него FakeItEasy за намного более компактный синтаксис.