Что, не надо создавать базовый класс? Или не надо читать документацию?
Ок, используем подход java и делаем все методы виртуальными. Их в воркере штук 7, если считать сеттери и геттеры. Сколько из них может полностью переопределить наследник, не поломав всю реализацию? Полностью - без вызова base и без дублирования кода из base. Только 2, и то только потому что они ничего не делают. И виноват в этом ес-но ... автор наследника. IMHO, виноват автор базового класса, который не продумал интерфейс. 
А теперь сравни это с возможностью неправильно подписаться на событие стандартного воркера. Он, кстати, не предьявляет вообще никаких требований к использующему его. Только надежда что тот будет периодически (да хоть раз в сутки) проверять CancellationPending.
Что, совсем не видно разницы? А ведь именно из-за этой "неуловимой" разницы появился Design By Contract и прочие формы отказа от наследования реализации.
Вот, линк по теме, а то пересказывать влом: http://blogs.gotdotnet.ru/personal/bezzus/...2c-f54450aa64d6

Есть PHP, в котором ООП в зачаточном состоянии. На нем написны миллиарды строк кода и проведены миллиарды человекочасов. На основе опыта программирования на PHP любой студент-кодер может сделать неголословное утверждение, даже вывод, что ООП - вообще вредно, только лишний раз мозг напрягает. Строгая типизация, обработка исключений, сборщик мусора, и вообще все, что хоть сколько-нибудь заботится о дизайне приложения, о минимизации контрактов, о соблюдении принципов ООП - это тоже борьба с ветряными мельницами? Или может это обдуманные решения, принятые ради удобства самих разработчиков? Миллионы леммингов не могут ошибаться.
И, кстати, C#/.NET тоже довольно распространенные языки, но за все время я только один раз видел жалобы на невиртуальные по умолчанию функции. Вот в этом топике 

Добавлено через 4 минуты и 34 секунды

Зато на написание и на поддержку этого качества могло бы уйти намного меньше времени.

Да сколько угодно. Вопрос только, нафига их ему переопределять? Есть абстрактные методы, их переопрелять обязательно. А неабстрактные методы можно не переопределять. 


Ну ты придумай ещё каких-нибудь ограничений. А потом ещё какие-нибудь выводы сделай на основании того, что сам придумал.


Зачем мне сравнивать с возможностью подписаться неправильно? 


Не видно разницы в необходимом объёме прочтения документации и в объёме требований к, которую ты заявлял. Ты теперь признаёшь, что был в этом неправ и переходишь к рассмотрению какой-то другой разницы? Невозможно же, не разобравшись с одним вопросом, перескакивать на следующий.


А не надо пересказывать, надо высказывать свои мысли.


Не надо передёргивать. На основании этого опыта можно сделать вывод, что отсутствие ООП это не катастрофа, вот и всё.


Ну если кто-то скажет, что без сборщика мусора -- полный капец -- то это будет борьба с ветряными мельницами. На самом деле, перечисленные тобой вещи просто улучшают жизнь, повышают КПД и производительность труда. Но они не превращают смерть в жизнь.


Конечно, это обдуманные решения.


Дело не в количестве леммингов, а в качестве мыслей. За каждым решением должна стоять мысль, а эту мысль должно быть можно сформулировать.

За отказом от виртуальных функций я пока увидел только одну мысль -- ограничить возможность наследника вмешиваться в функционирование того, что он использует в своей конструкции. Я нахожу это не плюсом, а минусом. 

Ой, а покажи, на какой странице? И кто жаловался, не подскажешь?

Dims, принцип наименьших привилегий знаком?

Это как раз не ограничения. Ограничения - это "обязательно надо вызвать base".

Так о том и спор. Если наследник не может корректно переопределить неабстрактный метод, то лучше бы этому методу вообще не быть виртуальным.

А ты сходи, почитай. Может и появятся свои мысли, а не только "в java так, зачем вы сделали по-другому" 
Вообще-то объем документации которую НУЖНО изучить перед использованием класса напрямую связан с объемом требований. Просто ты почему-то воспрнимаешь, например, обязательный вызов base как само-собой разумеющееся, а не как требование, налагаемое на наследника. Или, например, необходимость поддерживать интерфейс следующих версий базового класса - тоже требование к наследнику.



Да любой пхп-ст тебе как два пальца докажет что ООП - бесполезный выверт. Недвано на хабре даже спор был о полезности ООП.

Ну вот невиртуальность функций по умолчанию, и вообще переход от наследования реализации к наследованию контракта повышает производительность, КПД, и уменьшают количество багов и затрат на поддержку. Хочешь конкретных примеров - возьми стандартные паттерны - IoC/DI, MVC - не используется в них наследование. Возьми гамму - там наследование реализации очень редко встречается. Возьми того же Фаулера - там наследования почти нет. Возьми какой-нибудь Eiffel - типа идеал ООП - там вообще один интерфейсы. Почитай классику по ООП - Алана Кея - там нет наследования как такового.

Вирутальные функции тоже не превращают жизнь в смерть, просто перед их объявлением надо думать. Ну не верю я, что до написания тела функции можно быть 100% уверенным в том, что она достойна стать виртуальной. А ты веришь в умных кодеров наследников, которые будут читать документацию.


