Чому приватні поля є приватними для цього типу, а не екземплярами?

У C # (та багатьох інших мовах) абсолютно законно отримати доступ до приватних полів інших екземплярів того ж типу. Наприклад:

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

Оскільки специфікація C # (розділи 3.5.1, 3.5.2) констатує, що доступ до приватних полів має тип, а не екземпляр. Я обговорював це з колегою, і ми намагаємось знайти причину, чому це працює так (а не обмежувати доступ до того ж примірника).

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

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

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

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

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

EDIT : точка Danilel Hilgarth, що це міркування в зворотному напрямку має сенс. Мовні дизайнери можуть створити потрібну мову, і автори-компілятори повинні відповідати їй. Незважаючи на це, мовні дизайнери мають певний стимул, щоб полегшити авторам-упорядникам виконувати свою роботу. (Хоча в цьому випадку досить просто стверджувати, що приватні члени можуть бути доступними лише через this(неявно або явно)).

Однак я вважаю, що це робить проблему більш заплутаною, ніж повинна бути. Більшість користувачів (включаючи мене) вважають це необмеженим обмеженням, якщо вищезгаданий код не працював: зрештою, це мої дані, до яких я намагаюся отримати доступ! Чому я повинен пройти this?

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

Тому що мета інкапсуляції, що використовується в C # і подібних мовах *, полягає в зниженні взаємної залежності різних фрагментів коду (класи в C # і Java), а не різних об'єктів в пам'яті.

Наприклад, якщо ви пишете код в одному класі, який використовує деякі поля в іншому класі, то ці класи дуже щільно з'єднані. Однак якщо ви маєте справу з кодом, у якому у вас два об'єкти одного класу, додаткової залежності немає. Клас завжди залежить від себе.

Однак уся ця теорія про інкапсуляцію провалюється, як тільки хтось створює властивості (або отримує / встановлює пари в Java) і відкриває всі поля безпосередньо, що робить класи сполученими, як ніби вони отримують доступ до полів.

