Чи погано мати громадські константи?


38

Це:

public MyClass
{
    public const string SomeString = "SomeValue";
}

гірше за це:

public MyClass
{
    public static string SomeString { get{ return "SomeValue";}}
}

На обидва можна посилатися однаково:

if (someString == MyClass.SomeString)
     ...

Однак другий захист є власністю. Але насправді наскільки це краще, ніж const?

Я навчився знов і над небезпекою наявності громадських полів. Тож коли я побачив якийсь код, що використовує ці константи на загальнодоступних полях, я негайно почав рефакторинг їх на властивості. Але на півдорозі мені стало цікаво, яка вигода мати статичні властивості над константами.

Будь-які ідеї?


1
Загальнодоступні константи, які використовуються таким чином, просто чудові. Використання властивостей таким чином є надмірним.
Бернар

2
Чи думали ви використовувати ключове слово для читання тільки ? ReadOnly дає вам чистіший синтаксис const без проблем, зазначених у багатьох публікаціях.
Метт Раффель

Можна також зробити ... загальнодоступний статичний для читання лише тип typeName = 0;
Snoop

Відповіді:


56

У C # це дуже погано з жодної причини, згаданої в цій темі.

Громадські константи в C # залучаються до референтних зборів. Значить, якщо у вас є SomeOtherClass в окремій збірці, що посилається на SomeString в MyClass, CIL, згенерований для SomeOtherClass, буде містити жорстко закодовану рядок "SomeValue".

Якщо ви перейдете на повторне використання DLL, який містить MyClass, але не SomeOtherClass, і змініть const, SomeOtherClass не буде містити те, що, на вашу думку, буде - воно буде містити початкове значення.

Якщо ти 100% позитивний, це універсальна константа, як Пі, з глузду з’їдеш; інакше стежте обережно.

Ось краще пояснення: https://stackoverflow.com/questions/55984/what-is-the-difference-bet between-const-and- readonly


3
@ Додано, але однакова різниця є constвластивістю лише для читання. constвводиться у виклик, що викликає, властивість лише для читання не є.
svick

1
Це те, чого я не знав. Це ще один доказ того, що громадські поля погані. Я думаю, що навіть "безпечний" приклад Pi - це погана ідея (що робити, коли розробник хоче більш-менш цифри точності на Pi? І вносить зміни в збірку, не знаючи цього питання.) У мене 40+ збірок у моєму рішення, і я міг бачити, як це нас справді кусає, якщо ми не обережні.
Ваккано

2
Чи трапляється ця "Копія" в інших частинах C #? (тобто перерахунки)
Vaccano

2
Так, копія все-таки буває. Зазвичай це не проблема, але якщо у вашому коді використовується числове значення Enum і воно змінюється у спосіб, визначений у цьому питанні, то це може спричинити проблеми.
Ваккано

1
Це одна з головних причин, чому constв C # тупо. Нам потрібна краща підтримка непорушних ...
KChaloux

22

Зміна поля у властивість - це безперервна зміна. Ви втрачаєте сумісність із бінарними, джерелами та відображеннями.

В додаток:

  • Існує більш тонкий контроль доступу з властивостями. Потрібно, щоб воно було загальнодоступним, але дійсно хочеться, щоб воно було встановлено із захищеним доступом? Немає проблем (починаючи з C # 2, принаймні).
  • Хочете прорватися до налагоджувача щоразу, коли значення змінюється? Просто додайте в сетері точку розриву.
  • Хочете зареєструвати весь доступ? Просто додайте ведення журналу до геттера.
  • Властивості використовуються для прив'язки даних; поля - ні.

http://csharpindepth.com/articles/chapter8/propertiesmatter.aspx

Все, що було сказано, я не бачу, як на це дійсно впливають константи (особливо якщо вам не потрібна жодна з перерахованих вище функцій), якщо тільки ваш API не зміниться таким чином, що вони більше не будуть константами.


11

Небезпека загальнодоступних полів полягає в тому, що вони змінюються і що впровадження, що лежить в основі їх, може змінюватися.

Якщо мова заходить про constце, це зазвичай не проблема (подібно до публічних перелічень) - якщо ви не вважаєте, що ця constзаявка закінчиться як змінна і вам знадобиться інкапсуляція навколо аксесуара в якийсь час (скажіть, щоб увійти, скільки разів це було переглянуто вгору), ви можете також тримати це як публічне const.


1

Постійною є дані. Властивості передбачають можливість поведінки, коли ти так сильно "дивишся" на значення.

Поведінка (або майбутня можливість цього) з постійними даними абсолютно не відповідає. Для більшості систем це насправді не має значення, але це може.

Скажімо, значення "PI" і широко використовується в розрахунках системи. Якщо розмістити його за властивостями, змусить клієнтських програмістів програмувати оборонно. Вони повинні призначити значення у копії, що повторюється. Якщо вони не обробляються, наступна версія бібліотеки може мати небажану "поведінку", що вводиться за ресурсом. Поведінка властивості (якщо вона знаходиться у складеній бібліотеці) невідома. Можливо, він добре працює в тесті, але може бути прихований код, який виконується, якщо виконується особлива умова. Це не дострокова оптимізація. Особливо для системи реального часу залежить життя людей.

Клієнтські програмісти можуть навіть втратити безпеку постійної, оскільки мова може не дозволяти їм присвоювати значення властивості в їх дублікатній константі.

Крім того, коли програмісти змушені привласнювати ваше значення властивості до їхньої постійної, вони фактично зводять нанівець будь-яку поведінку, яку ви сподівалися здійснити зі своїм майном.

Справжні постійні дані не потребують або хочуть інкапсуляції.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.