Мысль - ограничить возможность наследника вмешаться прямо (некорректно заменить) или косвенно (использовать недокументированные подробности реализации базового класса) вмешаться в реализацию базового класса. Снизить вероятность привязки наследника к конкретной реализации базового класса. Ограничить распространение изменений базового класса - отказом от наследования вообще, или от виртуальных функций в частности. Принудительно потребовать от наследника соблюдать принцип подстановки (а не на надеятся на умных кодеров наследника). И еще много мыслей, которые ты сейчас отметешь как несущественные, потому что в java можно кодить без них.

Добавлено через 1 минуту и 6 секунд
Partizan, бесполезно, он исповедует принцип свободы, и считает невиртуальные функции лишними ограничениями и происками MS.

Модератор: БУУУУУУУУУУУ !!!!!!!!!!!!!

Ну народ, и нафлудили вы тут пока меня не было полгода...         

В общем, насчёт "почему все функции не виртуальные по умолчанию" отвечаю по существу. Потому что вызов виртуальной функции дороже с точки зрения производительности. Соответственно полиморфизм - необязательное свойство методов в сишарпе (в отличие от Java).

На ассемблере тоже можно писать, некоторым даже не плохо это удаётся, это же не значит, что надо вернуться к ассемблеру. Я нигде не пытался доказать, что явовский подход неработоспособен. Просто тот, который реализован в дотнете мне кажется более удачным и безопасным.


А кто говорит об отказе? Речь только о том, чтобы не делать виртуальными члены, не предназначенные для переопределения.

OFF: Ура! Модератор вернулся. Теперь будет чистота и порядок. А то уже эти холивары надоели 



mr.DUDA: угу, дискуссия была весьма захватывающей, я даже попкорн купил... но для холиваров есть целый раздел, а тут им не место вообще-то.   

Это сообщение отредактировал(а) mr.DUDA - 6.11.2008, 00:43

То есть вот так вот значит, да? Развлёкся, попкорна похавал, а теперь мятыми упаковками от этого попкорна в тех, кто тебя развлекал швыряешь?
И потом: причём тут холивар? Мы просто общаемся, выясняя вопрос, вполне вписывающийся в тематику форума. Если автор темы не пометил вопрос решённым - значит ему не всё ясно, а объяснения вроде


не убеждают даже меня, ибо в этом случае возникает вопрос: а почему тогда все классы не делаются завершёнными по-умолчанию? 

Разницу между расширяемостью и оптимальным подходом видишь?

Ну вот скажем, хочу я в одном случае сделать иерархию классов, с наследованием и полиморфизмом. На производительность мне начхать. Следовательно мне удобнее, чтобы классы были наследуемыми (а не завершёнными по умолчанию) и были доступны фичи а-ля реализация набора интерфейсов или базовых классов (как в С++), виртуальные функции и всяческий синтаксический сахар. Это про расширяемость.

Теперь про оптимальный подход. Допустим я хардкорный программер и хочу поиметь максимальную производительность и мимимум оверхеда на всякие ООП-приблуды, но вынужден по той или иной причине пользоваться дотнетом и сишарпом. Что мне делать? Использовать один-два класса, функциональный подход, никаких виртуальных функций, структуры вместо классов на мелкие объекты, массивы через указатели и так далее. Здесь мне уже начхать на полиморфизм и наследование.

Итак, вопрос: что важнее с точки зрения создателя такого языка и такой платформы как сишарп и дотнет? Ответ такой: важны все разработчики, важны все возможные области применения. Вердикт: минимум ограничений, максимум возможностей. Не запрещается наследование, но и не принуждается использование виртуальных функций.

Пример частный, но в контексте темы.

З.Ы. попкорном не кидаюсь!!!!!   

Ну здесь, на сколько я понимаю, никто не говорил об ограничениях, спор всего-навсего о том, какими члены типов должны быть по-умолчанию. Умолчания обычно можно изменять, однако те значения, которые элементы имеют по-умолчанию, считаются оптимальными и наиболее часто используемыми. И разногласия были собственно в том, что чаще нужно: виртуальные члены или нет.
Если мне по тем или иным причинам понадобится виртуальный член, то скорее всего производительность отойдёт на второй план и я сделаю член типа виртуальным. Собственно, я говорил только о том, что в контексте разговора производительность(ИМХО) не является решающим фактором.


Та ладно бы попкорном, а то пожамканая упаковка в ход идёт 



Это сообщение отредактировал(а) diadiavova - 7.11.2008, 02:51

diadiavova, работа такая у модератора - кидать упаковкой от попкорна или чем-нибудь потяжелее  

Консенсуса не видно, тема уже на 6 страницах, треть постов - оффтоп на тему нот и затенения. Заготавливаю ещё попкорн, чтобы было чем швыряться...

Можно было бы и попкорном швырнуть для разнообразия, а то тоже охота.

Насчёт нот - согласен, а с затенения всё и началось. Dims спросил: зачем оно нужно, и тут выяснилось, что функции не виртуальные по-умолчанию.