Лучшая практика:Свойства доступа или методы без параметров?

Question

Какая практика лучше и почему?

bool IsTodayMonday { get { return DateTime.Now.DayOfWeek == DayOfWeek.Monday; } }

Или

bool IsTodayMonday()
{
    return DateTime.Now.DayOfWeek == DayOfWeek.Monday;
}

Answer 1

Для меня - в данном конкретном случае - это вообще не имеет значения.

Если вы посмотрите на сгенерированный IL-код, вы заметите, что это точно одинаковый.Свойство приведет к созданию метода, который создает тот же IL-код.

Что касается реализаций .Net, вам, вероятно, следует использовать это свойство.Платформа .Net использует свойства для IsXXX-Functionality, когда параметр не используется, в противном случае она использует методы, если только некоторые другие факторы не указывают на то, что использование метода является более подходящим.(примеры см. в посте выше)

Это IL-код, созданный обеими версиями, если вам интересно (я использовал простое консольное приложение и статические методы/свойства).

{
  // Code size       22 (0x16)
  .maxstack  2
  .locals init ([0] bool CS$1$0000,
           [1] valuetype [mscorlib]System.DateTime CS$0$0001)
  IL_0000:  nop
  IL_0001:  call       valuetype [mscorlib]System.DateTime [mscorlib]System.DateTime::get_Now()
  IL_0006:  stloc.1
  IL_0007:  ldloca.s   CS$0$0001
  IL_0009:  call       instance valuetype [mscorlib]System.DayOfWeek [mscorlib]System.DateTime::get_DayOfWeek()
  IL_000e:  ldc.i4.1
  IL_000f:  ceq
  IL_0011:  stloc.0
  IL_0012:  br.s       IL_0014
  IL_0014:  ldloc.0
  IL_0015:  ret
} // end of method Program::get_IsTodayProp

Ваше здоровье!

Answer 2

На мой взгляд, используйте свойства в этих ситуациях, если:

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

В вашем примере я бы выбрал свойство.

Answer 3

Свойство должно быть довольно тривиальной оболочкой значения.Для пользователя свойства оно должно действовать как переменная.

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

Помимо этого, это больше зависит от личных предпочтений (считаете ли вы, что свойства должны представлять только конкретные переменные-члены или их можно использовать для чтения «расчетных значений», таких как в вашем примере).

Answer 4

В целом:

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

Если вы не можете использовать вариант №1, вам следует использовать методы get/set;т.е.:

bool getIsTodayMonday()
void setIsTodayMonday(bool timetravelingArgument)

Конкретно ваш пример

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

Answer 5

Я бы сказал, что IsTodayMonday больше похож на метод, чем на свойство, поэтому я бы выбрал второй вариант. См. Метод и свойство в C# – в чем разница хороший пример того, когда использовать свойства вместо методов.

Answer 6

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

Или с точки зрения пользователя:Я бы не возражал против многократного доступа к obj.IsTodayMonday, поскольку предполагаю, что для этого не нужны тяжелые вычисления.В случае obj.IsTodayMonday() я бы подумал о кэшировании и повторном использовании результата.

Но я, конечно, именно так и пишу код.Это зависит от вашей политики.

Answer 7

Clock.IsTodayMonday подсказывает мне, что это не имеет побочных эффектов или вычислений.

Clock.IsTodayMonday() указывает на то, что могут иметь место побочные эффекты или вычисления.

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

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

Answer 8

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

Answer 9

Вы рассмотрели

public static bool IsMonday(DateTime date)
{
    return date.DayOfWeek == DayOfWeek.Monday;
}

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

Answer 10

У меня около двадцати лет опыта разработки программного обеспечения в качестве консультанта в ряде различных компаний, а также я работал в OEM-компании.Для меня этот вопрос больше похож на вопрос политики компании (руководства по кодированию), и если какая-либо компания хочет выбрать методы, которые помогут создавать простые для понимания, простые в отладке и чтении методы, тогда им следует выбрать использование Get/Set вместо свойств.Это связано с тем, что, например, при отладке вызывающего класса, который использует свойство из другого класса, создается впечатление, что потенциально плохо обрабатывается доступ к общедоступным переменным (ПЛОХО и выглядит опасно).С другой стороны, если бы вы увидели там вызов метода Getter/Setter, вы бы сразу ЗНАЛИ, что это не доступ к общедоступной переменной и что существует функция, обрабатывающая вызов, и она может даже возвращать код ошибки или исключение. , если так выбрано.Любое руководство по кодированию или выбор практики должны основываться на том факте, что этот выбор лучше помогает программистам писать быстро понятный, надежный (безопасный), переносимый, простой и симметричный код, удобный для отладки.А должны ли быть какие-то другие причины?