Здравствуйте, Воронков Василий, Вы писали:

ВВ>Есть полиморфизм через интерфейсы. Есть полиморфизм построенный на виртуальности.

Полиморфизм — он всегда через интерфейсы.
То что ты называешь "полиморфизм построенный на виртуальности" это уже комбинация полиморфизма и повторного использования кода базового класса. Для полиморфизма при наследовании используется "интерфейс" (при этом самого ключевого слова interface в языке может и не быть) базового класса.

Так что "Наследование нужно для полиморфизма" — неверно. Если нужен именно полиморфизм, то его замечательно можно получить через интерфейсы. Особенно если они поддерживаются в языке как базовые конструкции языка.

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

F>То что ты называешь "полиморфизм построенный на виртуальности" это уже комбинация полиморфизма и повторного использования кода базового класса. Для полиморфизма при наследовании используется "интерфейс" (при этом самого ключевого слова interface в языке может и не быть) базового класса.
F>Так что "Наследование нужно для полиморфизма" — неверно. Если нужен именно полиморфизм, то его замечательно можно получить через интерфейсы. Особенно если они поддерживаются в языке как базовые конструкции языка.

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

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

F>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Есть полиморфизм через интерфейсы. Есть полиморфизм построенный на виртуальности.

F>Полиморфизм — он всегда через интерфейсы.
F>То что ты называешь "полиморфизм построенный на виртуальности" это уже комбинация полиморфизма и повторного использования кода базового класса. Для полиморфизма при наследовании используется "интерфейс" (при этом самого ключевого слова interface в языке может и не быть) базового класса.

F>Так что "Наследование нужно для полиморфизма" — неверно. Если нужен именно полиморфизм, то его замечательно можно получить через интерфейсы. Особенно если они поддерживаются в языке как базовые конструкции языка.

А как же Template method pattern? Всегда вместо него делать через стратегии, чтобы не было наследования реализации?

Здравствуйте, Воронков Василий, Вы писали:

ВВ> Полиморфизм предполагает что один тип может быть использован в качестве другого если он имеет с ним отношения по принципу генерализация-специализация.
Ничего подобного полиморфизм, конечно же не предполагает.. Это лишь один из способов достижения полимофизма.

ВВ> Повторное использование кода тут вообще не причем.
Конечно же причем.

ВВ> А вот для того, чтобы писать более "абстрактный" код через интерфейсы наследование действительно не нужно. Только это не полиморфизм в прямом смысле слова.
Опять вынужнден тебя определиться с терминами. Что ты понимаешь под терминами "тип", "интерфейс", "полиморфизм" и как они соотносятся друг с другом...

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вы не путаете интерфейсы как контракты и полиморфизм через интерфейсы? Полиморфизм предполагает что один тип может быть использован в качестве другого если он имеет с ним отношения по принципу генерализация-специализация. Повторное использование кода тут вообще не причем. Каждый класс в иерархии наследования должен специализировать поведение вышестоящего класса, а весь код можно хоть во внешние хелперы вынести.
ВВ>И да, наследование нужно именно для полиморфизма. А вот для того, чтобы писать более "абстрактный" код через интерфейсы наследование действительно не нужно. Только это не полиморфизм в прямом смысле слова.

У любого типа всегда есть интерфейс И это да, именно контракт. Интерфейс — это по сути своей контракт. А наличие или отсутствие в языке ключевого слова "interface" это уже детали.
Если нет переиспользования кода, то наследование самих классов друг от друга нафиг не уперлось.

Если брать С++, то у нас цепочка наследования ClassA->ClassB->ClassC. Так вот, добавляем чисто абстрактный класс, имеющий сигнатуру класса А, но не имеющей реализации.
AbstractA->ClassA->ClassB->ClassC

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

Собственно, если нас нужна только перегрузка виртуальных методов в наследниках (специализацию с дополнительными полями рассмотрим ниже), то можно смело переписывать иерархию:

AbstractA->ClassA
AbstractA->ClassB
AbstractA->ClassC

Все обобщенные методы перевести на работу AbstractA. Конкретное поведение реализовывать в ClassA, ClassB, ClassC. Что важно, реализация классов вообще не зависит друг от друга. Что значительно упрощает тестирование и внесение изменений (нет шансов, что изменение класса А вызвало случайный глюк в классе С).


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

AbstractA->AbstractB

