Наше программное обеспечение имеет несколько классов, которые должны быть динамически найдены с помощью отражения. Все классы имеют конструктор с определенной сигнатурой, посредством которой код отражения создает объекты.
Однако, когда кто-то проверяет, есть ли ссылка на метод (например, через Visual Studio Code Lens), ссылка через отражение не учитывается. Люди могут пропустить свои ссылки и удалить (или изменить) явно неиспользуемые методы.
Как мы должны пометить / документировать методы, предназначенные для вызова через отражение?
В идеале метод должен быть помечен таким образом, чтобы как коллеги, так и Visual Studio / Roslyn и другие автоматизированные инструменты «видели», что метод предназначен для вызова с помощью отражения.
Я знаю два варианта, которые мы можем использовать, но оба они не совсем удовлетворяют. Поскольку Visual Studio не может найти ссылки:
- Используйте пользовательский атрибут и пометьте конструктор этим атрибутом.
- Проблема заключается в том, что свойства атрибута не могут быть ссылкой на метод, поэтому конструктор все равно будет отображаться как имеющий 0 ссылок.
- Коллеги, не знакомые с пользовательским атрибутом, вероятно, проигнорируют его.
- Преимущество моего текущего подхода состоит в том, что часть отражения может использовать атрибут, чтобы найти конструктор, который он должен вызвать.
- Используйте комментарии, чтобы задокументировать, что метод / конструктор предназначен для вызова через отражение.
- Автоматизированные инструменты игнорируют комментарии (и коллеги могут делать то же самое).
- Комментарии к XML-документации могут использоваться для подсчета в Visual Studio дополнительной ссылки на метод / конструктор:
ПозвольтеMyPlugin
быть классом, конструктор которого вызывается через отражение. Предположим, что вызывающий код отражения ищет конструкторы, которые принимаютint
параметр. Следующая документация показывает, что кодовая линза показывает конструктор, имеющий 1 ссылку:
/// <see cref="MyPlugin.MyPlugin(int)"/> is invoked via reflection
Какие лучшие варианты существуют?
Какова наилучшая практика для маркировки метода / конструктора, который должен вызываться с помощью отражения?
источник
Ответы:
Комбинация предложенных решений:
Это должно прояснить предполагаемое использование коллегам (и моему будущему я).
<see>
-tag, чтобы увеличить количество ссылок для конструктора / метода.Это делает этот код объективным, а поиск ссылок показывает, что на конструктор / метод ссылаются.
UsedImplicitlyAttribute
[UsedImplicitly]
имеет точно предполагаемую семантику.PM>
Install-Package JetBrains.Annotations
.SupressMessageAttribute
для сообщенияCA1811: Avoid uncalled private code
.Например:
Решение предоставляет предполагаемое использование конструктора как читателям-людям, так и трем системам статического анализа кода, наиболее часто используемым в C # и Visual Studio.
Недостатком является то, что и комментарий, и одна или две аннотации могут показаться немного излишними.
источник
MeansImplicitUseAttribute
что может быть использовано для создания ваших собственных атрибутов, которые имеютUsedImplicitly
эффект. Это может уменьшить много шума атрибута в правильных ситуациях.У меня никогда не было этой проблемы в проекте .Net, но у меня регулярно есть такая же проблема с проектами Java. Мой обычный подход заключается в использовании
@SuppressWarnings("unused")
аннотации с добавлением комментария, объясняющего почему (документирование причины отключения любых предупреждений является частью моего стандартного стиля кода - всякий раз, когда компилятор не может что-то выяснить, я предполагаю, что, вероятно, человек может бороться тоже). Преимущество этого заключается в том, что инструменты статического анализа автоматически получают информацию о том, что в коде не должно быть прямых ссылок, и дают подробное объяснение для читателей.С # эквивалент Java
@SuppressWarnings
этоSuppressMessageAttribute
. Для приватных методов вы можете использовать сообщение CA1811: избегайте невостребованного приватного кода ; например:источник
SuppressMessageAttribute
( msdn.microsoft.com/en-us/library/… ). Наиболее близким сообщением являетсяCA1811: Avoid uncalled private code
( msdn.microsoft.com/en-us/library/ms182264.aspx ); Я еще не нашел сообщение для открытого кода.Альтернативой документированию было бы проведение модульных тестов, обеспечивающих успешное выполнение вызовов отражения.
Таким образом, если кто-то изменяет или удаляет методы, ваш процесс сборки / тестирования должен предупредить вас, что вы что-то сломали.
источник
Ну, не видя ваш код, вроде бы это было бы хорошим местом для введения некоторого наследования. Может быть, виртуальный или абстрактный метод, который может вызвать конструктор этих классов? Если вы метод, который вы пытаетесь пометить, это просто конструктор, то вы действительно пытаетесь пометить класс, а не метод, да? Что-то, что я сделал в прошлом, чтобы пометить классы, - создать пустой интерфейс. Затем инструменты проверки кода и рефакторинга могут искать классы, которые реализуют интерфейс.
источник