Вот основная мысль:
Класс предьявляет к наследникам только требования по интерфейсу. А в примере с твоим воркером - ты (разработчик класса) предьявляешь требования к деталям реализации наследника. И эти требования никак не проверяются, и скорее всего про них никто никогда не узнает, даже если ты опишешь их в документации. Но зато ты явно увеличил связность и нарушил инкапсуляцию - теперь твой класс работает не со всеми наследниками, а только с некоторыми - что нонсенс с точки зрения ООП.

Я за 6 лет сидения на C# использовал затенение ровно 0 раз. Поэтому ответ - незачем. Нужно не извращаться с затенением, а продумывать интерфейс базового класса.


Кому должно? Вот лично мой опыт показывает, что действительно виртуальные функции - те, которые можно переопределить, и те которые действительно можно переопределить без знания о внутренностях базового класса встречаются очень-очень редко. Вообще, сам факт наследования (не от базовых классов FCL) встречается очень редко. В основном из-за того что:

C-ШАРП, раз уж ты на нем пишешь. У наследования есть проблемы вообще в OOP/OOD.



Выше был пример. Твой воркер налагает ограничения по функциональности на наследников. Это серьезный баг с точки зрения дизайна - для того, чтобы создать простого наследника, кто-то должен будет перечитать документацию по всем методам воркера - потому что там наверняка можно будет встретить "если вы переопределяете А, то вы должны переопределить В, который обязательно должен вызвать С до вызова D, и ждать пока E станет false".


Честно, не знаю ;) Потому что твои аргументы применимы и к private. Типа, если написал код, который вызывает public функцию, и что-то не работает - то это код дурацкий. Никто не сколняет тебя к затенению, даже наоборот. НИКОГДА не используй его. Я аргументирую на уровне "я наступал на грабли, я знаю зачем невиртуальные функции". Просто ты не можешь понять решения проблемы т.к. с ней не сталкивался.

Вообще есть 2 проблемы, но ты из сливаешь в одну:
1. Невиртуальность по умолчанию. Это есть гуд. Хочешь доказать что не гуд - напиши версию воркера, которая не будет требовать сакральных требований.
2. Возможность делать затенение. 
Из 1 никак не следует что все поголовно затеняют методы. Из 1 следует только то, что интерфейс будет состоять только из тех методов, для которых возможность переопределения продумана. Как ты из этого выводишь что все поголовно затеняют вместо использования virual - я просто не понимаю.

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

Добавлено через 5 минут и 57 секунд

она выключена по умолчанию, надо ее включить словом new. прочитав предварительно сообщение о возможных последствиях.


По умолчанию приносит меньше вреда невиртуальная функция и ругательства при попытке затенить.


Отличная гипотеза, вот только .net бесплатный и с открытыми исходниками. А вот в этом: "только так, как он предусмотрел" заинтересован каждый разработчик, потому что если упал твой код, пусть даже из-за кривого наследника, но глубоко в твоем коде, то виноват только ты. Все отмазки типа "это наследник кривой", "он унаследовался неправильно" не прнимаются 

Я этого не вижу.


Отсутствует логический переход. Из одного описания гипотетического вреда делается вывод, для которого необходимо сравнение вреда и пользы с разных сторон.


Ну так невиртуальность в Си-диез используется безо всякой меры. Максималистски.



Она никогда и не оспаривалась. Вред может быть ото всего. Но я хотел оценить этот вред, для чего просил привести примеры.



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


А это, кстати, ещё один пример вреда от умолчательной невиртуальности: люди привыкают к ситуации, которая ненормальна. И о нормальных вещах узнают с удивлением.

Здесь под "нормальным" я понимаю то, что чаще пригождается. Польза от виртуальности нам известна, а вред от неё пока что гипотетичен. 

Сюда же я кладу многолетний опыт программирования на Джава: ни разу виртуальность не принесла вреда, зато постоянно исПОЛЬЗовалась. Только когда я перешёл с Си++ на Джаву, я и узнал, что такое настоящее ООП во всей красе.

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

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

Ты уже написал об этом разработчикам бэкграунд-воркера в Микрософт? У них точно такие же требования.


Ну. Значит твой опыт так же говорит, что это не нужно.

Тогда о чём мы спорим? Почему ты продолжаешь отрицать, что это ошибка разработчиков?


Очень-очень редко -- это всё-таки чаще, чем 0, который ты признал по затенению.


А си-плюс-плюс ты называешь си-плас-плас? 


А почему тогда такой баг допустили в Майкрософте?


Это слова. А язык говорит другое: ВСЕГДА используй затенение.


Ну так расскажи же о ней поскорее! Что ты тянешь так долго? Готовишь морально? 



Не вижу связи. Мой воркер содержит требования, аналогичные требованиям которые только что тут были описаны насчёт Validate и аналогичные требованиям, которые выдвинуты для Микрософтовского воркера. Ты предлагаешь мне для доказательства своей позиции превзойти в программировании всех на свете? А пониже планку никак не судьба?


