Зачем нужны автоматически реализуемые свойства?

@Богдан всепытный · Регистрация: 10.11.2017

Author24 — интернет-сервис помощи студентам

Зачем нужны автоматически реализуемые свойства в c#? Что, нельзя просто пометить поле как public? Зачем надо, чтобы доступ получался только через get и set, если в них нет никаких фильтров, ничего?

@Passerby · 27.06.2018, 12:24

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

@КОП · 27.06.2018, 12:40

Сообщение от Passerby

Если пользователь не хочет этой функцией пользоваться, то ему что старый проект, что новый - все равно.

он продолжает юзать свойство, которое работает ровно так как описано в моих доках.

Сообщение от Passerby

Если же он захочет такой функцией воспользоваться

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

Сообщение от Passerby

если пользователь захочет задействовать ваш новый проект

вот найдут у вас дыру в безопасности или просто баг критичный, тогда все захотят разом и быстро)

Добавлено через 7 минут

Сообщение от Passerby

то ему в любом случае придется перекомпилировать свой код.

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

@Passerby · 27.06.2018, 13:05

Сообщение от КОП

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

Итак, свойства нужны только в том случае, если выполняются сразу:
1. Проект это не вся программа.
2. Проект делается для его использования другими.
3. Если есть предположение повышения безопасности проекта изменением его свойств.

@Toros1992 · 27.06.2018, 13:20

Свойствами надо делать все, что хоть как-то будет соприкасаться с другими объектами. Помимо вышеописанных выгод, свойства позволяют осуществлять привязку данных, хранящихся в этих свойствах к элементам управления, например.
Приватное поле - это какая-то инфа, влияющая на сугубо внутреннюю реализацию поведения (коэффициенты, констаны, внутренние объекты, и т.д.)
Свойства - это одна из самых широко-используемых вещей.

Не по теме:

Сообщение от Passerby

Итак, свойства нужны только в том случае, если выполняются сразу:
1. Проект это не вся программа.
2. Проект делается для его использования другими.
3. Если есть предположение повышения безопасности проекта изменением его свойств.

Применение свойств можно ограничить тремя пунктами только примерно в такой классификации:
1. Фронтенд
2. Бэкенд
3. Фуллстак

@КОП · 27.06.2018, 13:31

Сообщение от Passerby

Итак, свойства нужны только в том случае, если выполняются сразу:

это буквально пара дополнительных нажатий клавиш, почему надо так долго обосновывать преимущества свойств ради этой пары кликов?

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

@Passerby · 27.06.2018, 13:49

Сообщение от КОП

это буквально пара дополнительных нажатий клавиш, почему надо так долго обосновывать преимущества свойств ради этой пары кликов?

Если эти преимущества для данного проекта есть. А если не выполняется что-то из перечисленного 1,2,3? И пара кликов, это только для одного свойства. И скорость чтения кода и скорость нахождения нужного фрагмента: ведь, не только закладками, но и скрулом пользуетесь.

Сообщение от КОП

Вопрос из ряда зачем писать качественный код

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

@kolorotur · 27.06.2018, 14:36

Сообщение от Passerby

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

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

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

@Passerby · 27.06.2018, 15:13

Сообщение от kolorotur

Во всех, не связанных с очень редкими ситуациями

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

@Toros1992 · 27.06.2018, 15:18

Passerby, Вы неправы. Свойства не только в этих случаях используются.
Они используются везде. Для привязки данных, инкапсуляции, переопределения логики свойств у наследников...

@Passerby · 27.06.2018, 15:38

Сообщение от Toros1992

Они используются везде. Для привязки данных, инкапсуляции, переопределения логики свойств у наследников...

Что не позволит в случае надобности заменить поле свойством в случаях не описанных мной?

@КОП · 27.06.2018, 15:53

Сообщение от Passerby

Что не позволит в случае надобности заменить поле свойством в случаях не описанных мной?

Ну замените поле Field на свойство, сравните вывод

C#

using System;
 
struct S
{
    public int Value { get; set; }
    
    public void SetValue(int i)
    {
        Value = i;
    }
}
 