и сразу становится очевидно, что наша иерархия по сути равна:
AbstractA->ClassA->(+AbstractB->)ClassB->ClassC

Продолжаем для С:
AbstractA->AbstractB->AbstractC

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

AbstractA->ClassA
AbstractB->ClassB
AbstractC->ClassC

Код работает с AbstractA, AbstractB, AbstractC и наслаждается всеми радостями специализации. А мы опять же независимо друг от друга реализуем А, Б и С. И опять у нас нет шансов, что при модификации А у нас появился случайный баг в С.

Минус — больше кода писать, т.е. отсутствует переиспользование кода при наследовании. Заметим в скобочках, что в иерархии ClassB->ClassC получение классом С интерфейса AbstractB тоже по сути своей является переиспользованием кода (не требуется вводить явно специальный AbstractC и указывать его связь с AbstractB, как это приходится делать в приведенной выше схеме.)


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

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

C>Мне кажется, в .Net runtime можно без особых проблем привнести возможность переписать код произвольного метода.
C>Любого метода любой managed DLL. Кроме того, любой невиртуальный метод класса можно сделать виртуальным.
C>Добавить поля в существующие sealed классы. И много чего еще.

Возможно Вы никогда не слышали про NVI. Но про инкапсуляцию Вы знать должны

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

S>>Главное при рассмотрении любой возможности — задуматься о ее необходимости.
C>У меня постоянно возникает необходимость через Reflection менять приватные члены классов и вызывать приватные методы.
C>а кое что даже при помощи Reflection невозможно.
C>Так что необходимость есть.

Есть необходимость поменять твой подход к использованию библиотек.

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

Ты не понял. Автор предписывает определённые способы использования. Другая часть задачи того же автора — сделать так, чтобы библиотеку нельзя было использовать способом, отличным от предписанного. Для этого и нужны модификаторы доступа.

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

Какой пафос...

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

IB>Опять вынужнден тебя определиться с терминами. Что ты понимаешь под терминами "тип", "интерфейс", "полиморфизм" и как они соотносятся друг с другом...

А вы можете изложить свою точку зрения? Это должно быть интересно. Без иронии.

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

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

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

Здравствуйте, Pavel Dvorkin, Вы писали:

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

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

PD>Если речь идет о классах приложения, то с этим можно и согласиться.
Если речь идет о приложениях, то код всегда можно переписать\изменить.

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

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

PD>>Если речь идет о классах библиотеки общего назначения — извольте тщательно продумывать , коль вы взялись эту библиотеку писать, а не закрывать классы на том основании, что вам лень было продумывать и писать как следует. Потому что иначе вы пользователям этой библиотеки ненужные проблемы создаете.
G>Если пишите библиотеку, то лучше предусмотреть точки расширения с помощью интерфейсов и атрибутов, если язык поддерживает. А классы таки лучше делать sealed по-умолчанию. Но это не касается графических компонент, которые традиционно реализуются через наследование

1.Графические — включая оконные или только собственно графика ? 2. Почему такой отбор ? Традиционно — не аргумент.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

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

PD>>>Если речь идет о классах библиотеки общего назначения — извольте тщательно продумывать , коль вы взялись эту библиотеку писать, а не закрывать классы на том основании, что вам лень было продумывать и писать как следует. Потому что иначе вы пользователям этой библиотеки ненужные проблемы создаете.
G>>Если пишите библиотеку, то лучше предусмотреть точки расширения с помощью интерфейсов и атрибутов, если язык поддерживает. А классы таки лучше делать sealed по-умолчанию. Но это не касается графических компонент, которые традиционно реализуются через наследование

PD>1.Графические — включая оконные или только собственно графика ? 2. Почему такой отбор ? Традиционно — не аргумент.
Еще как аргумент. Если вы создаете кастомный контрол в WinForms, то не используя наследование от наиболее подходящего предка можно потратить много времени в пустую.

PD>И опять-таки, есть разница между наследованием от класса в моем приложении и при расширении бибилиотеки (написании новой). В свое время я отнаследовался от ifstream и ничего плохого в этом не было. Но я вряд ли решился бы выставить этого наследника в качестве расширения библиотеки iostream — покусают
Все что вы делаете внутри своего приложения — исключительно ваша проблема. Если вы создаете классы и выставляете их другим разработчикам без возможности изменения исходного кода, то уже надо быть аккуратнее.

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

