Чому C # реалізує методи як невіртуальні за замовчуванням?

На відміну від Java, чому C # розглядає методи як не віртуальні функції за замовчуванням? Чи швидше це питання ефективності, а не інших можливих результатів?

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

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

virtualметоди також можуть мати незначний вплив на продуктивність. Це, мабуть, не є основною причиною.

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

Більшість виправдань мені читають, як старий аргумент "Якщо ми дамо тобі владу, ти можеш нашкодити собі". Від програмістів ?!

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

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

Невіртуальний за замовчуванням ускладнює моє життя.

ОНОВЛЕННЯ: [цілком правильно] було зазначено, що я фактично не відповів на питання. Отож - і з вибаченнями за те, що досить пізно….

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

Однак я усвідомлюю, що просто висловлюю свою думку, а не ту остаточну відповідь, яку бажає Stack Overflow. Звичайно, я подумав, що на найвищому рівні остаточна (але непомітна) відповідь така:

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

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

Отже, здавалося б, що відповіді та коментарі щодо небезпеки переважаючих API та необхідності чітко розробити спадщину на правильному шляху, але у всіх пропущений важливий часовий аспект: головна турбота Андерса полягала у підтримці неявного класу чи API контракт у різних версіях . І я думаю, що насправді він більше стурбований тим, щоб дозволити зміну платформи .Net / C # під кодом, а не стурбований тим, щоб змінити код користувача на вершині платформи. (І його "прагматична" точка зору - це якраз протилежний моєму, тому що він дивиться з іншого боку.)

(Але хіба вони не могли просто вибрати віртуальні за замовчуванням, а потім переглянули "остаточний" через кодову базу? Можливо, це не зовсім те саме. А Андер явно розумніший за мене, тому я збираюся дати йому лежати.)

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

Підсумовуючи сказане іншими, є декілька причин:

1- У C # є багато речей у синтаксисі та семантиці, які походять прямо з C ++. Справа в тому, що методи, де не віртуальні за замовчуванням у C ++, впливали на C #.

2- Наявність кожного методу віртуального за замовчуванням - це питання продуктивності, оскільки кожен виклик методу повинен використовувати Віртуальну таблицю об'єкта. Більше того, це сильно обмежує можливість компілятора Just-In-Time вбудовувати методи та виконувати інші види оптимізації.

3- Найголовніше, якщо методи за замовчуванням не віртуальні, ви можете гарантувати поведінку своїх класів. Якщо вони за замовчуванням є віртуальними, як, наприклад, у Java, ви навіть не можете гарантувати, що простий метод getter виконуватиметься за призначенням, оскільки його можна буде перекрити, щоб зробити що-небудь у похідному класі (звичайно, ви можете, і потрібно, робити метод та / або підсумковий клас).

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

На C # впливає C ++ (і більше). C ++ не дає змоги динамічно відправляти (віртуальні функції) за замовчуванням. Одним (хорошим?) Аргументом для цього є питання: "Як часто ви реалізуєте класи, які є членами класу hiearchy?". Ще одна причина уникнення включення динамічної відправки за замовчуванням - це пам'ять. Клас без віртуального вказівника (vpointer), що вказує на віртуальну таблицю , звичайно менше, ніж відповідний клас із увімкненою пізньою прив'язкою.

Питання про виставу не так просто сказати "так" чи "ні". Причиною цього є компіляція Just In Time (JIT), яка є оптимізацією часу запуску в C #.

Ще одне, схоже питання про " швидкість віртуальних дзвінків .. "

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

За допомогою невіртуального методу ви маєте тотальний контроль. Все, що піде не так - це вина оригіналу автора. Міркувати про код набагато простіше.

Якби всі методи C # були віртуальними, тоді vtbl був би набагато більшим.

Об'єкти C # мають віртуальні методи, лише якщо у класі визначені віртуальні методи. Це правда, що всі об'єкти мають інформацію про тип, яка включає еквівалент vtbl, але якщо не визначені віртуальні методи, тоді будуть присутні лише базові методи об'єкта.

@Tom Hawtin: Напевно, точніше сказати, що C ++, C # і Java - це сімейство мов C :)

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

Розглянемо клас списку «Додати метод. Що робити, якщо розробник захотів оновити одну з декількох потенційних баз даних кожного разу, коли певний список буде доданий до? Якщо "Додати" за замовчуванням було віртуальним, розробник міг би розробити клас "BackedList", який замінив метод "Add", не примушуючи весь код клієнта знати, що це "BackedList" замість звичайного "Список". У всіх практичних цілях "BackedList" може розглядатися як лише інший "Список" з коду клієнта.

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

Це, звичайно, не питання про продуктивність. Інтерпретатор Java Sun використовує той самий код для відправки ( invokevirtualбайт-код), а HotSpot генерує абсолютно той самий код, чи finalні. Я вважаю, що всі об'єкти C # (але не структури) мають віртуальні методи, тому вам завжди буде потрібно vtblідентифікація класу / час виконання. C # - діалект "Явоподібних мов". Припустити, що це походить від C ++, не зовсім чесно.

Існує думка, що вам слід «спроектувати на спадщину або ще заборонити це». Це звучить як чудова ідея аж до того моменту, коли у вас є серйозний діловий випадок, який потрібно швидко вирішити. Можливо, успадковане від коду, який ви не контролюєте.