class MyClass
{
    public S Field;
}
 
class Test
{    
    static void Main(string[] args)
    {
        MyClass mc = new S();
        mc.Field.SetValue(10);
        
        Console.WriteLine(mc.Field.Value);
    }
}

@Toros1992 · 27.06.2018, 16:01

КОП, Блин интересно... А не поясните, почему так?

@kolorotur · 27.06.2018, 16:06

Сообщение от Toros1992

почему так?

Потому что S — значимый тип, копируется при возвращении из свойства.

@Passerby · 27.06.2018, 16:35

Да, пример интересный.
Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности. Кроме уже упомянутых 1,2,3. Или для программ не разбитых на блоки, некоторые из которых предназначены для других пользователей, простые типы не надо заранее объявлять свойствами. Судя по ответам не делать свойства - плохой тон. Но если усомниться в религии?

@kolorotur · 27.06.2018, 17:01

Сообщение от Passerby

Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности.

Пример со структурой выше — проще некуда.
Заметили бы вы получившийся баг, просто глядя на код?
А реальная программа будет состоять из гораздо большего количества кода и баг, как это всегда бывает, всплывет в самый неудачный момент.
А багов, связанных с заменой поля на свойство или наоборот — тьма тьмущая.
Потому лучше сразу используйте синтаксические конструкции, специально для этого предназначенные.
Если вам в начале обучения это не очевидно, то это не повод отказаться от свойств. Лучше "с детства" учиться правильному пользованию инструментом, понимание придет потом — с опытом.
В худшем случае использовать поля у вас войдет в привычку, с которой в любой толковой команде вы долго не задержитесь, потому что никому не нужен коллега, лепящий в код бомбы замедленного действия.

Сообщение от Passerby

Судя по ответам не делать свойства - плохой тон.

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

Сообщение от Passerby

Но если усомниться в религии?

По вопросам религии — это наверное в церковь.
Или использование молотка вместо микроскопа для забивания гвоздей — это вопрос религии? Оба ведь тяжелые!

@КОП · 27.06.2018, 17:02

Сообщение от Passerby

Да, пример интересный.
Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности. Кроме уже упомянутых 1,2,3. Или для программ не разбитых на блоки, некоторые из которых предназначены для других пользователей, простые типы не надо заранее объявлять свойствами. Судя по ответам не делать свойства - плохой тон. Но если усомниться в религии?

Сомневаться в религии бывает очень полезно, у вас неплохо получается)

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

@sldp · 27.06.2018, 17:26

Passerby, Хватит в микропримерах а-ля "Привет мир!" искать весь потенциал тех или иных конструкций языка. При этом с минимальным временем жизни проекта. Здесь все хорошо. Но вот только на практике очень часто автосвойста перерастают в обычные свойства с доп проверкой или вызовом методов или еще чем-то. И в этом случае вы просто пересоберёте свой код. Все остальное продолжит работать. А в случае изменения поля на свойства, даже с тем же именем, все сборки, зависящие от вашего класса, нужно будет пересобирать.
Учитесь писать сразу грамотно, а не "вот когда будет большой проект" или "вот когда я буду работать в команде", а пока могу смело ставить паблик поля и, например, пол человека хранить в булевой переменной, а не в перечислении. Почему нет?!

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

@Passerby · 27.06.2018, 17:38

Сообщение от kolorotur

Пример со структурой выше — проще некуда.

Я говоря о простых типах имел в виду: https://docs.microsoft.com/ru-... -variables "Типы значений в C# подразделяются на простые типы..."

Сообщение от kolorotur

А багов, связанных с заменой поля на свойство или наоборот — тьма тьмущая.

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

Сообщение от КОП

Тогда вам нужно привести аргумент в пользу открытых полей,

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

Сообщение от Passerby

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

Добавлено через 8 минут

Сообщение от sldp

Хватит в микропримерах а-ля "Привет мир!" искать весь потенциал тех или иных конструкций языка. При этом с минимальным временем жизни проекта.

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

@kolorotur · 27.06.2018, 17:45

