Лучшие методы получения, установки и свойства. Java против C # - PullRequest
88 голосов
/ 09 февраля 2011

Я сейчас учусь на C # и пытаюсь найти лучший способ сделать что-то. Я родом из Java, поэтому я знаком только с лучшими практиками Java; Я новичок в C #!

В Java, если у меня есть частная собственность, я делаю это;

private String name;

public void setName(String name) {
   this.name = name;
}

public String getName() {
   return this.name;
}

В C # я вижу, что есть много способов сделать это.

Я могу сделать это как Java:

private string name;

public void setName(string name) {
   this.name = name;
}

public string getName() {
   return this.name;
}

Или я могу сделать это так:

private string name;

public string Name {
   get { return name; }
   set { name = value; }
}

Или:

public string Name { get; set; }

Какой из них мне следует использовать, и какие предостережения или тонкости связаны с каждым подходом? При создании классов я следую общим рекомендациям, которые я знаю по Java (особенно читаю Effective Java). Так, например, я предпочитаю неизменность (предоставляя сеттеры только при необходимости). Мне просто любопытно посмотреть, как эти методы сочетаются с различными способами предоставления сеттеров и геттеров в C #; по сути, как бы я перевел лучшие практики из мира Java в C #?

EDIT

Я публиковал это как комментарий к ответу Джона Скита, но потом он стал длинным:

А как насчет нетривиального свойства (т. Е. Со значительной обработкой и проверкой, возможно)? Могу ли я по-прежнему предоставлять его через открытое свойство, но с логикой, инкапсулированной в get и set? Почему я должен / должен делать это, имея выделенные методы установки и получения (с соответствующей логикой обработки и проверки).

Ответы [ 12 ]

2 голосов
/ 09 февраля 2011

, как и большинство ответов здесь, используйте автоматические свойства.Интуитивно понятный, меньше строк кода и он более чистый.Если вам нужно сериализовать ваш класс, пометьте класс [Serializable] / атрибутом [DataConract].И если вы используете [DataContract], отметьте участника как

[DataMember(Name="aMoreFriendlyName")]
public string Name { get; set; }

Частный или общедоступный сеттер зависит от ваших предпочтений.

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

/*this is invalid*/
public string Name 
{ 
    get; 
   /* setter omitted to prove the point*/
}

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

0 голосов
/ 28 ноября 2018

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

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

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

obj.getItems(filter);

В отличие от свойства, вы вынуждены сначала вернуть все элементы

obj.items

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

obj.itemsFilteredByX
obj.itemsFilteredByY

Иногда бывает неприятно, когда вы начинаете со свойством, например obj.itemsа затем обнаружил, что параметризация getter- или setter-необходима или облегчит работу для пользователя API класса.Теперь вам нужно либо переписать свой API и изменить все те места в вашем коде, которые обращаются к этому свойству, либо найти альтернативное решение.Напротив, с помощью get-метода, например obj.getItems(), вы можете просто расширить сигнатуру вашего метода, чтобы принять необязательный объект «конфигурации», например obj.getItems(options), без необходимости переписывать все те места, которые вызывают ваш метод.

* 1020Как уже говорилось, (автоматически реализованные) свойства в C # по-прежнему являются очень полезными ярлыками (по различным причинам, упомянутым здесь), поскольку большая часть времени параметризации может не потребоваться - но это предостережение стоит.
...