Мне нужно показать, что "отображается?" состояние экземпляра класса. Результат определяется базовой проверкой. Это не, просто отображая значение поля. Я не уверен, следует ли использовать свойство только для чтения или метод.
Свойство только для чтения:
public bool IsMapped
{
get
{
return MappedField != null;
}
}
Метод:
public bool IsMapped()
{
return MappedField != null;
}
Я прочитал MSDN Выбор между свойствами и методами, но я все еще не уверен.
В стандарте С# говорится
§ 8.7.4
A свойство - это член, который обеспечивает доступ к характеристике объекта или класса. Примеры свойств включают длину строки, размер шрифта, заголовок окна, имя клиента и т.д. Свойства являются естественным расширением полей. Оба они называются членами со связанными типами, а синтаксис для доступа к полям и свойствам одинаковый. Однако, в отличие от полей, свойства не обозначают места хранения. Вместо этого у свойств есть аксессоры, которые указывают операторы, которые будут выполняться, когда их значения будут считаны или записаны.
тогда как методы определены как
§ 8.7.3
A метод - это элемент, который реализует вычисление или действие, которое может выполняться объектом или классом. Методы имеют (возможно, пустой) список формальных параметров, возвращаемое значение (если методы return-type недействительны) и являются либо статическими, либо нестатическими.
Свойства и методы используются для реализации encapsulation. Свойства инкапсулируют данные, методы инкапсулируют логику. И поэтому вы должны предпочесть свойство только для чтения, если вы подвергаете данные. В вашем случае нет логики, которая изменяет внутреннее состояние вашего объекта. Вы хотите предоставить доступ к характеристике объекта.
Является ли экземпляр вашего объекта IsMapped или нет характеристикой вашего объекта. Он содержит проверку, но почему у вас есть свойства для доступа к ней. Свойства могут быть определены с использованием логики, но они не должны выставлять логику. Как и в примере, указанном в первой цитате: Представьте себе свойство String.Length. В зависимости от реализации может быть, что это свойство проходит через строку и подсчитывает символы. Он также выполняет операцию, но "извне" он просто дает утверждение по внутреннему состоянию/характеристикам объекта.
Я бы использовал свойство, потому что нет реального "действия" (действия), никаких побочных эффектов и не слишком сложного.
Я лично считаю, что method должен что-то сделать или выполнить какое-то действие. Вы ничего не выполняете внутри IsMapped, поэтому это должно быть property
Я бы пошел на имущество. Главным образом потому, что первая ссылка на ссылку MSDN-статьи:
В общем, методы представляют действия и свойства представляют данные.
В этом случае мне кажется совершенно понятным, что это должно быть свойство. Это простая проверка, отсутствие логики, отсутствие побочных эффектов, отсутствие влияния на производительность. Это не намного проще, чем проверка.
Edit:
Обратите внимание, что если бы был какой-либо из вышеперечисленных, и вы бы поместили его в метод, этот метод должен включать сильный глагол, а не вспомогательный глагол, как есть или имеет. Метод делает что-то. Вы можете назвать его VerifyMapping или DefineMappingExistance или что-то еще, если оно начинается с глагола.
Я думаю, что эта строка в вашей ссылке - это ответ
методы представляют действия и свойства представляют данные.
Здесь нет никаких действий, просто часть данных. Итак, это свойство.
Если в любой момент вам нужно будет добавить параметры, чтобы получить значение, вам нужен метод. В противном случае вам понадобится свойство
IMHO, первое свойство только для чтения является правильным, потому что IsMapped как атрибут вашего объекта, и вы не выполняете действие (только оценка), но в конце дня совместимость с существующей кодовой базой, вероятно, считается для более чем семантики.... если это не присвоение uni
Я соглашусь с тем, что люди здесь говорят, что, поскольку они получают данные и не имеют побочных эффектов, это должно быть свойство.
Чтобы развернуть это, я также соглашусь с некоторыми побочными эффектами с сеттерами (но не с геттером), если побочные эффекты имеют смысл кому-то "смотреть на него со стороны".
Один из способов думать о том, что методы - это глаголы, а свойства - прилагательные (между тем сами объекты являются существительными, а статические объекты - абстрактными существительными).
Единственное исключение из руководства глагола/прилагательного состоит в том, что имеет смысл использовать метод, а не свойство при получении (или настройке) информации, о которой идет речь, может быть очень дорогостоящим: логично, такая функция, вероятно, должна быть свойство, но люди привыкли думать о свойствах как о низком воздействии на производительность, и пока нет реальной причины, почему это всегда должно быть так, было бы полезно подчеркнуть, что GetIsMapped() относительно тяжелый, если он на самом деле был.
На уровне исполняемого кода нет абсолютно никакой разницы между вызовом свойства и вызовом эквивалентного метода для получения или установки; это все о том, чтобы облегчить жизнь человеку, написавшему код, который его использует.
В ситуациях/языках, где у вас есть доступ к обеим из этих конструкций, общий разделитель выглядит следующим образом:
Чуть более конкретно, свойство должно использоваться для доступа, в режиме чтения и/или записи, элемента данных, который (для целей потребления) принадлежит объекту, подвергнув его воздействию. Свойства лучше, чем поля, потому что данные не должны постоянно существовать в постоянной форме (они позволяют вам "лениться" на вычисление или извлечение этого значения данных), и они лучше, чем методы для этой цели, потому что вы все равно можете использовать их в коде, как если бы они были общедоступными полями.
Свойства не должны, однако, приводить к побочным эффектам (с возможным, понятным исключением установки переменной, предназначенной для сохранения возвращаемого значения, избегая дорогого пересчета значения, необходимого много раз); они должны, при прочих равных условиях, возвращать детерминированный результат (так что NextRandomNumber является плохим концептуальным выбором для свойства), и расчет не должен приводить к изменению каких-либо данных состояния, которые влияют на другие вычисления (например, получение PropertyA и СвойствоB в этом порядке не должно возвращать какой-либо другой результат, чем получение PropertyB, а затем PropertyA).
Метод OTOH концептуально понимается как выполнение некоторой операции и возвращение результата; Короче говоря, он делает что-то, что может выходить за рамки вычисления возвращаемого значения. Поэтому методы должны использоваться, когда операция, которая возвращает значение, имеет дополнительные побочные эффекты. Возвращаемое значение может по-прежнему являться результатом некоторого вычисления, но метод, возможно, вычислил его недетерминированным (GetNextRandomNumber()), или возвращенные данные в форме уникального экземпляра объекта, и вызов метода снова вызывает другой экземпляр, даже если он может иметь одни и те же данные (GetCurrentStatus()), или метод может изменять данные состояния, так что выполнение одной и той же вещи дважды в строке дает разные результаты (EncryptDataBlock(); многие шифры шифрования работают таким образом дизайн для обеспечения шифрования одних и тех же данных дважды подряд создает разные зашифрованные тексты).
Я ожидал бы свойство, поскольку оно возвращает только значение поля. С другой стороны, я ожидал бы
MappedFields[] mf;
public bool IsMapped()
{
mf.All(x => x != null);
}
вы должны использовать свойство, потому что С# имеет свойства по этой причине