Использовать свойство только для чтения или метод?
мне нужно разоблачить "отображается?" состояние экземпляра класса. Результат определяется базовой проверкой. Это не просто выставляя значение поля. Я не уверен, следует ли мне использовать свойство только для чтения или метод.
свойство только для чтения:
public bool IsMapped
{
get
{
return MappedField != null;
}
}
способ:
public bool IsMapped()
{
return MappedField != null;
}
Я читал выбор между свойствами и методами но я все еще не уверен.
12 ответов:
стандарт C# говорит
§ 8.7.4
A свойства является членом, который обеспечивает доступ к характеристику объекта или класса. Примеры свойств включают длину строки, размер шрифта, заголовок окна, имя клиента, и так далее. Свойства являются естественным продолжением полей. Оба имени членов соответствующих типов и синтаксис для доступа к полям и свойствам такой же. Однако, в отличие от полей свойства не указывают места хранения. Вместо этого свойства имеют методы доступа, которые определяют инструкции, которые будут выполняться при чтении или записи их значений.
в то время как методы as определяются как
§ 8.7.3
A метод является членом, который реализует вычисление или действие, которое может быть выполнено объектом или классом. Методы есть (возможно, пустой) список формальных параметров, возвращаемое значение (если возвращаемый тип метода-void), и являются либо статическими, либо нестатическими.
свойства и методы используются для реализации инкапсуляция. Свойства инкапсулируют данные, методы инкапсулируют логику. И именно поэтому вы должны предпочесть свойство только для чтения, если вы предоставляете данные. В вашем случае нет логики, которая изменяет внутреннее состояние вашего объекта. Вы хотите обеспечить доступ к характеристика объект.
является ли экземпляр вашего объекта
IsMapped
или нет-это характеристика вашего объекта. Он содержит чек, но именно поэтому у вас есть свойства для доступа к нему. Свойства могут быть определены с помощью логики, но они не должны подвергать логике. Так же, как пример, упомянутый в первой цитате: представьте себеString.Length
собственность. В зависимости от реализации это свойство может проходить через строку и подсчитывать символы. Он также выполняет операцию, но "извне" это просто дает утверждение о внутреннем состоянии/характеристиках объекта.
Я бы использовал свойство, потому что нет никакого реального "делания" (действия), никаких побочных эффектов, и это не слишком сложно.
Я лично считаю, что a
method
должен что-то сделать или выполнить какое-то действие. Вы ничего не делаете внутриIsMapped
Так что это должно бытьproperty
Я бы пошел на собственность. В основном потому, что первый senctence на ссылочной MSDN-статье:
В общем случае методы представляют действия, а свойства-данные.
в этом случае мне кажется довольно ясным, что это должно быть свойство. Это простая проверка, никакой логики, никаких побочных эффектов, никакого влияния на производительность. Это не становится намного проще, чем этот чек.
Edit:
обратите внимание, что если есть был любой из вышеперечисленных, и вы бы поместили его в метод, этот метод должен включать сильный глагол, а не вспомогательный глагол, такой как is или has. Метод тут что-то. Вы могли бы назвать это VerifyMapping или DetermineMappingExistance или что-то еще, если оно начинается с глагола.
Я думаю, что эта строка в вашей ссылке является ответом
методы представляют действия, а свойства представляют данные.
здесь нет никаких действий, только часть данных. Так что это собственность.
Если в какой-то момент вам нужно будет добавить параметры, чтобы получить значение, то вам нужен метод. В противном случае вам нужно свойство
IMHO, первое свойство только для чтения является правильным, потому что IsMapped как атрибут вашего объекта, и вы не выполняете действие (только оценку), но в конце дня согласованность с существующей кодовой базой, вероятно, имеет значение больше, чем семантика.... если это не назначение uni
Я соглашусь с людьми здесь, говоря, что, поскольку он получает данные и не имеет побочных эффектов, он должен быть свойством.
чтобы расширить это, я бы также принял некоторые побочные эффекты с сеттером (но не геттером), если бы побочные эффекты имели смысл для кого-то "глядя на него снаружи".
один из способов думать об этом заключается в том, что методы-это глаголы, а свойства-прилагательные (между тем, сами объекты являются существительными, а статические объекты абстрактны существительные.)
GetIsMapped() относительно тяжелый выполнить-мудро, если это на самом деле было.на уровне запущенного кода нет абсолютно никакой разницы между вызовом свойства и вызовом эквивалентного метода для получения или установки; все дело в том, чтобы облегчить жизнь человеку, пишущему код, который его использует.
в ситуациях / языках, где у вас есть доступ к обеим этим конструкциям, общее разделение выглядит следующим образом:
- если запрос на что-то объект и, используйте свойство (или поле).
- если запрос является результатом чего-то объекта тут, использовать способ.
немного более конкретно, свойство должно использоваться для доступа, в режиме чтения и / или записи, к элементу данных, который является (для потребляющие цели), принадлежащие объекту, представляющему свойство. Свойства лучше, чем поля, потому что данные не должны существовать в постоянной форме все время (они позволяют вам "лениво" вычислять или извлекать это значение данных), и они лучше, чем методы для этой цели, потому что вы все еще можете использовать их в коде, как если бы они были общедоступными полями.
свойства не должны, однако, приводить к побочным эффектам (с возможным, понятным исключением установки a переменная предназначены для сохранения возвращаемого значения, избегая дорогостоящих перерасчет стоимости необходимо много раз); они должны, при прочих равных условиях, вернуть детерминированный результат (так NextRandomNumber плохой концептуальный выбор для имущества) и расчет не должны приводить к изменению каких-либо данных о том, что может повлиять на другие расчеты (например, получение PropertyA и свойство b в таком порядке не должно возвращать любой другой результат, чем свойство b, а затем PropertyA).
метод, OTOH, концептуально понимается как выполнение некоторой операции и возврат результата; короче говоря, он делает что-то, что может выходить за рамки вычисления возвращаемого значения. Поэтому методы должны использоваться, когда операция, возвращающая значение, имеет дополнительные побочные эффекты. Возвращаемое значение все еще может быть результатом некоторого вычисления, но метод может вычислить его недетерминированно (GetNextRandomNumber ()), или возвращаемые данные находятся в форма уникального экземпляра объекта, и вызов метода снова создает другой экземпляр, даже если он может иметь те же данные (GetCurrentStatus()), или метод может изменить данные состояния таким образом, что выполнение одного и того же дважды подряд приводит к разным результатам (EncryptDataBlock(); многие шифры шифрования работают таким образом, чтобы обеспечить шифрование одних и тех же данных дважды подряд создает разные шифротексты).