Почему методы являются виртуальными по умолчанию в Java, но невиртуальными по умолчанию в C#? [закрытый]

Способ Java проще, способ C # более детализирован, безопаснее и по умолчанию более эффективен. Что лучше - в глазу держателя пива.

Андерс Хейлсберг: (ведущий архитектор C #)

Есть несколько причин. Один производительность. Мы можем заметить, что как люди пишут код на Java, они забывают чтобы отметить свои методы окончательными. Следовательно, эти методы виртуальные. Потому что они виртуальные, они не выступать также. Есть просто накладные расходы, связанные с будучи виртуальным методом. Это один проблема.

Более важным вопросом является управление версиями. Есть две школы мысли о виртуальные методы. Академическая школа мысли говорит: "Все должно быть виртуальный, потому что я могу захотеть когда-нибудь переопределит это ". Прагматичный школа мысли, которая исходит из создание реальных приложений, работающих в реальный мир говорит: «Мы должны быть очень осторожны в том, что мы делаем виртуальный "

Когда мы делаем что-то виртуальное в платформы, мы делаем очень много обещания о том, как он развивается в будущее. Для невиртуального метода мы Обещай, что когда ты позвонишь в это метод, x и y произойдут. Когда мы публикуем виртуальный метод в API, мы не только обещать это, когда вы звоните этот метод, x и y произойдут. Мы также обещайте, что когда вы переопределите этот метод мы назовем в этом особая последовательность в отношении эти другие, и государство будет в том или ином инварианте.

Каждый раз, когда вы говорите виртуальный в API, вы создаете перехватчик обратного вызова. Так как разработчик фреймворка ОС или API, ты должен быть очень осторожен с который. Вы не хотите, чтобы пользователи переопределяли и зацепление в любой произвольной точке в API, потому что вы не можете давай эти обещания. И люди могут не до конца понимают обещания, которые они делают, когда они что-то делают виртуальный.

.Net вынуждает программиста определять, какие функции могут быть переопределены, тогда как функции Java, по умолчанию, могут быть переопределены, если не используется ключевое слово final.

Если вы решительный сторонник из Принципа открытия / закрытия вы можете склоняться к поддержке способа Java. Лучше всего разрешить расширение классов и переопределение методов так, чтобы базовая функциональность / код не затрагивались. По этой причине я поддерживаю / предпочитаю способ Java. Если бы я смотрел на вопрос с другой точки зрения, мое мнение могло бы быть противоположным.

Это возмущение во времени. C ++ по умолчанию использует ключевое слово virtual и final.

Java следует за C ++ и пытается взять лучшее и улучшить его недостатки. Опасности чрезмерного использования наследования еще не выяснены, поэтому Java предпочитает использовать ключевое слово final и virtual по умолчанию.

C # следует за Java и имеет преимущество ретроспективного анализа. Андерс предпочитает вернуться к соглашению C ++ после изучения опыта Java.

Ответ Андерса Хейлсберга: http://www.artima.com/intv/nonvirtual.html

Как всегда, есть плюсы и минусы. C # сделал AOP более сложным для реализации, но ретроспективный взгляд может быть 20/20, как упоминалось другими. Все сводится к тому, считаете ли вы, что классы должны разрабатываться для расширения или просто оставлять открытыми для непредвиденных модификаций поведения. При разработке языка на этот вопрос сложно ответить. Я думаю, что отраслевой опыт склоняется к более консервативному подходу, который использует C #.