Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Albatros, Вы писали:
S>>>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.
A>>В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?
VD>Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.
VD>Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.
Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Albatros, Вы писали:
S>>>>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.
A>>>В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?
VD>>Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.
VD>>Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.
A>Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности.
Ну у меня например тема типов данных стойко ассоциируется с вот этим
Здравствуйте, FR, Вы писали:
VD>>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.
FR>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, FR, Вы писали:
VD>>>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.
FR>>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:
Z>Почему для этой цели не используется protected?
ЕМНИП, если надо закрыть возможность дёрнуть реализацию предка из потомка.
Здравствуйте, Albatros, Вы писали:
A>>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. G>>Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.
A>Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.
Уважаемый бывший препод МГТУ, какой конкретно ваш опыт опровергает полиморфизм через интерфейсы? Это самое чистое проявление полиморфизма, которое только можно себе представить.
FR>>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:
Z>Почему для этой цели не используется protected?
Потому что он не подходит, так как позволяет вызывать DoProccess из наследников,
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Albatros, Вы писали:
A>Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция. http://en.wikipedia.org/wiki/Interface_inheritance
A>Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов). Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ.
По ссылке выше можно узнать и о полиморфизме интерфейса. Совершенно ни к чему выдумывать определения для давно названных вещей.
A>Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.
К сожалению лычка "бывшего препода программирования" не добавляет знаний и не свидетельствует о них.
Попытайтесь как-то свой опыт скореллировать с опытом более опытных коллег. Пока не было поводов считать что ваш опыт ценнее и лучше других вместе взятых.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Albatros, Вы писали:
A>>>Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода.
G>>Наверное стоит начать отсюда
G>>Или отсюда
A>А вы, уважаемый, не думали, что речь там идет о интерфейсе класса, а не о чистом интерфесе? Да и википедия не самый авторитетный источник
А ваша этимология слова полиморфизм кажется притянута за уши, как у Задорнова.
Здравствуйте, Sinclair, Вы писали:
VD>>Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную. S>Добавлены в TP 5.5, в 1989 году, вместе с ключевыми словами object и virtual.
То есть добавлены для поддержки ООП?
Ну, так а что ты там про наследие былых времен то рассказывал?
Банальная ошибка дизайна. У Хейльсберга их всегда много было. Вот тот object, например. Только от него вовремя отказались, а от странного применения privat — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Albatros, Вы писали:
VD>>Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.
VD>>Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.
A>Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности.
У меня ощущение, что вы с самого начала троллите.
Но я так боюсь показаться невеждой, что готов обосновать все свои утверждения.
Какое из двух приведенных утверждений я должен обосновать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Банальная ошибка дизайна. У Хейльсберга их всегда много было. Вот тот object, например. Только от него вовремя отказались, а от странного применения privat — нет.
А что, уже отказались? В 2000-х Delphi поддерживал object в полный рост. Вся семантика была обратно совместимой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Albatros, Вы писали:
A>>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. G>>Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.
A>>>Наследования интерфейсов нет.
G>>
G>>intarface IA {}
G>>intarface IB:IA {}
G>>
A>>>Не путайте твердое с мягким. G>>Ты полную чушь говоришь.
A>Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция.
Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.
Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.
Например так:
class A
{
private IB b;
void C()
{
b.C();
}
}
A>Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов).
Тоже неверно. В С++ есть наследование реализации без наследования интерфейса.
A>Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ.
Ты сначала определение полиморфизма изучи, а то "необеспеченный полиморфизм" тут никто не поймет.
A>Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.
Ты в этом посте три раза выдумал определения, которых я больше нигде не встречал. Приведи в порядок терминологию, иначе тебя вообще никто не поймет.
Ссылки про полипорфизм я уже дал. Также стоит почитать спецификации языков, хотябы по-диагонали. Узнаешь много нового.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.
VD>Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.
VD>Видимо по этому в ОКамле и используют модули вместо классов.
FR>>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.
В Delphi ограничения видимости не распространяются на текущий модуль. То есть внутри одно модуля ограничения видимости не действуют, и любой код в модуле имеет неограниченный доступ ко всем членам всех классов, объявленных в этом-же модуле. Поэтому утверждение "объекты одного и того же класса не могут копаться у друг друга в кишках" не соответствует действительности.
Во-вторых, потомок, объявленный в другом модуле, не имеет доступа к приватным полям предка, поэтому утверждение "потомки видят private методы предков" также некорректно. Они их действиельно видят, но только если объявлены в одном модуле, но то-же видит и любой другой код этого модуля.
С какого-то момента (точно позже D7) ввели strict private. Подробностей о нём я не знаю, но вроде как он закрыл видимость таких членов внутри модуля.
Здравствуйте, Sinclair, Вы писали:
S>К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.
Ну как-же нет наследования. Во-первых наследовать можно свой интерфейс от чужого, всё, что требуется — библиотека типов. Во-вторых, есть аггрегация, которая суть наследование включением. Наследование включением не подразумевает полиморфизм, но его обеспечивают интерфейсы.
Здравствуйте, gandjustas, Вы писали:
G>Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.
G>Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.
Ну так это другое наследование, мы про разные вещи говорим! Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно
это разные вещи.
Это не композиция, это делигирование ты написал. А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.
G>>Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.
A>Ну так это другое наследование, мы про разные вещи говорим! Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно A>это разные вещи.
Поразительное упорство в невежестве после стольких ссылок
A>Это не композиция, это делигирование ты написал. А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код).
Еще одно выдуманное определение
A>Википедию почитай, подучись. http://en.wikipedia.org/wiki/Object_composition
Советую обратить внимание на примеры, особенно на паскалевский.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.
G>>Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.
A>Ну так это другое наследование, мы про разные вещи говорим!
У нас уже разные наследования появились?
Я знаю только два: наследование интерфейсов и наследование реализации. Композиция ни к одному, ни к другому не относится.
A>Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно это разные вещи.
А ты ссылки-то читал про полиморфизм? В курсе что generics\шаблоны — тоже полиморфизм, перегрузка функций — аналогично.
A>Это не композиция, это делигирование ты написал.
А в чем разница?
A>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?
Здравствуйте, gandjustas, Вы писали:
A>>Это не композиция, это делигирование ты написал. G>А в чем разница?
A>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись. G>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?
Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Это не композиция, это делигирование ты написал. G>>А в чем разница?
A>>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись. G>>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?
A>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.
Для тебя конечно просто, а я вообще перестал понимать что ты пытаешься сказать. Ты слишком вольно обращаешься с терминологией. Поэтому давай перейдем к более формальным языкам.
Повторяю: покажи в коде различия между композицией и делегированием, на том примере что я приводил.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Albatros, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
A>>>>Это не композиция, это делигирование ты написал. G>>>А в чем разница?
A>>>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись. G>>>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?
A>>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.
G>Для тебя конечно просто, а я вообще перестал понимать что ты пытаешься сказать. Ты слишком вольно обращаешься с терминологией. Поэтому давай перейдем к более формальным языкам. G>Повторяю: покажи в коде различия между композицией и делегированием, на том примере что я приводил.
Это уходит от темы. Делегирование — это передача реализации, т.е. это механизм событий и вызова методов. Обращение к методу B — это делегирование, а приватное поле — агрегация.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
"Нормальные герои всегда идут в обход!"
