Зачем всегда инкапсулировать переменные в свойства

@Insomnium · Регистрация: 21.03.2011

Давно хотел спросить. Вопрос возникает постоянно, когда я вижу код типа такого:

C#

class cls
    {
        private int _iii;
 
        public int Iii
        {
          get { return _iii; }
          set { _iii = value; }
        }
    }

Даже у Троелсена есть подобный пример:

Кликните здесь для просмотра всего текста

C#

    class Employee 
    { 
        // Поля данных. 
        private string empName; 
        private int empID; 
        private float currPay; 
        // Свойства. 
        public string Name 
        { 
            get { return empName; } 
            set 
            { 
                if (value.Length > 15) 
                    Console.WriteLine ("Error! Name must be less than 16 characters!"); 
                else 
                    empName = value; 
            } 
        } 
        // Можно было бы добавить дополнительные бизнес-правила для установки 
        // этих свойств, но в данном примере в этом нет необходимости. 
        public int ID 
        { 
            get { return empID; } 
            set { empID = value; } 
        } 
        public float Pay 
        { 
            get { return currPay; } 
            set { currPay = value; } 
        } 
    }

Я понимаю, с какой целью инкапсулируется поле empName, но зачем нужны свойства ID и Pay?

@Casper-SC · 01.07.2013, 06:30

Как я думаю, это всё та же инкапсуляция ради инкапсуляции

. Далее не известно, вдруг при редактировании свойства нужно будет добавить какие-то проверки в него, ещё какой-то функционал. А окажется, что оно не свойство. Или как ты сделаешь поле доступным для редактирования только внутри класса, но для чтения извне? Так же свойства нужны для биндингов. Так же, та же студия отображает чисто свойства в окне свойств у объектов (ну, конечно пример не супер, но пример).

Добавлено через 3 минуты
Или нужно тебе реализовать интерфейс, придётся реализовывать свойство, как ни крути

C#

    internal interface IGameObject
    {
        string Name { get; }
    }

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

@Insomnium · 01.07.2013, 06:47 **[ТС]**

Сообщение от Casper-SC

Далее не известно, вдруг при редактировании свойства нужно будет добавить какие-то проверки в него, ещё какой-то функционал.

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

Сообщение от Casper-SC

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

Сообщение от Casper-SC

Или нужно тебе реализовать интерфейс, придётся реализовывать свойство, как ни крути

Тут, конечно, использование свойств оправдано.

Psilon · 01.07.2013, 08:17

Insomnium,
3) привязки данных (например в WPF) работают только со свойствами.
4) как уже сказано выше, потом могут появиться правила обработки (например, неотрицательность интового поля). Представьте себе, что вы не можете просто так взятьи перекомпилировать все, чтобы заработало, например это библиотечный класс, который наследуется сотней различных клиентов... Или используется... Вот так...

@Insomnium 1 / 1 / 1 Регистрация: 21.03.2011 Сообщений: 46
	01.07.2013, 06:47 [ТС]	3
	Сообщение от Casper-SC Далее не известно, вдруг при редактировании свойства нужно будет добавить какие-то проверки в него, ещё какой-то функционал. Ну, в студии есть удобные инструменты для рефакторинга, из переменной можно сделать свойство за несколько кликов. Сообщение от Casper-SC Или как ты сделаешь поле доступным для редактирования только внутри класса, но для чтения извне? Сообщение от Casper-SC Или нужно тебе реализовать интерфейс, придётся реализовывать свойство, как ни крути Тут, конечно, использование свойств оправдано. 0

Psilon Master of Orion 6079 / 4935 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	01.07.2013, 08:17	4
	Insomnium, 3) привязки данных (например в WPF) работают только со свойствами. 4) как уже сказано выше, потом могут появиться правила обработки (например, неотрицательность интового поля). Представьте себе, что вы не можете просто так взятьи перекомпилировать все, чтобы заработало, например это библиотечный класс, который наследуется сотней различных клиентов... Или используется... Вот так... 0

Опции темы