Чи можуть параметри бути постійними?

Я шукаю еквівалент C # Java final. Чи існує?

Чи є у C # щось подібне:

public Foo(final int bar);

У наведеному вище прикладі barє змінною лише для читання і не може бути змінена Foo(). Чи є спосіб зробити це в C #?

Наприклад, може бути , у мене є довгий метод , який буде працювати з x, yі zкоординати деяких об'єктів (Інтс). Я хочу бути абсолютно впевненим, що функція жодним чином не змінює ці значення, тим самим пошкоджуючи дані. Таким чином, я хотів би оголосити їх лише для читання.

public Foo(int x, int y, int z) {
     // do stuff
     x++; // oops. This corrupts the data. Can this be caught at compile time?
     // do more stuff, assuming x is still the original value.
}

На жаль, ви не можете зробити це в C #.

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

readonlyКлючове слово може бути використано тільки на полях.

ПРИМІТКА. Мова Java також підтримує наявність кінцевих параметрів методу. Ця функція не існує в C #.

з http://www.25hoursaday.com/CsharpVsJava.html

РЕДАГУВАТИ (2019/08/13): Я кидаю це для наочності, оскільки це прийнято і є найвищим у списку. Тепер це можливо з inпараметрами. Детальніше див . Відповідь нижче.

Тепер це можливо в C # версії 7.2:

Ви можете використовувати inключове слово в підписі методу. Документація MSDN .

inКлючове слово повинно бути додано до вказівки аргументу методу.

Приклад, дійсний метод у C # 7.2:

public long Add(in long x, in long y)
{
    return x + y;
}

Незважаючи на те, що заборонено:

public long Add(in long x, in long y)
{
    x = 10; // It is not allowed to modify an in-argument.
    return x + y;
}

Наступна помилка буде показана при спробі модифікувати xабо yз тих пір, як вони позначені in:

Неможливо призначити змінну 'in long', оскільки вона є змінною лише для читання

Позначення аргументу inзасобами:

Цей метод не змінює значення аргументу, що використовується як цей параметр.

Ось коротка та мила відповідь, яка, ймовірно, набере багато голосів проти. Я не прочитав усіх постів та коментарів, тому, будь ласка, пробачте мене, якщо це було запропоновано раніше.

Чому б не взяти свої параметри і не передати їх в об'єкт, який представляє їх незмінними, а потім використовувати цей об'єкт у своєму методі?

Я усвідомлюю, що це, мабуть, дуже очевидна робота, яка вже була розглянута, і ОП намагається уникати цього, ставлячи це питання, але я відчував, що це все одно має бути ...

Удачі :-)

Відповідь: C # не має такої функції const, як C ++.

Я згоден з Беннеттом Діплом.

Ключове слово const дуже корисне. У цьому прикладі ви використовували int, і люди не розуміють вашу думку. Але чому, якщо ваш параметр - це величезний і складний об’єкт, який не можна змінити всередині цієї функції? Це використання ключового слова const: параметр не може змінюватися всередині цього методу, оскільки [яка б тут не була причина], що для цього методу не має значення. Ключове слово Const дуже потужне, і мені дуже не вистачає цього в C #.

Почну з intпорції. intце тип значення, а в .Net це означає, що ви дійсно маєте справу з копією. По-справжньому дивне обмеження в дизайні говорити методу "Ви можете отримати копію цього значення. Це ваша копія, а не моя; я більше ніколи її не побачу. Але ви не можете змінити копію". У виклику методу мається на увазі, що копіювання цього значення - це нормально, інакше ми не могли б безпечно викликати метод. Якщо методу потрібен оригінал, залиште його впроваджувачеві, щоб він зробив копію, щоб зберегти його. Або надайте методу значення, або не надайте методу значення. Не йдіть між собою всіми бажаючими.

Перейдемо до посилальних типів. Тепер це стає трохи заплутаним. Ви маєте на увазі постійне посилання, де саме посилання неможливо змінити, або повністю заблокований, незмінний об'єкт? Якщо перший, посилання в .Net за замовчуванням передаються за значенням. Тобто ви отримуєте копію посилання. Отже, ми маємо фактично таку ж ситуацію, як і для типів цінностей. Якщо реалізатору знадобиться оригінал посилання, він може зберегти його самостійно.

Це просто залишає у нас постійний (заблокований / незмінний) об’єкт. З точки зору виконання, це може здатися нормальним, але як компілятор його застосовувати? Оскільки властивості та методи можуть мати побічні ефекти, ви, по суті, обмежуєтесь доступом до полів лише для читання. Такий об’єкт навряд чи буде дуже цікавим.

Створіть інтерфейс для свого класу, який має лише доступ до властивостей лише для читання. Тоді нехай ваш параметр буде цього інтерфейсу, а не самого класу. Приклад:

public interface IExample
{
    int ReadonlyValue { get; }
}