PD>>1.Графические — включая оконные или только собственно графика ? 2. Почему такой отбор ? Традиционно — не аргумент.
G>Еще как аргумент. Если вы создаете кастомный контрол в WinForms, то не используя наследование от наиболее подходящего предка можно потратить много времени в пустую.

+1

PD>>И опять-таки, есть разница между наследованием от класса в моем приложении и при расширении бибилиотеки (написании новой). В свое время я отнаследовался от ifstream и ничего плохого в этом не было. Но я вряд ли решился бы выставить этого наследника в качестве расширения библиотеки iostream — покусают
G>Все что вы делаете внутри своего приложения — исключительно ваша проблема. Если вы создаете классы и выставляете их другим разработчикам без возможности изменения исходного кода, то уже надо быть аккуратнее.

Да, но я это сделать не могу. Он же sealed

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если речь идет о классах приложения, то с этим можно и согласиться.
Классы приложения никого не интересуют. Их вообще никто не собирается использовать повторно, поэтому sealed они или не sealed — вопрос второстепенный.
PD>Если речь идет о классах библиотеки общего назначения — извольте тщательно продумывать , коль вы взялись эту библиотеку писать, а не закрывать классы на том основании, что вам лень было продумывать и писать как следует. Потому что иначе вы пользователям этой библиотеки ненужные проблемы создаете.
Налицо трагическое непонимание сути вещей.
Автор библиотеки берет на себя некоторые обязательства. Он обещает, что библиотека выполняет некоторые функции, при штатном ее использовании. При этом очень важно объяснить, какое использование — штатное, а какое — нет. Простой вопрос: нужно ли вызывать в overriden методе метод предка? Если да, то в какой момент? Будет ли работать библиотека, если не вызвать предка? Или получится трудноуловимый баг?
Сама подстановка вопроса подсказывает пытливому уму, что не все методы одинаково полезно перекрывать.

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

Здравствуйте, Кэр, Вы писали:

Кэр>А вы можете изложить свою точку зрения? Это должно быть интересно. Без иронии.
Ну, прежде всего, полиморфизм отнюдь не ограничивается ООП, таким образом утверждать, что полиморфизм предполагает какие-то "отношения между типами по принципу генерализация-специализация" — несколько опрометчиво. Более того, даже если брать ООП, то, например, в динамически типизированных языках, как правило любая переменная полиморфна безовсяких отношений.
Собственно, наследование (отношения между типами по принципу генерализация-специализация) — это способ получить полиморфизм в статически типизированных языках.
В статически типизированных языках, где есть только наследование реализации, оное наследование используется и для получения ad-hoc полиморфных функций и для сокращения количества кода. В языках же оборудованных механизмом явной декларации контракта (e.g. interface), эти самые механизмы предназначены именно для получения полиморфизма в чистом виде, без побочных эффектов в виде унаследованной реализации.
Таким образом, утверждать, что абстрактный код через интерфейсы "не полиморфизм в прямом смысле слова" — довольно смело, но не верно..

Собственно, это и побудило меня в очередной раз спросить ВВ, что именно он имеет ввиду под означенными терминами, особенно меня интересует "полиморфизм в прямом смысле слова" =)
Вообще, у меня складывается впечатление, что ВВ просто выдает знакомые слова в случайном порядке, как только похожий контекст увидит, так как ни одного используемого им термина он так и не смог объяснить своими словами и рассказать что же именно имеется ввиду...
Только и умеет, что на каждую просьбу минус ставить..

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

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

Да, только твоим. Вызванное многократным употреблением библиотеки классов .Net

S>Автор библиотеки берет на себя некоторые обязательства. Он обещает, что библиотека выполняет некоторые функции, при штатном ее использовании. При этом очень важно объяснить, какое использование — штатное, а какое — нет. Простой вопрос: нужно ли вызывать в overriden методе метод предка? Если да, то в какой момент? Будет ли работать библиотека, если не вызвать предка? Или получится трудноуловимый баг?
S>Сама подстановка вопроса подсказывает пытливому уму, что не все методы одинаково полезно перекрывать.

А я заявил, что надо перекрывать все ? Где ? Я этого вовсе не утверждал.

S>По вопросу запечатывания класса поясняю еще раз: да, допустим я всё продумал. И вижу, что никакие модификации поведения этого класса путем наследования не могут гарантировать выполнение инвариантов. Повторно вопрошаю: какие изменения вы хотите сделать в классе System.String?

