Override для произвольного метода.
От: Chrome  
Дата: 02.12.08 15:32
Оценка: -1 :)
Мне кажется, в .Net runtime можно без особых проблем привнести возможность переписать код произвольного метода.
Любого метода любой managed DLL. Кроме того, любой невиртуальный метод класса можно сделать виртуальным.
Добавить поля в существующие sealed классы. И много чего еще.
Нужно это, что бы преодолеть ошибки проектирования существующих библиотек.
Из минусов вижу некоторые проблемы с безопасностью в trusted environment, но эти проблемы преодолимы.
Еще возможно, в следующей версии библиотеки автор откажется от поддержки метода, который мы переопределили. Но вероятность этого мала. И я бы пошел на такой риск ради потенциальных преимуществ.
Почему официальная практика повторного использования кода не движется в этом направлении?
Зачем проектировщики библиотек заранее гадают, какие возможности понадобится переопределить пользователям их продукта и через раз не угадывают?(Ведь, чем раньше принято решение — тем больше вероятность ошибки).
Re: Override для произвольного метода.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.12.08 19:00
Оценка: +1
Здравствуйте, Chrome, Вы писали:

C>Из минусов вижу некоторые проблемы с безопасностью в trusted environment, но эти проблемы преодолимы.


Главный минус — эта мегафича для оптимизатора все равно что серпом по яйцам. Да, кстати, через profiler api все это уже сейчас имеется.

C>Зачем проектировщики библиотек заранее гадают, какие возможности понадобится переопределить пользователям их продукта и через раз не угадывают?(Ведь, чем раньше принято решение — тем больше вероятность ошибки).


Могу посоветовать очень хорошее решение проблемы — совсем не использовать наследование в качестве публичного интерфейса. Тогда и угадывать ничего не придется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[2]: Override для произвольного метода.
От: Cyberax Марс  
Дата: 02.12.08 19:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

C>>Из минусов вижу некоторые проблемы с безопасностью в trusted environment, но эти проблемы преодолимы.

AVK>Главный минус — эта мегафича для оптимизатора все равно что серпом по яйцам. Да, кстати, через profiler api все это уже сейчас имеется.
Просто нужна поддержка динамической рекомпиляции кода при изменении иерархии. Т.е. то что уже есть многие годы в Sun HotSpot JVM

Кстати, в Java все методы по умолчанию виртуальные.
Sapienti sat!
Re[3]: Override для произвольного метода.
От: fddima  
Дата: 02.12.08 22:04
Оценка: +3
Здравствуйте, Cyberax, Вы писали:

C>Кстати, в Java все методы по умолчанию виртуальные.


Кстати, не факт что это хорошо.
Re[4]: Override для произвольного метода.
От: Cyberax Марс  
Дата: 03.12.08 01:07
Оценка:
Здравствуйте, fddima, Вы писали:

C>>Кстати, в Java все методы по умолчанию виртуальные.

F> Кстати, не факт что это хорошо.
Скажем так, мешает это намного реже, чем помогает.
Sapienti sat!
Re: Override для произвольного метода.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.12.08 05:49
Оценка: +2 -1
Здравствуйте, Chrome, Вы писали:

C>Мне кажется, в .Net runtime можно без особых проблем привнести возможность переписать код произвольного метода.

Главное при рассмотрении любой возможности — задуматься о ее необходимости.
Большинство современных теоретиков ОО-архитектуры сходятся на том, что
а) наследование реализации — это зло, которого нужно по возможности избегать
б) проектирование виртуальных методов — сложное искусство.
Из этого делается два вывода:
1. Классы по умолчанию должны быть sealed. Распечатывать их можно только в том случае, когда вы тщательно продумали то, как ваш код будет работать с произвольными наследниками.
2. Методы класса по умолчанию должны быть невиртуальными. Виртуальными нужно делать только те методы, перегрузка которых не нарушит инварианты класса.

Исправление ошибок — интересная гипотеза. Давайте посмотрим на класс System.String. Что, если любой желающий сможет исправлять в нем "ошибки"? Твой код готов получать в параметрах вместо string какой-нибудь ImprovedString, который исправлен произвольным образом?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Override для произвольного метода.
От: Chrome  
Дата: 03.12.08 11:08
Оценка: :))
Здравствуйте, Sinclair, Вы писали:
S>Главное при рассмотрении любой возможности — задуматься о ее необходимости.