Сообщение от Passerby

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

Под сторонними пользователями подразумевается не дядя Вася из соседнего отдела, а ваш собственный, написанный вами же код, который тупо перестанет работать.
Чтобы далеко не ходить — банальная сериализация. Если она бинарная, то тип вообще перестанет десериализироваться, т.е. вы потеряете данные.
И таких "нюансиков" — море, в зависимости от используемых библиотек.

Сообщение от Passerby

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

Примеров вам уже на две страницы привели, просто после каждого раза вы добавляете "а если кроме этого?", о чем свидетельствует довольно распухший список "условий".
Простые типы в программе, не состоящей из блоков, часть которых не предназначена для сторонних пользователей — это типы в такой программе, которая никому не нужна, даже вам. Т.к. ничего не будет делать, ибо простейший класс — это уже блок, а сторонний пользователь — это ваш же другой класс.
Если же у вас вся программа состоит из одного класса, то бога ради — используйте поля. Но и открытыми их в этом случае делать смысла нет.

Сообщение от Passerby

Только слова "надо"... - это я и называл религией.

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

@Passerby · 27.06.2018, 18:54

Сообщение от kolorotur

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

Действительно каждый раз добавляю : уже набралось: простой тип и проект - программа не разбитая на блоки. Цитату, пожалуйста, из примеров на две страницы.

Сообщение от kolorotur

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

Когда вы говорили о блоках, в которых применение свойств не вызывает сомнений, речь шла не о всех классах, из которых состоит программа, а из тех которые скомпилированы и замена полей на свойства потребует их перекомпиляции. Сейчас же вы называете тем же словом и классы не вынесенные в скомпилированный блок. Это называется подмена понятий. Или вы считаете, что программа не составленная из несколько скомпилированных блоков никому не нужна?

Сообщение от kolorotur

Потому, действительно, на данном этапе просто примите это как "надо".

Сильный аргумент.

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 12:24	21
	Хорошо, вы делаете проект с простыми свойствами. Выкладываете его в открытый доступ для использования. Затем решаете прикрутить к свойству функцию для ее использования пользователями. Если пользователь не хочет этой функцией пользоваться, то ему что старый проект, что новый - все равно. Если же он захочет такой функцией воспользоваться (узнать сколько раз было обращение к свойству, к примеру), то ему в любом случае придется перекомпилировать свой код. Т.е. только в том случае, если пользователь захочет задействовать ваш новый проект, но не задействовать его новые возможности ему не потребуется компиляция. Вопрос про замену свойств полями компилятором повторил, т.к. казалось, что где-то читал, что компилятор это делает. Вероятно, ошибся. Спасибо за ответы. 0

@КОП 1123 / 794 / 219 Регистрация: 15.08.2010 Сообщений: 2,185
	27.06.2018, 12:40	22
	Сообщение от Passerby Если пользователь не хочет этой функцией пользоваться, то ему что старый проект, что новый - все равно. он продолжает юзать свойство, которое работает ровно так как описано в моих доках. Сообщение от Passerby Если же он захочет такой функцией воспользоваться эта функция (деталь реализации) нужна МНЕ, конечный пользователь вообще не будет в курсе изменений. И не должен Сообщение от Passerby если пользователь захочет задействовать ваш новый проект вот найдут у вас дыру в безопасности или просто баг критичный, тогда все захотят разом и быстро) Добавлено через 7 минут Сообщение от Passerby то ему в любом случае придется перекомпилировать свой код. благо если просто перекомпилировать, а если перестанет компилиться, или сайдэффект будет без предупреждений 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 13:05	23
	Сообщение от КОП эта функция (деталь реализации) нужна МНЕ, конечный пользователь вообще не будет в курсе изменений. И не должен Итак, свойства нужны только в том случае, если выполняются сразу: 1. Проект это не вся программа. 2. Проект делается для его использования другими. 3. Если есть предположение повышения безопасности проекта изменением его свойств. 0

