Свойства vs Методы

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

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

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

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

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

Из раздела « Выбор между свойствами и методами » Руководства по разработке для разработки библиотек classов:

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

Да, если все, что вы делаете, это получение и настройка, используйте свойство.

Если вы делаете что-то сложное, что может повлиять на несколько членов данных, метод более подходит. Или, если ваш получатель принимает параметры, или ваш сеттер принимает больше значения параметра.

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

Они в значительной степени взаимозаменяемы, но свойство сигнализирует пользователю о том, что реализация является относительно «простой». О, и синтаксис немного чище.

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

Если вы устанавливаете фактическое свойство своего объекта, вы используете свойство.

Если вы выполняете задачу / функциональность, вы используете метод.

В вашем примере это определенное свойство.

Если, однако, ваша функциональность была в AppendToLabel, вы бы использовали метод.

Свойства – это способ ввода или извлечения данных из объекта. Они создают абстракцию над переменными или данными внутри classа. Они аналогичны геттерам и сеттерам на Java.

Методы инкапсулируют операцию.

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

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

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

 public Label Title { get{ return titleLabel;} set{ titleLabel = value;} } 

Настройка текста:

 Title.Text = "Properties vs Methods"; 

Если бы я только установил свойство Text метки, я бы это сделал:

 public string Title { get{ return titleLabel.Text;} set{ titleLabel.Text = value;} } 

Настройка текста:

 Title = "Properties vs Methods"; 

Вам нужно только посмотреть на самое имя … «Свойство». Что это значит? Словарь определяет его разными способами, но в этом случае «существенный или отличительный атрибут или качество вещи» подходит лучше всего.

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

Свойства действительно являются функциями. Все они сводятся к getXXX () и setXXX (). Он просто скрывает их в синтаксическом сахаре, но это сахара, который дает семантический смысл процессу.

Подумайте о свойствах, таких как атрибуты. У автомобиля много атрибутов. Цвет, MPG, Модель и т. Д. Не все свойства можно настроить, некоторые из них рассчитаны.

Между тем, метод – это действие. GetColor должен быть собственностью. GetFile () должна быть функцией. Другое эмпирическое правило: если оно не изменяет состояние объекта, то оно должно быть функцией. Например, CalculatePiToNthDigit (n) должен быть функцией, потому что он фактически не изменяет состояние объекта Math, к которому он привязан.

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

Симпатичные свойства – это атрибуты ваших объектов. Методы – это поведение вашего объекта.

Ярлык является атрибутом, и имеет смысл сделать его собственностью.

Что касается объектно-ориентированного программирования, вы должны иметь четкое представление о том, что является частью поведения и что является просто атрибутом.

Автомобиль {Цвет, Модель, Бренд}

У автомобиля есть атрибуты Color, Model и Brand, поэтому не имеет смысла использовать метод SetColor или SetModel, потому что мы не просим Car задать собственный цвет.

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

Поиск через MSDN я нашел ссылку на Свойства vs Методы, которая предоставляет некоторые отличные рекомендации по созданию методов:

  • Операция представляет собой преобразование, например Object.ToString .
  • Операция достаточно дорогая, что вы хотите сообщить пользователю, что они должны рассмотреть вопрос о кешировании результата.
  • Получение значения свойства с помощью get accessor будет иметь наблюдаемый побочный эффект.
  • Вызов члена дважды подряд дает разные результаты.
  • Порядок исполнения важен. Обратите внимание, что свойства типа должны быть установлены и извлечены в любом порядке.
  • Элемент статический, но возвращает значение, которое можно изменить.
  • Элемент возвращает массив. Свойства, возвращающие массивы, могут вводить в заблуждение. Обычно необходимо возвращать копию внутреннего массива, чтобы пользователь не мог изменить внутреннее состояние. Это, в сочетании с тем, что пользователь может легко предположить, что это индексированное свойство, приводит к неэффективному коду.

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

Свойства должны быть простыми и иметь один вкладыш. Что-нибудь еще, и это действительно нужно переместить в метод. Комплексный код всегда должен быть в методах.

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

Также большим плюсом для свойств является то, что значение свойства можно увидеть в Visual Studio во время отладки.

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

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

Все остальные методы являются предпочтительным способом.

Речь идет не только о семантике. Использование свойств неуместного старта, имеющего странность, возникает в визуальном дизайнере визуальной студии.

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

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

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

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

Неправильные представления (IMHO) об использовании свойств:

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

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

 public String Title { set { Label.Text = text; } } 

Я пришел из java, и я использовал get .. set .. method какое-то время.

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

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

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

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

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

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

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

  • Как выполнить итерацию свойств анонимного объекта в C #?
  • Свойства системы Java и переменные среды
  • Как получить список свойств classа?
  • Получить список свойств объекта в Objective-C
  • `def` vs` val` vs `lazy val` в Scala
  • appSettings vs applicationSettings. appSettings устарел?
  • Как перебрать все свойства classа?
  • Когда использовать свойства вместо функций
  • Загрузить файл свойств в JAR?
  • Определения @property с ARC: сильные или сохраняются?
  • Ошибка в classе Swift: свойство не инициализировано при вызове super.init
  • Давайте будем гением компьютера.