У меня постоянно возникает необходимость через Reflection менять приватные члены классов и вызывать приватные методы.
а кое что даже при помощи Reflection невозможно.
Так что необходимость есть.

S>Большинство современных теоретиков ОО-архитектуры сходятся на том, что

S>а) наследование реализации — это зло, которого нужно по возможности избегать
S>б) проектирование виртуальных методов — сложное искусство.

Печальная история. И очень типичная в нашем мире. Теоретики изобретают теорию. Практики воплощают ее в жизнь.
НО!! То ли первые забыли описать область определения своей теории, то ли практики не удосужились обратить свое внимание на этот аспект, но теория внедряется там, где ее выводы неуместны.
Для массовых библиотек такой подход — зло.

S>Из этого делается два вывода:

S>1. Классы по умолчанию должны быть sealed. Распечатывать их можно только в том случае, когда вы тщательно продумали то, как ваш код будет работать с произвольными наследниками.

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

S>2. Методы класса по умолчанию должны быть невиртуальными. Виртуальными нужно делать только те методы, перегрузка которых не нарушит инварианты класса.


Не открыл метод — лишил клиента возможности доработать и использовать свой класс — заставил его написать собственный подобный — обесценил свою библиотеку.

S>Исправление ошибок — интересная гипотеза. Давайте посмотрим на класс System.String. Что, если любой желающий сможет исправлять в нем "ошибки"?

Ноль проблем — если накосячит — сам виноват, никого больше это не заденет.
Твой код готов получать в параметрах вместо string какой-нибудь ImprovedString, который исправлен произвольным образом?
Так это будет мой код и мой ImprovedString, какие проблемы? Ну в крайнем случае мой код и ВАСИН ImprovedString, пойду к Васе и проблему решу, А вот в Microsoft не могу пойти решать проблему.
Re[2]: Override для произвольного метода.
От: Chrome  
Дата: 03.12.08 11:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Chrome, Вы писали:


C>>Из минусов вижу некоторые проблемы с безопасностью в trusted environment, но эти проблемы преодолимы.


AVK>Главный минус — эта мегафича для оптимизатора все равно что серпом по яйцам. Да, кстати, через profiler api все это уже сейчас имеется.

Не проблема это вовсе. В оптимизации нуждаются считанные проценты кода, не факт, что этот код пересекается с тем, который вы собиратесь модифицировать. Кроме того исходный код состоит из оптимизированного MSIL, наш патч компилируется в оптимизированный MSIL, потом .Net Runtime должен их соединить и откомпилировать в native код, опять же имеет возможность оптимизировать. Где тут проблемы?

C>>Зачем проектировщики библиотек заранее гадают, какие возможности понадобится переопределить пользователям их продукта и через раз не угадывают?(Ведь, чем раньше принято решение — тем больше вероятность ошибки).


AVK>Могу посоветовать очень хорошее решение проблемы — совсем не использовать наследование в качестве публичного интерфейса. Тогда и угадывать ничего не придется.

— я имею в виду очень конкретный случай — программирование под .Net с использованием его стандартных библиотек, куда там без наследования? Или заставить microsoft перепроектировать их билблиотеку — я за!!!
Re[3]: Override для произвольного метода.
От: fmiracle  
Дата: 03.12.08 11:22
Оценка: +2
Здравствуйте, Chrome, Вы писали:

S>Твой код готов получать в параметрах вместо string какой-нибудь ImprovedString, который исправлен произвольным образом?

C>Так это будет мой код и мой ImprovedString, какие проблемы? Ну в крайнем случае мой код и ВАСИН ImprovedString, пойду к Васе и проблему решу, А вот в Microsoft не могу пойти решать проблему.

А если не твой и не Васин? Если ImprovedString из библиотеки от Оракла, которая тебе тоже до жути нужна? К кому пойдешь решать проблему — к Микрософту или к Ораклу?

