Каковы лучшие альтернативы геттерам и сеттерам в C #?

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

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

var c = new Car();
c.Odometer += 10;  // bad
c.DriveMiles(10);  // good

Я также сомневаюсь, насколько эта статья применима к C #; он утверждает:

Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details.

В C # это неверно, средство доступа C # может принимать произвольные классы, они не «предоставляют внешний доступ к деталям реализации».

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

obj.Day = 28;
obj.Month = Months.February;
obj.Day = 30;
obj.Month = Months.March;

Как только я установил день на 30, а месяц - февраль, у меня недействительное состояние.

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

obj.ChangeDate(Months.March, 30);

Если аналогия даты и времени сбивает с толку из-за DateTime, у вас может быть аналогичный пример с координатами широты и долготы:

obj.Latitude = 45.4112;
obj.Longitude = -75.6981;
//... 
obj.Latitude = 39.73;
obj.Longitude = -86.27;

Когда для широты установлено значение 39,73, местоположение становится местом рядом с Ньюарком, а не с Оттавой (первая широта / долгота) или Индианаполисом (вторая широта / долгота). Если оставить настройки для lat / long, интерфейс останется открытым, и он не сможет проверить его инварианты, а некоторые могут сказать, что он не совсем объектно-ориентированный. Итак, вместо этого у вас может быть метод:

obj.MoveTo(39.73, -86.27);

ОО подразумевает как инкапсулированное состояние, так и поведение. Хотя некоторым может казаться, что свойства «инкапсулируют» состояние, обычно это не так. Они отделяют реализацию от интерфейса, так что то, что используется в качестве резервного хранилища свойств, может измениться, но это редко когда-либо; поэтому свойства просто предоставляют доступ к деталям реализации иначе, чем предоставляют общедоступные поля.

Существуют такие концепции, как разделение командных запросов, основанные на этой идее, которые предполагают, что интерфейс должен либо обновлять состояние, либо состояние запроса, но не то и другое вместе. Свойства с геттерами и сеттерами предоставляют интерфейс, который обновляет состояние и состояние запроса. Приведенные выше примеры MoveTo и ChangeDate будут «командами». По идее, вы должны предоставить другие способы запроса состояния; если это необходимо.

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

Тонкий? Конечно; но он говорит об объектно-ориентированном дизайне, а не о коде, который «просто работает».

Геттеры и сеттеры не являются злом, просто они не должны генерироваться автоматически для каждого атрибута. Что касается вашего примера, класс Car, вероятно, должен иметь метод getBrand, возвращающий String, но установщик для этого атрибута, вероятно, не нужен. Метод в Car, возвращающий TextBox с названием бренда, скорее всего, худшая идея, чем простой метод получения, возвращающий String, потому что он не очень общий.

Теперь я вижу ответ Питера Ричи: хороший пример с changeDate. Класс Date должен предоставлять подобный метод вместо того, чтобы предоставлять геттер для дня и месяца и требовать, чтобы пользовательский код самостоятельно вычислял следующий день в календаре.

По сути, он говорит, что у вас есть класс с десятью свойствами, и вы хотите сбросить его в строку csv. Добавьте в класс метод Tocsv, чтобы вернуть строку с кучей csvs в ней. Не пишите другой класс, который обращается к нему через свойства и строит строку csv, поскольку по необходимости они становятся очень тесно связанными.

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

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

SomeLabel.Text = SomeInstance.StringValue;

с участием

SomeInstance.MakeStringValueALabel(SomeLabel);