чем вот это
class DataItem
{
public int ID_DataItem {get; set;};
public string Data {get; set;};
}

лучше вот этого?

class DataItem
{
public int ID_DataItem;
public string Data;
}

Здравствуйте, Философ, Вы писали:

Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Тут есть 2 лагеря. Использование полей избавляет от косвенности и позволяет легче читать код. Использование автоматических свойств позволяет засунуть какую-нибудь логику в получение и установку значения поля.

Мой подход — это использовать поля до тех пор, пока не возникнет необходимость использовать свойства.

Здравствуйте, Философ, Вы писали:

Ф>skipped
В основном тем, что:
— в случае развития DataItem и появления логики при get/set (хотя бы банального INPC), код использующий DataItem, в первом варианте не сломается;
— некоторые технологии (как примеры — data binding, ORM) завязаны на использование свойств, а не полей.

Здравствуйте, Щъмых, Вы писали:

Щ>Мой подход — это использовать поля до тех пор, пока не возникнет необходимость использовать свойства.

Такой подход хорош, если код поддерживает один квалифицированный разработчик. Если с кодом работаете не только вы, то простейший рефакторинг "обернули поле в свойство" может вылезти боком где угодно — при сериализации, биндинге, рефлексии и т.п. Самое интересное, вылезти оно может _после_ того как вы добавите и оттестируете свойство, в какой-то момент в коде окажется

  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???

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

Здравствуйте, HowardLovekraft, Вы писали:

HL>- некоторые технологии (как примеры — data binding, ORM) завязаны на использование свойств, а не полей.
да, тут согласен.
однако решарпер "решает", т.к. сгенерить заготовки свойств для полей — секундное дело


HL>- в случае развития DataItem и появления логики при get/set (хотя бы банального INPC)
чиво?
что такое INPC?

HL>, код использующий DataItem, в первом варианте не сломается;
а в первом случае, что его сломает?

Здравствуйте, Sinix, Вы писали:

S>

S>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>

А вот такого я вообще никогда не понимал.
Зачем лишать компилятор возможности контроля ошибок?
А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?


S>В небольших проектах без публичного API такие вещи ещё реально отловить, в крупных — проще подстраховаться сразу и не вводить публичных полей без явной необходимости

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

Здравствуйте, Философ, Вы писали:

S>>

S>>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>>

Ф>А вот такого я вообще никогда не понимал.
Ф>Зачем лишать компилятор возможности контроля ошибок?
Ф>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?

Не понимайте так буквально. Например, перебор всех полей и проверка/передача их значений куда-либо и т. д. После смены "поле -> свойство" оно просто будет игнорироваться. Опять же — это только первый пришедший в голову пример. В общем — речь о том, что грабли могут полезть при использовании Reflection. Причем очень неявно.

Здравствуйте, Философ, Вы писали:

1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться


Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

что понимается под бинарной совместимостью?

Здравствуйте, Философ, Вы писали:

Ф>однако решарпер "решает", т.к. сгенерить заготовки свойств для полей — секундное дело
Решарпер нифига не решает, т.к. перечень используемых сторонних, и тем более, платных (сумма не важна) инструментов далеко не всегда определяет разработчик.

Ф>что такое INPC?
Ф>а в первом случае, что его сломает?
Сокращение от INotifyPropertyChanged.