А сколько ты времени потратишь, прежде чем поймешь, что проблема имеется в неожиданном изменении какого-то класса, который раньше всегда вел себя одним образом а теперь вдруг (с новой версии какой-то третьей библиотеки) вдруг стал вести себя иначе (но ты, заметим, не ожидаешь, что вести он себя стал иначе)?
Re[3]: Override для произвольного метода.
От: Aikin Беларусь kavaleu.ru
Дата: 03.12.08 11:26
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

S>>Главное при рассмотрении любой возможности — задуматься о ее необходимости.

C>У меня постоянно возникает необходимость через Reflection менять приватные члены классов и вызывать приватные методы.

А пример можно? Что-то у меня не часто такое желание возникает

S>>Большинство современных теоретиков ОО-архитектуры сходятся на том, что

S>>а) наследование реализации — это зло, которого нужно по возможности избегать
S>>б) проектирование виртуальных методов — сложное искусство.

C>Печальная история. И очень типичная в нашем мире. Теоретики изобретают теорию. Практики воплощают ее в жизнь.

C>НО!! То ли первые забыли описать область определения своей теории, то ли практики не удосужились обратить свое внимание на этот аспект, но теория внедряется там, где ее выводы неуместны.
C>Для массовых библиотек такой подход — зло.
бла-бла-бла

S>>Из этого делается два вывода:

S>>1. Классы по умолчанию должны быть sealed. Распечатывать их можно только в том случае, когда вы тщательно продумали то, как ваш код будет работать с произвольными наследниками.
C>Автор библиотеки обычно сильно заблуждается относительно того, как тысячи клиентов будут ее использовать, даже если он очень умный человек — он один, а клиентов — тысячи. Не может он ничего "тщательно продумать"
Поменять билиотеку? Связаться с автором? И наконец, разобраться как же нужно правильно использовать эту библиотеку.

S>>2. Методы класса по умолчанию должны быть невиртуальными. Виртуальными нужно делать только те методы, перегрузка которых не нарушит инварианты класса.

C>Не открыл метод — лишил клиента возможности доработать и использовать свой класс — заставил его написать собственный подобный — обесценил свою библиотеку.
Зачем клиенту понадобилось ее дорабатывать???



И еще: переиспользовать класс можно не только наследованием, но и агрегацией.

СУВ, Aikin
Re[3]: Override для произвольного метода.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.12.08 11:34
Оценка:
Здравствуйте, Chrome, Вы писали:

AVK>>Главный минус — эта мегафича для оптимизатора все равно что серпом по яйцам. Да, кстати, через profiler api все это уже сейчас имеется.

C>Не проблема это вовсе.

Аргументированно

C> В оптимизации нуждаются считанные проценты кода




C> Кроме того исходный код состоит из оптимизированного MSIL, наш патч компилируется в оптимизированный MSIL


Если тебе нужно патчить MSIL, то инструментов для этого хватает, бери да пользуйся. Только при чем тут тогда CLR?

AVK>>Могу посоветовать очень хорошее решение проблемы — совсем не использовать наследование в качестве публичного интерфейса. Тогда и угадывать ничего не придется.

C>- я имею в виду очень конкретный случай — программирование под .Net с использованием его стандартных библиотек

Как будто на практике всерьез можно рассматривать их неиспользование

C>, куда там без наследования?


Давай конкретные примеры, иначе это воду в ступе толочь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[3]: Override для произвольного метода.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.12.08 12:18
Оценка: +4
Здравствуйте, Chrome, Вы писали:

C>У меня постоянно возникает необходимость через Reflection менять приватные члены классов и вызывать приватные методы.

C>а кое что даже при помощи Reflection невозможно.
C>Так что необходимость есть.
Вот когда я работал с Delphi, необходимость "вскрывать" неудачно заprivate-нные классы из VCL быстро падала с ростом моей квалификации.

C>Для массовых библиотек такой подход — зло.

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

C>Автор библиотеки обычно сильно заблуждается относительно того, как тысячи клиентов будут ее использовать, даже если он очень умный человек — он один, а клиентов — тысячи. Не может он ничего "тщательно продумать"

Это слишком общее предположение. Именно из-за того, что автор библиотеки не может предусмотреть корректное поведение в миллионах сценариев, ему имеет смысл зафиксировать небольшое количество сценариев и работать только с ними.

