Свойства против методов - PullRequest
118 голосов
/ 02 марта 2009

Быстрый вопрос: когда вы решили использовать свойства (в C #) и когда вы решили использовать методы?

Мы заняты этой дискуссией и нашли некоторые области, в которых можно спорить, следует ли нам использовать свойство или метод. Один из примеров:

public void SetLabel(string text)
{
    Label.Text = text;
}

В этом примере Label - это элемент управления на странице ASPX. Существует ли принцип, который может регулировать решение (в данном случае), делать ли это методом или свойством.

Я приму ответ, который является наиболее общим и всеобъемлющим, но также затрагивает приведенный мной пример.

Ответы [ 16 ]

3 голосов
/ 02 марта 2009

Я предпочитаю использовать свойства для методов добавления / установки с параметром 1 . Если параметров больше, используйте методы.

2 голосов
/ 02 марта 2009

С точки зрения дизайна, свойства представляют данные или атрибуты объекта класса, а методы - действия или поведения объекта класса.

В мире .Net существуют другие последствия использования свойств:

  • Свойства используются в привязке данных, а методы get_ / set_ - нет.
  • Пользовательские свойства XML-сериализации как естественный механизм сериализации.
  • Свойства доступны через PropertyGrid control и intern ICustomTypeDescriptor , которые можно эффективно использовать при написании пользовательской библиотеки.
  • Свойства контролируются Атрибутами , их можно использовать с умом для разработки программного обеспечения с ориентацией на аспекты.

Заблуждения (IMHO) об использовании свойств:

  • Используется для выставления небольших вычислений: ControlDesigner.SelectionRules блок get состоит из 72 строк !!
  • Используется для раскрытия внутренних структур данных. Даже если свойство не отображается на внутренний элемент данных, его можно использовать как свойство, если оно является атрибутом вашего класса. Viceversa, даже если его атрибут свойств вашего класса не рекомендуется, возвращать массив как члены данных (вместо этого используются методы для возврата глубокой копии членов.)

В приведенном здесь примере это могло бы быть написано с большим деловым значением как:

public String Title
{
    set { Label.Text = text; }
}
2 голосов
/ 02 марта 2009

Свойства действительно хороши, потому что они доступны в визуальном дизайнере Visual Studio при условии, что у них есть доступ.

Они используются, если вы просто устанавливаете и получаете и, возможно, некоторую проверку, которая не дает доступа к значительному объему кода. Будьте осторожны, поскольку создание сложных объектов во время проверки не является простым.

Любые другие методы являются предпочтительным способом.

Дело не только в семантике. Использование неуместных свойств может привести к появлению странностей в визуальном дизайнере визуальной студии.

Например, я получал значение конфигурации в свойстве класса. Класс конфигурации фактически открывает файл и запускает sql-запрос, чтобы получить значение этой конфигурации. Это вызвало проблемы в моем приложении, когда файл конфигурации открывался и блокировался самой Visual Studio, а не моим приложением, потому что он не только считывал, но и записывал значение конфигурации (через метод setter). Чтобы это исправить, мне просто нужно было изменить его на метод.

1 голос
/ 13 августа 2012

Вот хороший набор рекомендаций о том, когда использовать свойства и методы из Билла Вагнера

  • Используйте свойство, когда все это верно: Получатели должны быть простыми и, таким образом, вряд ли будут генерировать исключения. Обратите внимание, что это подразумевает отсутствие доступа к сети (или базе данных). Любой из них может потерпеть неудачу и, следовательно, вызовет исключение.
  • Они не должны зависеть друг от друга. Обратите внимание, что это будет включать установку одного свойства и его влияние на другое. (Например, установка свойства FirstName повлияет на доступное только для чтения свойство FullName, которое состоит из свойств имени + фамилии, что подразумевает такую ​​зависимость)
  • Они должны быть установлены в любом порядке
  • Получатель не имеет наблюдаемого побочного эффекта. Обратите внимание, что это руководство не исключает некоторые формы отложенной оценки свойства.
  • Метод всегда должен возвращаться немедленно. (Обратите внимание, что это исключает свойство, которое выполняет вызов доступа к базе данных, вызов веб-службы или другие подобные операции).
  • Используйте метод, если член возвращает массив.
  • Повторные вызовы получателя (без промежуточного кода) должны возвращать одно и то же значение.
  • Повторные вызовы для установщика (с тем же значением) не должны давать различий от одного вызова.

  • Метод get не должен возвращать ссылку на внутренние структуры данных (см. Пункт 23). Метод может вернуть глубокую копию и избежать этой проблемы.

* Взято из моего ответа на дублирующий вопрос.

0 голосов
/ 07 февраля 2019

Это просто.

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

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

0 голосов
/ 30 июня 2010

Я приехал из Явы и некоторое время использовал метод get .. set ..

Когда я пишу код, я не спрашиваю себя: «Доступ к этим данным прост или требует тяжелого процесса?» потому что все может измениться (сегодня восстановить это свойство просто, завтра может потребоваться какой-то или тяжелый процесс).

Сегодня у меня есть метод SetAge (int age), завтра у меня будет также метод SetAge (дата рождения), который вычисляет возраст, используя дату рождения.

Я был очень разочарован, что свойство преобразования компилятора в get и set, но не считает мои методы Get ... и Set .. одинаковыми.

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