Требовать класс для экземпляра в C #? - PullRequest
6 голосов
/ 28 марта 2012

Нам нужно «защитить» класс от наличия статических методов в целях безопасности. Мы не хотим, чтобы разработчики новичков, следуя предложениям инструментов кодирования, делали член статичным, поскольку нам нужно использовать конструктор с паролем для управления доступом к этому классу.

Есть ли способ защитить класс .NET в C #, чтобы он не имел статических членов?

Будет ли такая функция, если она недоступна, полезной для будущей версии .NET?

Спасибо.

Ответы [ 8 ]

28 голосов
/ 28 марта 2012

нам нужно использовать конструктор с паролем для управления доступом к этому классу.

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

Есть ли способ защитить класс .NET в C #, чтобы он не имел статических членов?

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

Будет ли такая функция, если она недоступна, полезной для будущей версии .NET?

Это вряд ли в крайности.

Спасибо.

Не за что!

9 голосов
/ 28 марта 2012

Самое простое, что можно сделать, это настроить FxCop на сервере сборки и написать собственное правило FxCop для проверки статических элементов.

Этот вопрос содержит подробности о том, как написать пользовательское правило FxCop.


В качестве альтернативы, как указывал SimpleCoder, вы можете использовать StyleCop для применения правила в исходном коде.

На этой странице описано, как настроить StyleCop с помощью msbuild.

8 голосов
/ 28 марта 2012

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

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

3 голосов
/ 28 марта 2012

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

Я не могу придумать, как использовать эту функцию. Это проблема общения, а не реализации.

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

0 голосов
/ 31 марта 2012

Я в значительной степени согласен с Эриком Липпертом.Но в этих случаях я хочу сделать что-то подобное (иногда просто чтобы не допустить ошибок), я пытаюсь написать для него модульный тест.Как это:

[Test]
public void Class_should_not_have_static_methods()
{
    var staticMethods = typeof (Foo).GetMethods().Where(x => x.IsStatic);

    Assert.That(staticMethods.Count(), Is.EqualTo(0), "Static methods: " + string.Join(", ", staticMethods.Select(x => x.Name)));
}
0 голосов
/ 28 марта 2012

Предложения

  1. Обучение
  2. Больше тренировок
  3. Код Отзывы
  4. Другие предложили stylecop или fxcop - оба хороших варианта
  5. Если № 4 терпит неудачу - больше тренировок - на этот раз свяжите это с обзорами производительности. :)
0 голосов
/ 28 марта 2012

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

Требуя, чтобы конструктор содержал пароль, вы пытаетесь защитить себя от людей, которые используют ваш класс. Но эти люди могут декомпилировать и перекомпилировать ваш класс, чтобы снять проверку пароля - так от чего вы защищены?

0 голосов
/ 28 марта 2012

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

...