@КОП 1123 / 794 / 219 Регистрация: 15.08.2010 Сообщений: 2,185
	27.06.2018, 13:31	25
	Сообщение от Passerby Итак, свойства нужны только в том случае, если выполняются сразу: это буквально пара дополнительных нажатий клавиш, почему надо так долго обосновывать преимущества свойств ради этой пары кликов? Вопрос из ряда зачем писать качественный код, если его буду видеть только я. Тут мои полномочия всё 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 15:13	28
	Сообщение от kolorotur Во всех, не связанных с очень редкими ситуациями Ситуации, когда требуется свойство я описал выше: Зачем нужны автоматически реализуемые свойства? Я неправ или для вас ситуация, когда код компилируется полностью в программу, а не в модуль для его использования другими очень редкий случай? 0

@Богдан всепытный 10 / 18 / 4 Регистрация: 10.11.2017 Сообщений: 283
		1
	Зачем нужны автоматически реализуемые свойства? 25.06.2018, 23:56. Показов 3984. Ответов 55 Метки нет (Все метки) Зачем нужны автоматически реализуемые свойства в c#? Что, нельзя просто пометить поле как public? Зачем надо, чтобы доступ получался только через get и set, если в них нет никаких фильтров, ничего? 0

@Toros1992 899 / 554 / 275 Регистрация: 26.11.2015 Сообщений: 1,758 Записей в блоге: 2
	27.06.2018, 13:20	24
	Свойствами надо делать все, что хоть как-то будет соприкасаться с другими объектами. Помимо вышеописанных выгод, свойства позволяют осуществлять привязку данных, хранящихся в этих свойствах к элементам управления, например. Приватное поле - это какая-то инфа, влияющая на сугубо внутреннюю реализацию поведения (коэффициенты, констаны, внутренние объекты, и т.д.) Свойства - это одна из самых широко-используемых вещей. Не по теме: Сообщение от Passerby Итак, свойства нужны только в том случае, если выполняются сразу: 1. Проект это не вся программа. 2. Проект делается для его использования другими. 3. Если есть предположение повышения безопасности проекта изменением его свойств. Применение свойств можно ограничить тремя пунктами только примерно в такой классификации: 1. Фронтенд 2. Бэкенд 3. Фуллстак 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 13:49	26
	Сообщение от КОП это буквально пара дополнительных нажатий клавиш, почему надо так долго обосновывать преимущества свойств ради этой пары кликов? Если эти преимущества для данного проекта есть. А если не выполняется что-то из перечисленного 1,2,3? И пара кликов, это только для одного свойства. И скорость чтения кода и скорость нахождения нужного фрагмента: ведь, не только закладками, но и скрулом пользуетесь. Сообщение от КОП Вопрос из ряда зачем писать качественный код Нет. Вопрос в том, в каких случаях код более качественный, если использовать свойства, а в каких нет. Еще раз спасибо, что помогли разобраться. По делу все понятно, а предпочтения у всех разные. 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	27.06.2018, 14:36	27
	Сообщение от Passerby Вопрос в том, в каких случаях код более качественный, если использовать свойства, а в каких нет. Во всех, не связанных с очень редкими ситуациями, где нужно иметь открытое поле для работы с неуправляемым кодом или для интеграции с неуправляемыми системами. В целом же свойства — это такой же элемент архитектуры, как и классы: они нужны для изоляции деталей реализации. Семантически поле — это деталь реализации, до которой никому кроме автора класса нет дела, а свойство — это элемент взаимодействия с другими типами данных. 0

@Toros1992 899 / 554 / 275 Регистрация: 26.11.2015 Сообщений: 1,758 Записей в блоге: 2
	27.06.2018, 15:18	29
	Passerby, Вы неправы. Свойства не только в этих случаях используются. Они используются везде. Для привязки данных, инкапсуляции, переопределения логики свойств у наследников... 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 15:38	30
	Сообщение от Toros1992 Они используются везде. Для привязки данных, инкапсуляции, переопределения логики свойств у наследников... Что не позволит в случае надобности заменить поле свойством в случаях не описанных мной? 0