C>Не открыл метод — лишил клиента возможности доработать и использовать свой класс — заставил его написать собственный подобный — обесценил свою библиотеку.

Неверно. Можно привести пример возможности использования, которой тебя лишила запечатанность класса string? А вообще, наследование — далеко не лучший, и уж точно не единственный способ "доработки и использования".

C>Ноль проблем — если накосячит — сам виноват, никого больше это не заденет.

C>Твой код готов получать в параметрах вместо string какой-нибудь ImprovedString, который исправлен произвольным образом?
C>Так это будет мой код и мой ImprovedString, какие проблемы? Ну в крайнем случае мой код и ВАСИН ImprovedString, пойду к Васе и проблему решу, А вот в Microsoft не могу пойти решать проблему.
Налицо полное непонимание сути вещей. Разъясняю подробнее: ты используешь библиотеку, разработанную Колей. В библиотеку передаются параметры класса string. Кроме этого, ты используешь другую библиотеку, разработанную Васей. Васина библиотека возвращает объекты, отнаследованные от string, с тонким образом перекрытым методом Equals. В итоге Колина библиотека, естественно, падает. Потому что она рассчитывает на те инварианты string, которые описаны в MSDN.
Ни к Васе ни к Коле ты пойти не можешь — визы и билеты в те места, где они живут, стоят дороже разработки всего того же с нуля.

Что тебе остается? Переделывать обе библиотеки, обучая их работать друг с другом? Отлично, через полгода твоя программа работает, но Коля выпустил новую версию своей либы, в которой пофиксена критическая ошибка. Твои переделки волшебным образом перестают работать. Потому что ты наследовался от Колиных классов, а их устройство теперь изменилось трудносовместимым образом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Override для произвольного метода.
От: Chrome  
Дата: 03.12.08 15:10
Оценка:
C>> В оптимизации нуждаются считанные проценты кода
AVK>
А в чем юмор?

AVK>Если тебе нужно патчить MSIL, то инструментов для этого хватает, бери да пользуйся. Только при чем тут тогда CLR?


Наиболее часто хочется модифицировать методы .Net framework. Эти сборки лежат в GAG. Если я их отредактирую, во первых отвалится подпись, во вторых эти изменения отразятся на других программах.
Чего хотелось бы от CLR — что бы он во время JIT компиляции заменял стандартные функции на пропатченные варианты.
Естественно, все это должно действовать локально в рамках моей программы, на основе ее конфигурационного файла.


AVK>>>Могу посоветовать очень хорошее решение проблемы — совсем не использовать наследование в качестве публичного интерфейса. Тогда и угадывать ничего не придется.

C>>- я имею в виду очень конкретный случай — программирование под .Net с использованием его стандартных библиотек
AVK>Как будто на практике всерьез можно рассматривать их неиспользование
C>>, куда там без наследования?
AVK>Давай конкретные примеры, иначе это воду в ступе толочь.

Нуу эээ — предположим, мы программируем под ASP.Net — и как то так получается, вунуждены создавать наследников от Web.UI.Page
откажемся от наследования? Будем IHttpHanler имплементировать?
захотели добавить свой контрол — будьте добры унаследоваться от Web.UI.Control — иначе не сможете добавить его ни в одну иерархию. А если унаследовались — вынуждены мириться с его реализацией. Как от нее отказаться?

Вот и мечтаю я о патчах.
Re[4]: Override для произвольного метода.
От: Chrome  
Дата: 03.12.08 15:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Chrome, Вы писали:


S>Вот когда я работал с Delphi, необходимость "вскрывать" неудачно заprivate-нные классы из VCL быстро падала с ростом моей квалификации.


C>>Для массовых библиотек такой подход — зло.

S>Для массовых библиотек этот подход — единственно возможный. Потому что иначе невозможно вообще ничего проконтролировать.

Зачем контролировать? Выпустили библиотеку .Net framework v 2.0. Ушла она в свободное плавание. Фиксите иногда критические баги, но это доли процента кода.
Сами работаете над V3.0.
А кому надо использует 2.0, так, как считает нужным.
И зачем что то контролировать?

C>>Не открыл метод — лишил клиента возможности доработать и использовать свой класс — заставил его написать собственный подобный — обесценил свою библиотеку.