public class Example : IExample
{
    public int Value { get; set; }
    public int ReadonlyValue { get { return this.Value; } }
}


public void Foo(IExample example)
{
    // Now only has access to the get accessors for the properties
}

Для конструкцій створіть загальну обгортку const.

public struct Const<T>
{
    public T Value { get; private set; }

    public Const(T value)
    {
        this.Value = value;
    }
}

public Foo(Const<float> X, Const<float> Y, Const<float> Z)
{
// Can only read these values
}

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

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

Усім тим, хто болить зараз натиснути кнопку проти, будь ласка, ознайомтесь з думками цих корифеїв щодо цієї теми:

• Ерік Ліпперт
• Ларрі Остерман
• Джоель Спольскі

Я знаю, що це може бути трохи пізно. Але для людей, які все ще шукають для цього інші шляхи, може існувати інший спосіб обійти це обмеження стандарту C #. Ми могли б написати клас обгортки ReadOnly <T> де T: struct. З неявним перетворенням на базовий тип Т. Але лише явне перетворення на клас обгортки <T>. Що буде застосовувати помилки компілятора, якщо розробник намагається неявно встановити значення типу ReadOnly <T>. Як я продемонструю два можливі варіанти використання нижче.

USAGE 1 потрібно змінити визначення абонента. Це використання буде використано лише для тестування на правильність коду ваших функцій "TestCalled". На рівні випуску / збірках ви не повинні його використовувати. Оскільки у великих масштабах математичні операції можуть перевершити перетворення і зробити ваш код повільним. Я б не використовував його, але лише для демонстрації це опублікував.

ВИКОРИСТАННЯ 2, яке я б запропонував, демонструє використання функції налагодження проти випуску у функції TestCalled2. Також не було б перетворення функції TestCaller при використанні цього підходу, але для цього потрібно трохи більше кодування визначень TestCaller2 з використанням кондиціонування компілятора. Ви можете помітити помилки компілятора в конфігурації налагодження, тоді як при конфігурації випуску весь код у функції TestCalled2 буде успішно скомпільовано.

using System;
using System.Collections.Generic;

public class ReadOnly<VT>
  where VT : struct
{
  private VT value;
  public ReadOnly(VT value)
  {
    this.value = value;
  }
  public static implicit operator VT(ReadOnly<VT> rvalue)
  {
    return rvalue.value;
  }
  public static explicit operator ReadOnly<VT>(VT rvalue)
  {
    return new ReadOnly<VT>(rvalue);
  }
}

public static class TestFunctionArguments
{
  static void TestCall()
  {
    long a = 0;

    // CALL USAGE 1.
    // explicite cast must exist in call to this function
    // and clearly states it will be readonly inside TestCalled function.
    TestCalled(a);                  // invalid call, we must explicit cast to ReadOnly<T>
    TestCalled((ReadOnly<long>)a);  // explicit cast to ReadOnly<T>

    // CALL USAGE 2.
    // Debug vs Release call has no difference - no compiler errors
    TestCalled2(a);

  }

  // ARG USAGE 1.
  static void TestCalled(ReadOnly<long> a)
  {
    // invalid operations, compiler errors
    a = 10L;
    a += 2L;
    a -= 2L;
    a *= 2L;
    a /= 2L;
    a++;
    a--;
    // valid operations
    long l;
    l = a + 2;
    l = a - 2;
    l = a * 2;
    l = a / 2;
    l = a ^ 2;
    l = a | 2;
    l = a & 2;
    l = a << 2;
    l = a >> 2;
    l = ~a;
  }


  // ARG USAGE 2.
#if DEBUG
  static void TestCalled2(long a2_writable)
  {
    ReadOnly<long> a = new ReadOnly<long>(a2_writable);
#else
  static void TestCalled2(long a)
  {
#endif
    // invalid operations
    // compiler will have errors in debug configuration
    // compiler will compile in release
    a = 10L;
    a += 2L;
    a -= 2L;
    a *= 2L;
    a /= 2L;
    a++;
    a--;
    // valid operations
    // compiler will compile in both, debug and release configurations
    long l;
    l = a + 2;
    l = a - 2;
    l = a * 2;
    l = a / 2;
    l = a ^ 2;
    l = a | 2;
    l = a & 2;
    l = a << 2;
    l = a >> 2;
    l = ~a;
  }

}

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

Чи можете ви створити параметр, значення якого неможливо призначити в методі або властивості якого неможливо встановити в межах методу? Ні. Ви не можете запобігти присвоєнню значення в методі, але ви можете запобігти встановленню його властивостей, створивши незмінний тип.

Питання не в тому, чи можна призначити параметр або його властивості в рамках методу. Питання в тому, що це буде, коли метод вийде.

Будь-які зовнішні дані будуть змінені лише в тому випадку, якщо ви передасте клас і зміните одне з його властивостей, або якщо ви передасте значення за допомогою ключового слова ref. Ситуація, яку ви окреслили, ні того, ні іншого.