@Toros1992 899 / 554 / 275 Регистрация: 26.11.2015 Сообщений: 1,758 Записей в блоге: 2
	27.06.2018, 16:01	32
	КОП, Блин интересно... А не поясните, почему так? 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	27.06.2018, 16:06	33
	Сообщение от Toros1992 почему так? Потому что S — значимый тип, копируется при возвращении из свойства. 1

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 16:35	34
	Да, пример интересный. Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности. Кроме уже упомянутых 1,2,3. Или для программ не разбитых на блоки, некоторые из которых предназначены для других пользователей, простые типы не надо заранее объявлять свойствами. Судя по ответам не делать свойства - плохой тон. Но если усомниться в религии? 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	27.06.2018, 17:01	35
	Сообщение от Passerby Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности. Пример со структурой выше — проще некуда. Заметили бы вы получившийся баг, просто глядя на код? А реальная программа будет состоять из гораздо большего количества кода и баг, как это всегда бывает, всплывет в самый неудачный момент. А багов, связанных с заменой поля на свойство или наоборот — тьма тьмущая. Потому лучше сразу используйте синтаксические конструкции, специально для этого предназначенные. Если вам в начале обучения это не очевидно, то это не повод отказаться от свойств. Лучше "с детства" учиться правильному пользованию инструментом, понимание придет потом — с опытом. В худшем случае использовать поля у вас войдет в привычку, с которой в любой толковой команде вы долго не задержитесь, потому что никому не нужен коллега, лепящий в код бомбы замедленного действия. Сообщение от Passerby Судя по ответам не делать свойства - плохой тон. Дело не в тоне, а в использовании инструментов, созданных для решения определенных задач и в огромном количестве проблем, связанных с неиспользованием этих инструментов. Сообщение от Passerby Но если усомниться в религии? По вопросам религии — это наверное в церковь. Или использование молотка вместо микроскопа для забивания гвоздей — это вопрос религии? Оба ведь тяжелые! 0

	27.06.2018, 18:54

@КОП 1123 / 794 / 219 Регистрация: 15.08.2010 Сообщений: 2,185
	27.06.2018, 17:02	36
	Сообщение от Passerby Да, пример интересный. Но для простых типов можете привести пример невозможности превращения поля в свойство, в случае надобности. Кроме уже упомянутых 1,2,3. Или для программ не разбитых на блоки, некоторые из которых предназначены для других пользователей, простые типы не надо заранее объявлять свойствами. Судя по ответам не делать свойства - плохой тон. Но если усомниться в религии? Сомневаться в религии бывает очень полезно, у вас неплохо получается) Тогда вам нужно привести аргумент в пользу открытых полей, а то одностороннее получается. И предупреждая возможный аргумент: экономия 2х машинальных нажатий будет съедена временем на придумывание названия переменной. 0