S>Неверно. Можно привести пример возможности использования, которой тебя лишила запечатанность класса string? А вообще, наследование — далеко не лучший, и уж точно не единственный способ "доработки и использования".

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

S>Налицо полное непонимание сути вещей. Разъясняю подробнее: ты используешь библиотеку, разработанную Колей. В библиотеку передаются параметры класса string. Кроме этого, ты используешь другую библиотеку, разработанную Васей. Васина библиотека возвращает объекты, отнаследованные от string, с тонким образом перекрытым методом Equals. В итоге Колина библиотека, естественно, падает. Потому что она рассчитывает на те инварианты string, которые описаны в MSDN.


Так это ведь Я использую Колину и Васину библиотеку, и если Колина библиотека падает от того, что Я передал ей обьекты, которые ей не подходят — я и виноват. Хотя сценарий возврата так тонко испоганеных строк экзотичен.

S>Что тебе остается? Переделывать обе библиотеки, обучая их работать друг с другом? Отлично, через полгода твоя программа работает, но Коля выпустил новую версию своей либы, в которой пофиксена критическая ошибка.

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

Нормальные вендоры фиксят ошибки в старых версиях продукта,
и отдельно выпускают новые версии.
Re[5]: Override для произвольного метода.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.12.08 15:35
Оценка:
Здравствуйте, Chrome, Вы писали:

C>>> В оптимизации нуждаются считанные проценты кода

AVK>>
C>А в чем юмор?

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

C>Наиболее часто хочется модифицировать методы .Net framework. Эти сборки лежат в GAG.


Если ты будешь модифицировать содержимое сборок, тебе в любом случае понадобится снести подпись. Следовательно, GAC с немодифицированными сборками тебе уже никак не помеха.

C> Если я их отредактирую, во первых отвалится подпись


Да, что логично

C>, во вторых эти изменения отразятся на других программах.


Нет.

C>Чего хотелось бы от CLR — что бы он во время JIT компиляции заменял стандартные функции на пропатченные варианты.


Profiler API.

AVK>>Давай конкретные примеры, иначе это воду в ступе толочь.


C>Нуу эээ — предположим, мы программируем под ASP.Net — и как то так получается, вунуждены создавать наследников от Web.UI.Page


Проблема в чем?

C>захотели добавить свой контрол — будьте добры унаследоваться от Web.UI.Control


Проблема в чем?

C> Как от нее отказаться?


Никак. Эта задача в рамках дизайна вебформсов нерешаема. Только написанием своего собственного Page.ё

C>Вот и мечтаю я о патчах.


Бесполезно патчить внутренние детали реализации чужого фреймворка — первый же сервиспак порушит все твое приложение напрочь. И чинить будет ой как больно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[5]: Override для произвольного метода.
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.12.08 05:25
Оценка:
Здравствуйте, Chrome, Вы писали:


C>Зачем контролировать? Выпустили библиотеку .Net framework v 2.0. Ушла она в свободное плавание. Фиксите иногда критические баги, но это доли процента кода.

Ну и что, что доли процента.

C>И зачем что то контролировать?

Затем, что иначе начинается анархия и неконтролируемое расползание изменений. Единственный способ борьбы со сложностью софта — четкое введение контрактов. Открытие всех методов всех классов для перегрузки открывает слишком широкий контракт, что сводит возможность неломающих фиксов к нулю.

C>я агитирую за метод динамических патчей произвольных методов библиотеки

C>а вы что предложите в рамках существующей платформы .Net?
Я предлагаю агрегацию.

C>Так это ведь Я использую Колину и Васину библиотеку, и если Колина библиотека падает от того, что Я передал ей обьекты, которые ей не подходят — я и виноват.

И какая тебе радость от того, что ты виноват? Получается так, что платформа не может предоставить тебе нормальные условия для работы.
C> Хотя сценарий возврата так тонко испоганеных строк экзотичен.
Приведи свой сценарий.

C>Нормальные вендоры фиксят ошибки в старых версиях продукта,