Не пойдет. Кроме System.String (о нем предпочту не высказываться, ибо он притча во языцех) в .Net еще десятки классов, где изменения я вполне готов сделать и обосновать.

Например


Directory Class
Exposes static methods for creating, moving, and enumerating through directories and subdirectories. This class cannot be inherited.

Да, тут не просто sealed, а sealed поскольку static, но все равно — нельзя расширить функциональность. А что, собственно, будет плохого, если я устрою в наследнике enumerating без коллекций, а по одному через PInvoke ? О виртуальности тут и речи нет, методы статические, почему я не могу еще один добавить. И какие инварианты здесь нарушаются ?

И таких примеров десятки, если не сотни.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Например

PD>Directory Class
PD>Exposes static methods for creating, moving, and enumerating through directories and subdirectories. This class cannot be inherited.

PD>Да, тут не просто sealed, а sealed поскольку static, но все равно — нельзя расширить функциональность. А что, собственно, будет плохого, если я устрою в наследнике enumerating без коллекций, а по одному через PInvoke ? О виртуальности тут и речи нет, методы статические, почему я не могу еще один добавить. И какие инварианты здесь нарушаются ?
Я плакал... писать MyDirectory.StaticMethod уже религия не позволяет?

PD>И таких примеров десятки, если не сотни.
Давай еще.

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

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да, только твоим. Вызванное многократным употреблением библиотеки классов .Net
Хм. Вообще-то это далеко не единственная библиотека, с которой я имел счастье столкнуться в своей девелоперской жизни.


PD>А я заявил, что надо перекрывать все ? Где ? Я этого вовсе не утверждал.
Ты, вроде как, спорил с моей точкой зрения. Она совершенно недвусмысленным образом изложена в сообщении, которому ты поставил минус.

PD>Не пойдет. Кроме System.String (о нем предпочту не высказываться, ибо он притча во языцех) в .Net еще десятки классов, где изменения я вполне готов сделать и обосновать.
PD>Например

PD>Directory Class
PD>Exposes static methods for creating, moving, and enumerating through directories and subdirectories. This class cannot be inherited.
Это какой-то неудачный пример. Пару лет назад аналогичный пример приводил тут кто-то, желающий либо запихать в Math всю математику вообще (см. справочних Г. и Т. Корн). Или, по крайней мере, дать наследоваться от Math.
В данном случае совершенно понятно, что это совершенно ненужно. Пиши свой класс, со своими методами — и всё будет работать. Главное — не пытаться подменить задачу некоторым конкретным решением.
PD>И таких примеров десятки, если не сотни.
Пока ни одного примера в топике не прозвучало. Только абстрактные пожелания встроить прямо в платформу перекрывать вообще нахрен всё.

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

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

Более того, большинство из тех примеров, которые встречались лично мне, впоследствии имели более аккуратное решение, предусмотренное (sic!) автором библиотеки.
Ну, вот простой пример: как сделать WebRequest к некоторому адресу, и передать ему некий нестандартный Host header?
На первый взгляд, библиотеку делали тупые козлы, потому что Host Header намертво зашит в реализацию, и никакого способа порулить им вручную нет. И все способы перекрытия методов стандартных классов закрыты разработчиком.
Упс! Неужели нам придется применять хардкорный reflection, profiler API, или copy-paste 90% system.net для того, чтобы это обойти?
Оказывается, нет. Штатный способ добиться результата — это указать адрес целевой машины в качестве Proxy, а нужный хост указать в виде URL.

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

F>>Полиморфизм — он всегда через интерфейсы.
F>>То что ты называешь "полиморфизм построенный на виртуальности" это уже комбинация полиморфизма и повторного использования кода базового класса. Для полиморфизма при наследовании используется "интерфейс" (при этом самого ключевого слова interface в языке может и не быть) базового класса.

F>>Так что "Наследование нужно для полиморфизма" — неверно. Если нужен именно полиморфизм, то его замечательно можно получить через интерфейсы. Особенно если они поддерживаются в языке как базовые конструкции языка.

A>А как же Template method pattern? Всегда вместо него делать через стратегии, чтобы не было наследования реализации?

А он почти как синглетон — антипатерн. Но не такой разрушительной силы слава богу.

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

A>>А как же Template method pattern? Всегда вместо него делать через стратегии, чтобы не было наследования реализации?

GIV>А он почти как синглетон — антипатерн. Но не такой разрушительной силы слава богу.

А можно раскрыть мысль?