ОО: Должны ли вы обращаться к своим личным переменным через свойства внутри вашего класса?

Question

Мне было интересно, что такое хорошая практика:

 private int value;

 public int Value { get { return this.value; } }

 private int DoSomething()
 {
      return this.Value + 1;
      //OR
      return this.value + 1;
 }

Итак, вопрос в том, как вы должны обращаться с переменными класса. Вы должны получить доступ к ним через вашу собственность или просто через?

Answer 1

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

private Myobject _value;

public Myobject Value
{
    get
    {
        if (_value == null) _value = new MyObject();
        return _value;
    }
}

private MyObject DoSomething();
{
    //If you access _value here, it might be null...
    //so you should access it through the property:
    return Value;
}

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

Все это сводится к архитектуре вашего приложения, и для этого вам нужно задать вопрос: что наиболее целесообразно с точки зрения обслуживания?

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

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

Мои мысли о плюсах и минусах таковы:

Переход со свойством:

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

Работа с полем:

• У меня нет потенциальной нагрузки на производительность из-за необходимости шагать по коду свойства каждый раз, когда я получаю доступ к значению.
• Мне нужно убедиться, что значение инициализируется должным образом при каждом вызове, или обрабатывать случаи, когда это не так.
• I может повлиять на значение, даже если мое свойство может предоставить толькодоступный только для чтения интерфейс для моего значения.

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

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

Хитрость в том, что всегда делают что-то по какой-то причине, не делайте вещи вслепую только потому, что .

Answer 2

Я бы пошел на прямой доступ. Это все «держать в семье», так сказать.

Answer 3

Свойства введены для «скрытия» в конечном итоге более сложной структуры, чем возвращение одного значения из поля.

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

Answer 4

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

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

Answer 5

Не думаю, что это черно-белый вопрос. Несколько вещей приходят на ум:

Во-первых, если свойство не имеет поведения (то есть get / set просто проходит до получения и возврата поля), то превратите поле в авто-свойство и удалите дилемму. Меньше строк кода, без путаницы.

Во-вторых, если у свойства есть побочные эффекты (ленивая загрузка, уведомление об изменениях, сбор статистики и т. Д.), То вы должны подумать, уместно ли запускать такое поведение через частные обновления. Если это уместно, просто используйте свойство. Если это не подходит, не делайте этого (или измените дизайн, чтобы сделать его более очевидным).

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

например. скажем, у вас есть свойство Angle, защищенное проверкой аргументов.

public class ManThatCanRotate
{
    public int Angle 
    { 
       get { return m_angle; } 
       set { if(value >= 0 && value < 360) m_angle = value; }
    }

    public void RotateLikeSomeKindOfLunatic()
    {
       // imagine this has been called 359 times already.
       m_angle++; // ruh-roh
    }
}

Плохие вещи (tm) произойдут, если вы установите m_angle напрямую, как указано выше; угол станет недействительным. Вы можете просто преобразовать угол в его собственный тип, чтобы сделать его недействительным, что устранит проблему.

Answer 6

Если ваш класс не может доверять своим собственным методам доступа к своим личным переменным, кому он может доверять?

Answer 7

В некоторых ситуациях это хорошая идея. Например, в случае iPhone, учитывая небольшой объем памяти, вы можете получать «предупреждения о памяти» от ОС. В соответствии с этими предупреждениями вас просят освободить память, чтобы избежать остановки. Обычно эта память поступает из таких ресурсов, как изображения, звуки или большие блоки данных, которые вам не нужны постоянно в памяти.

В этом случае я иногда обращаюсь к некоторым частным иварам через частные средства доступа Objective-C, которые обычно проверяют, равен ли ивар «ноль» (NULL), и загружают ли данные обратно в память в «отложенной загрузке», специальный путь. Для этого я считаю частные свойства действительно полезными. В противном случае я использую прямой доступ к ivar.

Как всегда, я не думаю, что на этот вопрос есть однозначный ответ: «это зависит».

Answer 8

Я голосую за возвращение this.value + 1.

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