Блокирование доступа к переменным члена парламента, не занимающего официального поста? Использование силы общественных собственностей?

Вы можете сделать это через наследование:

abstract class A // A is not instantiatable due to being abstract
{
    private string m_hello = null;

    public string Hello
    {
         get{return m_hello;}
         set{m_hello = value;}
    }
}

class B : A
{
    // B now cannot access the private variable, use B in your code instead of A
}

Я не утверждаю, что это хорошо. Просто это можно сделать.

Как предложили другие, это должно быть ответом...

Вы все еще можете использовать автоматические свойства в C# 3 при работе с .NET 2.0, наряду с некоторыми другими возможностями C# 3. В отличие от (скажем) деревьев выражений, автоматическим свойствам не нужно ничего особенного от CLR или фреймворка, кроме атрибута [CompilerGenerated] (который был введен в .NET 2.0).

Так что если вы используете VS2008 или VS2010, то стоит использовать автоматическое свойство.

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

 public string Name
 {
     private string name;
     get { return name; }
     set { name = value; }
 }

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

Нет, в принципе. Ну, вы могли бы сделать что-то с предупреждениями компилятора через [Obsolete] и #pragma, но это было бы чрезмерно.

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

while(true) { }

или вы просто списали это на "не будь дураком"? ;p

Нет. Любой метод внутри класса будет иметь доступ к обоим.

Ваша команда должна стандартизировать, что использовать (свойство или частную переменную).

Как только вы решите, что использовать, вы можете попытаться использовать пользовательское правило FxCop для обеспечения соблюдения стандарта.

Доступ к свойству можно получить только через общедоступное свойство Hello. Это причина такой закономерности. Если вы добавите какие-либо функции в get или set, если вы обращаетесь к частному экземпляру, вы внесете ошибки в свой код. Но ответ - НЕТ, вы не можете запретить кому-либо вызывать Private, когда они внутри вашего класса изменяют ваш код.

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

Лично я не вижу ничего плохого в доступе к закрытому члену внутри класса. Фактически, это то, что я обычно делаю (если только в геттере / установщике свойств нет логики, которую я всегда хочу использовать).

Для меня это просто имеет смысл: код внутри класса составляет реализацию этого класса; зачем скрывать реализацию от самой себя?

Вот пример того, что я имею в виду. Предположим, у меня есть член m_denominator , и я хочу, чтобы он никогда не был равен нулю:

private int m_denominator = 1;
public int Denominator
{
    get { return m_denominator; }
    set
    {
        if (value == 0)
            throw new ArgumentException("Denominator must not be zero.");
        m_denominator = value;
    }
}

Я мог бы сказать себе: «Хорошо, везде, где я устанавливаю это значение в этом классе, я должен использовать Знаменатель , чтобы убедиться, что я не устанавливаю его равным нулю ». Но я полностью контролирую то, что устанавливаю Знаменатель на - Я внутри класса! В и этом сценарии суть логики в свойстве Знаменатель заключается в защите класса от недопустимых значений, установленных клиентским кодом. Нет оправдания для установки вашего внутреннего состояния на некое недопустимое значение в реализации самого класса.

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