Есть способ выполнить то, что вы хотите - скрыть участников, которых вы не хотите видеть, - но сделать так, чтобы они применялись автоматически, не требуя сотрудничества других с точки зрения их использования с помощью пользовательского интерфейса. Вы можете сделать это, повторно введя всех членов, которых вы не хотите видеть, и пометив их атрибутами.
Это то, что делает Windows Forms, когда, например, свойство базового класса ничего не значит для конкретного потомка. Например, Control имеет свойство Text, но свойство Text не имеет смысла, скажем, в TabControl. Поэтому TabControl переопределяет свойство Text и добавляет атрибуты к его переопределению, говоря: «Кстати, не показывайте мое свойство Text в таблице свойств или в Intellisense». Свойство все еще существует, но так как вы никогда не видите его, оно не мешает вам.
Если вы добавите атрибут [EditorBrowsable (EditorBrowsableState.Never)]] к члену (свойству или методу), то Intellisense больше не будет отображать этот элемент в своих списках завершения кода. Если я правильно понимаю ваш вопрос, это самое важное, чего вы пытаетесь достичь: усложнить для кода приложения случайное использование элемента.
Для свойств вы, вероятно, также захотите добавить [Browsable (false)] , чтобы скрыть свойство из таблицы свойств, и [DesignerSerializationVisibility (DesignerSerializationVisibility.Hidden)] * , чтобы предотвратить дизайнер записывает значение свойства в файл .designer.cs.
Это затруднит случайное использование метода / свойства. Они все еще не гарантия, хотя. Если вам нужна гарантия, добавьте также атрибут [устарел] и выполните сборку с «Обрабатывать предупреждения как ошибки» - тогда вы позаботитесь о.
Если базовый член является виртуальным, вы, вероятно, захотите переопределить его, и пусть ваше переопределение просто вызовет base. Не выбрасывайте исключение, поскольку переопределенный член, вероятно, будет вызываться базовым классом во время обычного хода событий. С другой стороны, если базовый элемент не является виртуальным, тогда вы хотите использовать «новый» вместо «переопределить», и вы можете решить, должна ли ваша реализация вызывать базовый или просто выдавать исключение - никто не должен использовать в любом случае, ваш вновь введенный участник, так что это не должно иметь значения.
public class Widget : UserControl
{
// The Text property is virtual in the base Control class.
// Override and call base.
[EditorBrowsable(EditorBrowsableState.Never)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
[Obsolete("The Text property does not apply to the Widget class.")]
public override string Text
{
get { return base.Text; }
set { base.Text = value; }
}
// The CanFocus property is non-virtual in the base Control class.
// Reintroduce with new, and throw if anyone dares to call it.
[EditorBrowsable(EditorBrowsableState.Never)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
[Obsolete("The CanFocus property does not apply to the Widget class.")]
public new bool CanFocus
{
get { throw new NotSupportedException(); }
}
// The Hide method is non-virtual in the base Control class.
// Note that Browsable and DesignerSerializationVisibility are
// not needed for methods, only properties.
[EditorBrowsable(EditorBrowsableState.Never)]
[Obsolete("The Hide method does not apply to the Widget class.")]
public new void Hide()
{
throw new NotSupportedException();
}
}
Да, это довольно трудоемкая работа, но вы должны выполнять ее только один раз ... для каждого члена, для каждого класса ... ммм, да. Но если эти члены базового класса действительно не относятся к вашему классу, и наличие их там вызовет путаницу, тогда, возможно, стоит приложить усилия.