То же самое относится и к виртуальности. Из виртуальности метода не следует, что все поголовно его переопределяют. Поэтому здесь 0:0 или 1:1. Ничья.

Изъян твоей позиции в том, что ты никак не хочешь СРАВНИВАТЬ. Ты просто говоришь о висящих в воздухе вреде и пользе, об каких-то недостатках одного подхода. А надо говорить о РАЗНИЦЕ.



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

Ответ: никак.

Чтобы объектом пользоваться, надо знать не только тип параметров его интерфейса, но и что они делают.



new это варнинг. Его можно и не ставить.


Ругательств при переопределении тоже больше -- забыть override это ошибка, а не замечание.


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

  

Уж чего-чего, этого точно никто не говорил....


P.S. Лучше бы вы человеку про затенение не говорили...ему было бы спокойнее.

Здравая мысль! Если невозможно предусмотреть всего, значит невозможно основывать на этом какую-то логику. А если метод всё-таки нужен, то его надо делать private, а если в классах-наследниках такой метод тоже понадобится, то его по всей видимости прийдётся продублировать(потомучто private там не видно). И тут мы вообще приходим к абсурдной ситуации у нас окажется два одинаковых метода, один из которых мы сделаем private (внутренняя кухня), а второй будет виртуальным, хотя из базового класса мы его вызывать не будем.


Ну почему гипотетического? Если я создаю метод, и не имею возможности знать что от него можно ожидать, а что нельзя, то как я должен работать с ним? Обычно при вызове метода я ожидаю от него конкретного результата, а как я должен вызывать метод если понятия не имею, что он будет делать?

А то, что при определённом опыте можно обходить неудобства, ещё не говорит о том, что неудобств этих нет. И если в яве, где все функции виртуальны люди чувствуют себя комфортно, так и на ассемблере до сих пор некоторые пишут.



Говоря о максимализме я отвечал на вопрос "Из этого следует, что нужно вообще запретить виртуальные функции...". Максимализм в том, чтобы отказаться от одного в пользу другого, а средняя линия - использование всего в меру.



Любой пример можно назвать частным случаем, а если он будет придуман для иллюстрации - надуманным.


А какой случай нужен? Как я создал виртуальный метод, а его переопределение принесло вред? Так не помню я такого случая. Я же на яве не писал, а в дотнете виртуальные методы я создаю только когда в виртуальности есть потребность. Я просто не задумывался о том, как бы так создать виртуальный метод, чтобы от этого были проблемы. 
Поэтому всё что могу - это описать гипотетическую ситуацию, но полагаю - это слабый аргуумент.



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


Норма - понятие очень обтекаемое. То, что норма в одном контексте - в другой может не вписаться даже на правах аномалии. А чаще пригождается программисту то, к чему он больше привык. Помимо правил и гайдлайнов всевозможных есть ещё индивидуальный стиль программирования(почерк), и вырабатывается он под влиянием того, с чем приходится работать. Не удивительно, что после явы некоторые вещи кажутся неудобными, но при другом стиле программирования как раз ява может показаться "не в масть".


Слегка напоминает высказывания последователей различных культов 
"Только познав Господа я ощутил всю полноту жизни"   
Ничего не имею против религии, только мы о программировании сейчас.
А ООП это просто набор принципов, которые могут реализовываться по-разному, и принадлежность к ООП накладывает не так много ограничений на язык как некоторые думают.


Не ошибка, а возможность, которая жрать не просит, а если кому надо - пусть берёт, не жалко.


Я как-то чего-то затенял, но потом общая идея оказалась неудачной, пришлось всё поменять, и в новом варианте затенения не было. Но неудачной идея была не из-за затенения, там что-то другое вылезло(уже не помню)


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


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

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

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

Добавлено через 12 минут и 35 секунд
Кстати здесь поблизости ещё одна такя же тема обсуждается. Там речь идёт о грядущих возможностях си-шарпа(исправляюсь  ). За динамическую типизацию речь зашла, типа зачем и всё такое. А вот в бейсике её никто никогда не отменял, и пока никто не жаловался. Тем более, что прижелании можно включить, а можно выключить.

А причём тут виртуальность? Поверьте, тысячи людей используют Джава, где все методы виртуальные, и они отнюдь не находятся в описываемом Вами положении 



Ну это если мы исходим из злонамеренности собеседника.


Ну так а как же Вы можете быть уверены, что такие случаи существуют?


Я не против. Объясните, каким образом невиртуальные функции являются нормой вместе с контекстом, который тоже объясните.


Это не ко мне. Я не делаю культа ни из чего. Или делаю из всего, то есть, пытаюсь найти логику и привлекательность в разных вещах.



Ну вот. Итак, трое (включая меня) признают, что затенение не нужно. Отсюда вывод, что с нашей (конечно, субъективной и, возможно, ошибочной) точки зрения, разработчики Си-диеза допустили ошибку, когда включили его по умолчанию.


