Когда лучше использовать метод по сравнению со свойством для определения класса?

Question

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

В случае свойства, скажем, public string DataAsString, средство доступа get будет содержать логику для кодирования всех данных.в строку, в то время как метод доступа set будет декодировать входное значение и установить все данные в экземпляре класса.Это кажется удобным, потому что ввод / вывод действительно является строкой.

В случае метода одним методом будет Encode(), который возвращает закодированную строку.Затем либо сам конструктор будет содержать логику для декодирования строки и потребует строковый аргумент, либо я напишу метод Decode(string str), который вызывается отдельно.В любом случае он будет использовать метод вместо свойства.

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

Answer 1

Функциональной разницы нет; свойства - это просто пары методов get и set с точки зрения поведения.

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

Есть очевидные исключения из этого (а именно ленивая загрузка в области ORM, где get может вызвать вызов базы данных).

Answer 2

«Существительные»: Соглашение состоит в том, что свойства не выполняют реальной бизнес-логики и не имеют побочных эффектов, то есть изменяют состояние объекта (кроме Задания значения).

"Глаголы: методы должны работать и иметь побочные эффекты.

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

Answer 3

Технически они могут делать то же самое. Как правило, если требуется сложная обработка, я помещаю ее в метод, а не в свойство. Основная причина этого (хотя я не говорю, что люди должны это принимать) состоит в том, что существует общее представление о том, что свойства должны обеспечивать быстрый доступ к данным, когда вызов метода предполагает, что может потребоваться несколько циклов полный. Должны ли люди предполагать это? Определенно нет, но они делают.

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

Answer 4

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

Answer 5

Еще один момент, который не упоминается, заключается в том, что если одно или несколько свойств чтения-записи в объекте записаны, а затем все считаны обратно без каких-либо промежуточных вызовов метода, прочитанные значения должны соответствовать записанным значениям. Если запись свойства Foo приведет к изменению значения свойства чтения-записи Bar, на мой взгляд, будет хорошим признаком того, что один или другой должен быть парой явных методов получения-установки, а не свойством. В .net существует множество классов, которые нарушают этот принцип, но я считаю такое поведение небрежным. Возможно, худшим нарушителем является свойство Visible Control. Запись свойства обновляет поле, состояние которого не может быть прочитано, а чтение свойства возвращает результат некоторых вычислений. Лучше было бы иметь свойство Hidden для чтения и записи и поле Visible только для чтения. Кстати, на слегка похожей ноте я бы сделал свойство «Длина» объекта StringBuilder только для чтения, но имел бы методы для его усечения или дополнения; единственное свойство чтения-записи, которое у меня было бы, было Value.

Answer 6

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

Давайте возьмем, например, класс Person Person.Name имеет смысл как свойство в этом случае. Person.Speak () не имеет смысла как свойство.

Все зависит от того, какую функцию он выполняет.