Наиболее простое и очевидное, что может быть приделано к автосвойству (да еще и DataItem'а ), это логика в сеттере для реализации INPC (решили вы его в одно прекрасное утро привязать к какому-нибудь представлению):

Было:

class DataItem
{
    public int ID_DataItem {get; set;};
    public string Data {get; set;};
}

Стало:

class DataItem : INotifyPropertyChanged
{ 
    public int ID_DataItem 
    {
        get { return iD_DataItem; }
        set
        {
             if ( != value)
             {
                 iD_DataItem = value;
                 OnPropertyChanged("ID_DataItem");
             }
        }
    }

    // ...
}

Коду, использующему DataItem, безразлично, он как вызывал пару методов get_ID_DataItem/set_DataItem, так и продолжает вызывать.

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

void Foo(ref int someParam)
{
}

var item = new DataItem { ID_DataItem = 100 };

Foo(ref DataItem.ID_DataItem);

Заменили на свойство — получили ошибку компиляции.

И это если мы соблюдаем правило "внесли breaking changes — поменяли asembly version". А если еще и версию не поменяли, то в рантайме получим MissingFieldException, потому как раньше было обращение к полю, а теперь требуется вызов метода.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

Ф>что понимается под бинарной совместимостью?

Можно подменить библиотеку новой версией, не требуя перекомпиляции использующего ее кода

Здравствуйте, Философ, Вы писали:

Ф>А вот такого я вообще никогда не понимал.
Ф>Зачем лишать компилятор возможности контроля ошибок?
На практике ошибка может быть не так очевидна, это просто самый простой пример

Ф>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?
Ну, при убирании поля обычно проводят детальный просмотр кода. При оборачивании поля в свойство — наоборот, забывают.

Ф>вот я и спрашиваю, чем это может повредить, т.к. предыдущий пункт вообще не убедителен

Ну да, так и есть. Просто любые best practices работают по принципу бэкапа:
"Пользователи делятся на тех, кто еще не делает бекапы и тех, кто уже делает"

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

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Философ, Вы писали:

S>>>

S>>>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>>>

Ф>>А вот такого я вообще никогда не понимал.
Ф>>Зачем лишать компилятор возможности контроля ошибок?
Ф>>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?

Doc>Не понимайте так буквально. Например, перебор всех полей и проверка/передача их значений куда-либо и т. д. После смены "поле -> свойство" оно просто будет игнорироваться. Опять же — это только первый пришедший в голову пример. В общем — речь о том, что грабли могут полезть при использовании Reflection. Причем очень неявно.

Reflection — вообще одни сплошные грабли, и только из-за него смена поле/свойство — это breaking change.
поломать код можно и проще:
было
public int ID_DataItem {get; set;};
стало
public int ID_DataItem {get; private set;};

а теперь десереализуем

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Философ, Вы писали:

Ф>>что такое INPC?
HL>Сокращение от INotifyPropertyChanged.

я его использовал, мне сокращение не знакомо было.

HL>Заменили на свойство — получили ошибку компиляции.
Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

HL>И это если мы соблюдаем правило "внесли breaking changes — поменяли asembly version". А если еще и версию не поменяли, то в рантайме получим MissingFieldException, потому как раньше было обращение к полю, а теперь требуется вызов метода.

а вот об этом не подумал, спасибо.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, HowardLovekraft, Вы писали:

HL>>Здравствуйте, Философ, Вы писали:

Ф>>>что такое INPC?
HL>>Сокращение от INotifyPropertyChanged.

Ф>я его использовал, мне сокращение не знакомо было.

HL>>Заменили на свойство — получили ошибку компиляции.
Ф>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

Значит ты никогда не писал публичных АПИ. Вот представь что выпустили патч к .Net Framework, где нарушили бинарную совместимость

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, HowardLovekraft, Вы писали:

HL>>>Здравствуйте, Философ, Вы писали:

Ф>>>>что такое INPC?
HL>>>Сокращение от INotifyPropertyChanged.

Ф>>я его использовал, мне сокращение не знакомо было.

HL>>>Заменили на свойство — получили ошибку компиляции.
Ф>>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

ЕА>Значит ты никогда не писал публичных АПИ.

писал, почему же, но никогда в АПИ поля не выставлял наружу — как минимум был INPC, но чаще всего private/protected set.
к тому-же даже в публичных АПИ, даже от мелкософта можно встретить public fields
например Microsoft.Xna.Framework.Vector3 — хороший пример класса а-ля DataItem

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

Ф>>что понимается под бинарной совместимостью?

ЕА>Можно подменить библиотеку новой версией, не требуя перекомпиляции использующего ее кода

Где можно про это прочитать?

Здравствуйте, Философ, Вы писали:

Ф>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.
Эх...

Степень "ничего" обратно пропорциональна количеству человек, завязанных на этот код, и степени активности проекта.
Если вы вносите breaking changes (а замена поля на свойство — самое что ни на есть оно) в код, которым пользуется 1-3 человека, то, наверное, ничего страшного.
Если от этого зависит человек 50 хотя бы внутри вашей конторы, то в результате вам могут дать в бубен за срыв плана работ какого-то смежного подразделения, потому что им срочно нужно было исправить свои ошибки из-за ваших изменений, потом протестировать исправления, потом выпустить новую версию, которую потом нужно будет кому-то установить.

А если ваш код используют сотни, тысячи? В результате получается "опять эти индусы все поломали".

Здравствуйте, Философ, Вы писали:

Ф>Reflection — вообще одни сплошные грабли, и только из-за него смена поле/свойство — это breaking change.
Однако, без него всякие binding/mapper/undo-redo/ioc чота не пишутся.
Почему-то пока ничего лучшего никто не предложил.

Ф>поломать код можно и проще:
Ф>было
Ф>public int ID_DataItem {get; set;};
Ф>стало
Ф>public int ID_DataItem {get; private set;};
Ф>а теперь десереализуем
А вот это вы зря.
Правильный сериализатор такая мелочь не сломает. Он даже такое умеет десериализовывать:

public Collection<DataItem> Items
{
    get { return items ?? (item = new Collection<DataItem>()); } 
}
private readonly Collection<DataItem> items;

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Философ, Вы писали:

Ф>>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.
HL>Эх...

HL>Степень "ничего" обратно пропорциональна количеству человек, завязанных на этот код, и степени активности проекта.
HL>Если вы вносите breaking changes (а замена поля на свойство — самое что ни на есть оно) в код, которым пользуется 1-3 человека, то, наверное, ничего страшного.
HL>Если от этого зависит человек 50 хотя бы внутри вашей конторы, то в результате вам могут дать в бубен за срыв плана работ

Смена поля на свойство, как и любое изменение кода, делается не потому что левая пятка правой ноги так захотела, а потому что это реально понадобилось.
И раз уж это произошло, то в свойстве появилась какая-то логика.
Если все эти 50 человек завязаны на мой класс, то так или иначе им придётся тестировать свой код (тот же INPC иногда приводит к stack overflow)

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

Это их работа — править свои ошибки и выпускать новые версии.
А вы как хотели? Чтобы новая версия без тестирования вываливалась?


HL>А если ваш код используют сотни, тысячи? В результате получается "опять эти индусы все поломали".
демагогия