@sldp 309 / 317 / 119 Регистрация: 29.10.2011 Сообщений: 1,006
	27.06.2018, 17:26	37
	Passerby, Хватит в микропримерах а-ля "Привет мир!" искать весь потенциал тех или иных конструкций языка. При этом с минимальным временем жизни проекта. Здесь все хорошо. Но вот только на практике очень часто автосвойста перерастают в обычные свойства с доп проверкой или вызовом методов или еще чем-то. И в этом случае вы просто пересоберёте свой код. Все остальное продолжит работать. А в случае изменения поля на свойства, даже с тем же именем, все сборки, зависящие от вашего класса, нужно будет пересобирать. Учитесь писать сразу грамотно, а не "вот когда будет большой проект" или "вот когда я буду работать в команде", а пока могу смело ставить паблик поля и, например, пол человека хранить в булевой переменной, а не в перечислении. Почему нет?! Есть паблик ридонли поля. Когда и константа не подходит, ибо значение зависящее, и свойства, ибо тогда для внешнего кода нет гарантии, что значение не изменится. 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 17:38	38
	Сообщение от kolorotur Пример со структурой выше — проще некуда. Я говоря о простых типах имел в виду: https://docs.microsoft.com/ru-... -variables "Типы значений в C# подразделяются на простые типы..." Сообщение от kolorotur А багов, связанных с заменой поля на свойство или наоборот — тьма тьмущая. Так приведите один для простого типа, для случая программы не состоящей из блоков, часть которых предназначен для сторонних пользователей. Сообщение от КОП Тогда вам нужно привести аргумент в пользу открытых полей, Во-первых я не высказываюсь в чью-то пользу, а хочу понять. И пока здесь не приведено ни одного аргумента в пользу использования свойств для простых типов для случая программы не состоящей из блоков, часть которых предназначен для сторонних пользователей. Кроме тренировки использования свойств. Только слова "надо"... - это я и называл религией. А во-вторых все же аргументы приводил: Сообщение от Passerby И пара кликов, это только для одного свойства. И скорость чтения кода и скорость нахождения нужного фрагмента: ведь, не только закладками, но и скрулом пользуетесь. Добавлено через 8 минут Сообщение от sldp Хватит в микропримерах а-ля "Привет мир!" искать весь потенциал тех или иных конструкций языка. При этом с минимальным временем жизни проекта. Хватит в глобальных примерах, а-ля крупнейший проект для концерна с огромным временем жизни, искать шаблоны для применения в других проектах. Участники, судя по количеству просмотров, вопрос темы интересует не только меня. Давайте не начинать флейм. 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	27.06.2018, 17:45	39
	Сообщение от Passerby Так приведите один для простого типа, для случая программы не состоящей из блоков, часть которых предназначен для сторонних пользователей. Под сторонними пользователями подразумевается не дядя Вася из соседнего отдела, а ваш собственный, написанный вами же код, который тупо перестанет работать. Чтобы далеко не ходить — банальная сериализация. Если она бинарная, то тип вообще перестанет десериализироваться, т.е. вы потеряете данные. И таких "нюансиков" — море, в зависимости от используемых библиотек. Сообщение от Passerby пока здесь не приведено ни одного аргумента в пользу использования свойств для простых типов для случая программы не состоящей из блоков, часть которых предназначен для сторонних пользователей. Примеров вам уже на две страницы привели, просто после каждого раза вы добавляете "а если кроме этого?", о чем свидетельствует довольно распухший список "условий". Простые типы в программе, не состоящей из блоков, часть которых не предназначена для сторонних пользователей — это типы в такой программе, которая никому не нужна, даже вам. Т.к. ничего не будет делать, ибо простейший класс — это уже блок, а сторонний пользователь — это ваш же другой класс. Если же у вас вся программа состоит из одного класса, то бога ради — используйте поля. Но и открытыми их в этом случае делать смысла нет. Сообщение от Passerby Только слова "надо"... - это я и называл религией. Очень сложно объяснить даже студенту-программисту огромнейшую важность для программиста такого предмета, как дискретная математика. Можно лишь научить и сказать "надо", а озарение придет намного позже — зачастую уже на месте работы. Потому, действительно, на данном этапе просто примите это как "надо". 0

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242
	27.06.2018, 18:54	40
	Сообщение от kolorotur Примеров вам уже на две страницы привели, просто после каждого раза вы добавляете "а если кроме этого?", о чем свидетельствует довольно распухший список "условий". Действительно каждый раз добавляю : уже набралось: простой тип и проект - программа не разбитая на блоки. Цитату, пожалуйста, из примеров на две страницы. Сообщение от kolorotur Простые типы в программе, не состоящей из блоков, часть которых не предназначена для сторонних пользователей — это типы в такой программе, которая никому не нужна, даже вам. Т.к. ничего не будет делать, ибо простейший класс — это уже блок, а сторонний пользователь — это ваш же другой класс. Когда вы говорили о блоках, в которых применение свойств не вызывает сомнений, речь шла не о всех классах, из которых состоит программа, а из тех которые скомпилированы и замена полей на свойства потребует их перекомпиляции. Сейчас же вы называете тем же словом и классы не вынесенные в скомпилированный блок. Это называется подмена понятий. Или вы считаете, что программа не составленная из несколько скомпилированных блоков никому не нужна? Сообщение от kolorotur Потому, действительно, на данном этапе просто примите это как "надо". Сильный аргумент. 0