C>и отдельно выпускают новые версии.
Я и говорю — пофиксили ошибку. Это потребовало изменений во внутреннем устройстве классов библиотеки; ты был заточен на это внутреннее устройство.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Override для произвольного метода.
От: prVovik Россия  
Дата: 04.12.08 09:46
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Я и говорю — пофиксили ошибку. Это потребовало изменений во внутреннем устройстве классов библиотеки; ты был заточен на это внутреннее устройство.


Еще веселее будет, если посмотреть на это с точки зрения Майкрософта: при любом изменении деталей реализации фреймворка будут переставать работать приложения, заточенные под эти изменённые детали реализации. На кой хрен оно надо Майкрософту?
лэт ми спик фром май харт
Re[5]: Override для произвольного метода.
От: Воронков Василий Россия  
Дата: 04.12.08 11:01
Оценка: +2
Здравствуйте, Chrome, Вы писали:

C>Наиболее часто хочется модифицировать методы .Net framework. Эти сборки лежат в GAG. Если я их отредактирую, во первых отвалится подпись, во вторых эти изменения отразятся на других программах.

C>Чего хотелось бы от CLR — что бы он во время JIT компиляции заменял стандартные функции на пропатченные варианты.
C>Естественно, все это должно действовать локально в рамках моей программы, на основе ее конфигурационного файла.

А зачем модифицировать методы стандартных классов? Какого эффекта хочется добиться? Хак какой-нибудь учудить зачастую можно и через рефлекшин — но при этом надо быть готовым к тому, что все это может спокойно отвалиться в будущем.
Принцип я могу отнаследоваться от любого класса и перекрыть любой метод в корне неправильный. И он на самом деле скорее противоречит ОО-принципам. Я вот не считаю, что наследование — это зло, при грамотном использовании одна из основных фишек ООП, при этом у меня на проектов процентов 90 классов — sealed.
Если мы разрешаем наследование, то класс сам по себе должен быть изначально спроектирован с учетом этого. Не говоря уж о том, что во многих случаях наследование просто бессмысленно. Наследование нужно для полиморфизма. Но даже если наш класс предполагает наследование от него это не означает того, что должна быть возможность перекрыть все методы. Как раз наоборот — должна быть возможность лишь внести некоторые коррективы в поведение класса, специализировать его, не изменяя общий функционал. Все остальное — антипаттерн.
А то, что методы виртуальные по умолчанию — это ошибочный дизайн в джава.

AVK>>>>Могу посоветовать очень хорошее решение проблемы — совсем не использовать наследование в качестве публичного интерфейса. Тогда и угадывать ничего не придется.

C>>>- я имею в виду очень конкретный случай — программирование под .Net с использованием его стандартных библиотек
AVK>>Как будто на практике всерьез можно рассматривать их неиспользование
C>>>, куда там без наследования?
AVK>>Давай конкретные примеры, иначе это воду в ступе толочь.

C>Нуу эээ — предположим, мы программируем под ASP.Net — и как то так получается, вунуждены создавать наследников от Web.UI.Page

C>откажемся от наследования? Будем IHttpHanler имплементировать?

Кстати, неплохая идея

C>захотели добавить свой контрол — будьте добры унаследоваться от Web.UI.Control — иначе не сможете добавить его ни в одну иерархию. А если унаследовались — вынуждены мириться с его реализацией. Как от нее отказаться?

C>Вот и мечтаю я о патчах.

А что конкретно хочется изменить в асп.нет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: Override для произвольного метода.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.12.08 13:46
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Наследование нужно для полиморфизма.


Для полиморфизма нужно наследование интерфейсмов, а здесь речь о наследовании реализаций.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Override для произвольного метода.
От: Воронков Василий Россия  
Дата: 04.12.08 13:55
Оценка: +1 -1
Здравствуйте, AndrewVK, Вы писали:

ВВ>>Наследование нужно для полиморфизма.

AVK>Для полиморфизма нужно наследование интерфейсмов, а здесь речь о наследовании реализаций.

Есть полиморфизм через интерфейсы. Есть полиморфизм построенный на виртуальности. Я не считаю последнее злом, вполне уместное во многих случае решение с т.з. дизайна.

А о чем речь тут можно будет полностью понять, когда автор-таки приведет пример, чего в конкретном случае он хочет добиться через наследование
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.