Скрыть детали реализации от разработчиков в одной сборке - PullRequest
0 голосов
/ 10 июня 2018

Я хочу отделить Foo от FooHandler.Также они должны быть зарегистрированы DI через сканирование сборки.Поэтому у меня есть 3 типа:

interface IFooHandler { // no type arguments, so it can be used by reflection
   void DoStuff(object foo); 
}

interface IFooHandler<TFoo>: IFooHandler { // TFoo tells us, what foo is it for
   void DoStuff(TFoo foo); // developers are happy with strongly typed foos
}

abstract class FooHandler<TFoo>: IFooHandler<TFoo> {
   void IFooHandler.DoStuff(object foo){
       DoStuff((TFoo)foo); // adapter of interface 2 to 1
   }
   abstract void DoStuff(TFoo foo); // for nice implementation
}

Проблема с таким дизайном заключается в том, что я не могу легко запретить другим людям в моей сборке использовать IFooHandler или IFooHandler<TFoo> напрямую.Использование first - плохая идея, потому что оно не будет зарегистрировано в DI и не получится.Использование second - плохая идея, потому что вы пишете бесполезный шаблон, уже написанный в базовом классе.

Разумно ли добавлять атрибут Obsolete с error=True, чтобы люди не могли использовать эти интерфейсы?Есть ли лучший способ их скрыть (я не могу переместить их в другую сборку и пометить как внутреннюю).

Конкретный пример: допустим, у нас есть веб-приложение, и в этой панели для различных типов есть контексты (Foo)которые идентифицируют список опций для данного контекста.Допустим, у вас есть выбор валюты, и Foo CurrencyList.Затем у вас есть класс CurrencyListProvider, который принимает CurrencyList, получает доступные валюты из базы данных и возвращает на панель, чтобы пользователь мог выбрать, какую валюту он хочет использовать для транзакции.Я использую конкретные типы, поэтому вы можете легко перемещаться по базе кода с помощью таких инструментов, как resharper, но внутри этих конкретных типов есть строки, проходящие через http.

1 Ответ

0 голосов
/ 10 июня 2018

Разумно ли добавлять устаревший атрибут с ошибкой = True, чтобы люди не могли использовать эти интерфейсы?

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

Также они должны быть зарегистрированы DI через сканирование сборки

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

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

Пусть ваша фабрика решит, какую версию вернуть.

Вы даже можете использовать сборки друзей для защиты конструкторов.

реальный ответ:


Просто убедитесь, что ваша документация завершена.Если люди читают, что вы не одобряете использование определенного типа, пусть решают.Если ваши сборки хорошо документированы, это поможет вам:
  • a) поддерживать ваш код в течение времени
  • b) ссылаться на документы, если кто-то испортит
  • в) помогите своим пользователям правильно использовать вашу библиотеку

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...