Уведомить разработчика о методе "DO NOT USE"

Вы можете использовать:

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

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

Однако точка зрения Китса о сверхинженерии все еще стоит.

Если класс имеет значение [Serialisable] (то есть его можно скопировать в любое место по мере необходимости), то для десериализации необходим конструктор без параметров.

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

В основном вы говорите, что это OK для XmlSerializer , чтобы сделать копию и затем установить свойства, но вы не хотите, чтобы ваш собственный код сделал это.

В какой-то степени я думаю, что это чрезмерное проектирование.

Просто добавьте XML комментарий, который подробно описывает, какие свойства нужно инициализировать (и что делать).

Не используйте [Obsolete] , потому что это не так. зарезервируйте это для действительно устаревших методов.

Я прочел заголовок и сразу подумал: "28. Как насчёт

    /// <summary>
    /// do not use
    /// </summary>
    /// <param name="item">don't pass it anything -- you shouldn't use it.</param>
    /// <returns>nothing - you shouldn't use it</returns>
    public bool Include(T item) { 
    ....

На самом деле я был бы склонен не согласиться со всеми, кто выступает за использование ObsoleteAttribute , поскольку в документации MSDN говорится, что:

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

Поскольку универсальные конструкторы для сериализации XML не должны быть удалены из приложения, я не буду применять его только в том случае, если разработчик технического обслуживания в будущем не знаком с тем, как работает сериализация XML.

Я фактически использовал метод кита , просто отметив, что конструктор используется для сериализации в документации XML, так что он появляется в Intellisense.

Вы можете построить свой собственный производный класс Attribute , скажем NonCallableAttribute , чтобы квалифицировать методы, а затем добавить в задачу анализа кода build/CI проверку для отслеживания, если какой-либо код использует эти методы.

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

ObsoleteAttribute , вероятно, будет работать в вашей ситуации - вы даже можете вызвать разрыв сборки, если этот метод используется.

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

То, что вы ищете-это класс ObsoleteAttribute :

using System;

public sealed class App {
   static void Main() {      
      // The line below causes the compiler to issue a warning:
      // 'App.SomeDeprecatedMethod()' is obsolete: 'Do not call this method.'
      SomeDeprecatedMethod();
   }

   // The method below is marked with the ObsoleteAttribute. 
   // Any code that attempts to call this method will get a warning.
   [Obsolete("Do not call this method.")]
   private static void SomeDeprecatedMethod() { }
}

Ух ты, эта проблема меня тоже достает.

Вам также нужны конструкторы по умолчанию для NHibernate, но я хочу заставить людей NOT использовать инициализаторы объектов C# 3.0, чтобы классы проходили через код конструктора.

Отделите сериализуемый объект от объекта домена.

throw new ISaidDoNotUseException();

Да, это так.

Я написал об этом в своем блоге, работая с дизайнером .

А вот и код:

public class MyClass
{
  [Obsolete("reason", true)]
  public MyClass()
  {
    // required for xml serialization
  }
}

Я использую ObsoleteAttribute .

Но также вы можете иметь некоторые комментарии, конечно.

И, наконец, удалите его полностью, если вы можете (не нужно поддерживать совместимость с чем-то старым). Это самый лучший способ.