_{* Для роз'яснення видів інкапсуляції див відмінну відповідь Авеля.}

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

Ще в дні

Десь між Smalltalk в 80-х і Java в середині 90-х років визріла концепція орієнтації на об'єкти. Інформація про приховування, спочатку не розглядалася як концепція, доступна лише для OO (згадана спочатку в 1978 р.), Була введена в Smalltalk, оскільки всі дані (поля) класу є приватними, усі методи є загальнодоступними. Під час багатьох нових розробок ОО в 90-х Бертран Мейєр намагався формалізувати значну частину концепцій ОО у своїй знаковій книзі " Об'єктно-орієнтована побудова програмного забезпечення" (OOSC), яка з тих пір вважається (майже) остаточним посиланням на концепції OO та мовний дизайн .

У випадку приватної видимості

За Мейєром, метод повинен бути доступний для визначеного набору класів (стор. 192-193). Це, очевидно, дає дуже високу деталізацію прихованості інформації, наступна особливість доступна класамA та classB та всім їх нащадкам:

feature {classA, classB}
   methodName

У разі privateвін говорить наступне: без явного оголошення типу видимим для власного класу, ви не можете отримати доступ до цієї функції (методу / поля) в кваліфікованому виклику. Тобто, якщо xце змінна, x.doSomething()не дозволена. Безумовно, доступ дозволений, звичайно, всередині самого класу.

Іншими словами: щоб дозволити доступ екземпляру того ж класу, ви повинні дозволити методу доступ до цього класу явно. Іноді це називається екземпляр-приватний проти клас-приватний.

Примірник-приватний у мовах програмування

Я знаю щонайменше дві мови, які в даний час використовуються, які використовують приховування приватної інформації, на відміну від приховування приватно-класової інформації. Один - Ейфелева, мова, розроблена Мейєром, яка підводить ОО до найбільшої межі. Інший - Рубі, набагато більш поширена мова в наш час. У Ruby privateозначає: "приватний для цього екземпляра" .

Вибір мовного дизайну

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

З технічної точки зору, немає жодної причини вибирати той чи інший спосіб (наприклад, якщо врахувати, що Eiffel.NET може це зробити з IL, навіть при багатократному успадкуванні, немає властивої причини не надавати цю функцію).

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

Чому C # дозволяє лише інкапсуляцію класу, а не інкапсуляцію примірника

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

Однак C #, правда кажучи, найважче виглядав на C ++ та Java за його мовний дизайн. У той час як Ейфель і Модула-3 також були на знімку, враховуючи безліч особливостей відсутності Ейфеля (багаторазове успадкування), я вважаю, що вони вибрали той самий маршрут, що і Java та C ++, коли мова зайшла про модифікатор приватного доступу.

Якщо ви дійсно хочете дізнатись, чому вам слід спробувати домогтися Еріка Ліпперта, Кшиштофа Кваліна, Андерса Хейльсберга чи будь-кого іншого, хто працював за стандартом C #. На жаль, я не зміг знайти остаточну замітку в анотованій мові програмування C # .

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

Причина справді - перевірка рівності, порівняння, клонування, перевантаження оператора ... Було б дуже складно реалізувати, наприклад, оператор + на складних числах.

Перш за все, що буде з приватними статичними членами? До них можна отримати доступ лише статичними методами? Ви, звичайно, не хотіли б цього, тому що тоді ви не зможете отримати доступ до своїх consts.

Що стосується вашого явного питання, розгляньте випадок StringBuilder, який реалізується як пов'язаний список самих примірників:

public class StringBuilder
{
    private string chunk;
    private StringBuilder nextChunk;
}

Якщо ви не можете отримати доступ до приватних членів інших примірників вашого власного класу, вам доведеться реалізувати ToStringтак:

public override string ToString()
{
    return chunk + nextChunk.ToString();
}

Це буде працювати, але це O (n ^ 2) - не дуже ефективно. Насправді це, мабуть, перемагає всю мету - мати StringBuilderклас в першу чергу. Якщо ви можете отримати доступ до приватних членів інших примірників вашого власного класу, ви можете реалізувати ToString, створивши рядок потрібної довжини, а потім зробивши небезпечну копію кожного фрагмента на відповідному місці в рядку:

public override string ToString()
{
    string ret = string.FastAllocateString(Length);
    StringBuilder next = this;

    unsafe
    {
        fixed (char *dest = ret)
            while (next != null)
            {
                fixed (char *src = next.chunk)
                    string.wstrcpy(dest, src, next.chunk.Length);
                next = next.nextChunk;
            }
    }
    return ret;
}

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

Це цілком законно для багатьох мов (C ++ для однієї). Модифікатори доступу виходять з принципу інкапсуляції в OOP. Ідея полягає у обмеженні доступу назовні , в даному випадку зовні - це інші класи. Наприклад, будь-який вкладений клас у C # може отримати доступ до приватних членів батьків.

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

Існує аналогічне обговорення тут

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

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

Я думаю, що все навколо, надання можливості обмежувати доступ таким чином, може стати гарною особливістю додати до OOP. Чи справді це корисно? Я б сказав, що ні, оскільки клас повинен мати можливість довіряти своєму коду. Оскільки цей клас - це єдине, що може отримати доступ до приватних членів, немає реальної причини потребувати абстрагування даних під час роботи з екземпляром іншого класу.

Звичайно, ви завжди можете писати свій код так, ніби приватний застосовується до екземплярів. Використовуйте звичайні get/setметоди для доступу / зміни даних. Це, ймовірно, зробить код більш керованим, якщо клас може зазнати внутрішніх змін.

Чудові відповіді, наведені вище. Я додам, що частиною цієї проблеми є той факт, що інстанціювати клас всередині себе навіть дозволено в першу чергу. Наприклад, у рекурсивній логіці циклу "for", наприклад, використовується такий тип трюку, доки у вас є логіка для припинення рекурсії. Але екземпляр або передача одного класу всередині себе, не створюючи таких циклів, логічно створює власні небезпеки, навіть незважаючи на те, що загальноприйнята парадигма програмування. Наприклад, клас C # може створювати копію себе в конструкторі за замовчуванням, але це не порушує жодних правил і не створює причинних циклів. Чому?

До речі .... ця сама проблема стосується і "захищених" членів. :(

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

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

Мені здається, що якби дані були приватними для інших екземплярів одного типу, вони не обов'язково були б уже того самого типу. Здавалося б, поводитись чи діяти так само, як інші випадки. Поведінку можна легко змінити на основі приватних внутрішніх даних. Це просто поширило біду на мою думку.

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