Я думаю, они просто не знают, что такое диез, и как это будет по-английски. Логика совершенно ясна: в названии Си++ использовали оператор ++ из Си, чтобы обозначить язык больше Си, а в названии C# использовали уже музыкальный оператор повышения тона, то есть, диез; чтобы обозначить то же самое.

Я думаю, что они знают, что такое диез...
Всего-навсего так уж повелось, что язык программирования С# программисты(по крайней мере абсолютное большинство) называют "Си-шарп", в то же время музыканты запись С# в нотном стане, очевидно, прочтут как "до-диез"...и это тоже нормально, ибо в музыкальной области это действительно обозначение ноты...

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

Вообще спорим о том, что ты считаешь что warning - это предупреждение. На самом деле warning - это самая настоящая ошибка. 

Ну уж никак не До-крест-крест.



Если на стене висит ружье, то оно выстрелит. Если что-то можно сделать неправильно, кто-то сделает это неправильно. 1:0. Твой аргумент?



Что не есть как. Ты ездишь на автомобиле, все классно, но через год к тебе приходят и говорят: тут надо после каждого километра хреновинку поворачивать на полоборота? вы не поворачивали? ну тогда придется автомобиль выбросить и купить новый. Да, и штраф заплатить по количеству непроворотов.


"как бы не пришлось учитывать что есть чужая кривая реализация" - тоже неплохой мотив. А ты предлагаешь по принципу: параметры валидируют только трусы! Разработчик заинтересован в контролируемой расширяемости, а не в поддержке чужих расширений.

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


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


Ну у меня есть оправдание. Корпорация майкрософт надёжно защитила меня от таких ошибок.  


Да контекст я ка бы уже объяснял. Ну вот пример: внутри класса я создаю метод, возвращающий строку в определённом формате. Вызывая функцию я ожидаю, что она будет возвращать нужную строку и её обработка не потребует много усилий. Если же я даю возможность переопределить метод, то строка может быть какой угодно. Мне потребуется проверить корректность строки, очень желательно, расширить формат, потомучто лишний пробел может сделать строку нечитабельной, и предусмотреть действия, при некорректном результате, которого в случае с моей функцией просто не может возникнуть. Теперь вопрос: какой вариант функции проще и безопаснее описать?


Я этого не утверждал. Трудно рассуждать о примере, сути которого даже я не помню(разве что примерно помню что делал). Затенение там было нужно и проблему создало не оно. Я тогда осваивал элементы управления и делал комбобокс с картинками. Мне надо было чтобы элементы, которые принимает коллекция Items были строго моего типа, который содержал информацию о картинке, её расположении и т. д. Но свойство Item(а в бейсике индексаторы считаются свойствами) не было виртуальным и я его затенял. В данном контексте действие вполне уместное, но сама идея как оказалось не очень. 



Насчёт большинства - сомневаюсь, компьютерщики всех мастей вообще любят называть то с чем работают всякими смешными словами.


Вряд ли в нотном стане может появится такая запись(разве что при обозначении аккорда или тональности)


А почему сосно музыкант не может быть программистом?

Добавлено @ 00:45
Да насчёт автомобиля совсем забыл. Для тог, чтобы ездить не надо знать устройство. Надо просто уметь пользоваться интерфейсом.

Это сообщение отредактировал(а) diadiavova - 4.11.2008, 00:47

diadiavova,  

Ну зачем ёрничать...



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

....кстати говоря в этой теме я вообще увидел ещё одно))) Си-диез ) это у нас что?...я слышал, что у ноты Си диеза нету, только бемоль )

Вообще-то ёрничаю я совсем не так. По моему это уже можно было заметить.
Примеры могу привести на ходу
мускул
пхп
хтмл
васик
жаба(по-моему куда более обидное название)
И это только языки программирования. А рассуждать обо всяких имхо, сабжах, матерях(в смысле железа, вот ещё тоже словечко "железо") можно вообще до бесконечности.


Ну о том как сленг приходит из других областей тоже можно рассуждать долго.


Здесь просто было название буквы(а точнее языка си) соединено с названием значка в русском языке, а музыкальный термин вообще не имелся ввиду.
А си-диез есть, только это чистая до. Просто между си и до - полтона, поэтому повышение си на полтона (это делает диез) приводит к ноте до.(это так, если интересно)

Ладно )
Не хотите обращаться в нашу веру? - Как хотите   



всё это производные от написания/произношения...
Си-Шарп вполне попадает в этот ряд...

никто же не говорит "МойЭсКуЭл"

Это сообщение отредактировал(а) Partizan - 4.11.2008, 01:23

Та я ж из васиков. И кстати, уверен, что васик - круче.

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

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

diadiavova, 

о логике:


Во всех статьях говорится именно о # как о подчёркивании сходства с С++, но нигде не говорится, что символ # был использован, чтобы показать "превосходство на полтона" )

Я видел оба варианта объяснения, и кстати: о последнем узнал недавно. В любом случае всё это только предположения. Официальных разъяснений на этот счёт я не видел, да и потом, о логике: повторюсь
 



Это сообщение отредактировал(а) diadiavova - 4.11.2008, 01:35