Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата KILLER @ 29.04.11, 06:46

если я не напишу конструктор явно, его сгенерит компилятор автоматически

А в Delphi - нет. Код, что я привел, вызывается в момент создания. Если у объекта нет конструктора - значит, у него конструктор предка. Так понятнее?

Цитата Flex Ferrum @ 29.04.11, 06:58

Правильно ли я понимаю, что создав TButton (в Delphi), я не смогу передать созданный экземпляр в метод, который принимает на вход TAbstractButton? Ведь TButton - неделимая сущность...

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

Цитата D_KEY @ 29.04.11, 07:02

Объект единое целое, никто не спорит, но объект производного класса так же является и объектом базового, а гарантировать это в состоянии только конструктор базового класса.

Не является. Его можно попользовать как объект базового класса, но заставить его им являться достаточно трудно.
В этом-то и вся разница: он может выглядеть как свой предок, но от этого он предком не станет. Отсюда и взгляд на объект как на единую сущность. Нет цепочки создания объекта по частям, есть единая однообразная процедура.
Идея, кстати, доведена до логического конца в Питоне, где наплевать есть общий предок или нет, важно только чтобы нужный метод был и данные.

Цитата Romkin @ 29.04.11, 08:13

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

Как же так?
Ну вот допустим у нас такая иерархия:
class Car; //! Класс машина
class BMW: public Car //! Класс BMW наследуется от класса машина

Получается что BMW - это BMW, и заставить ее являтся машиной - достаточно трудно, так чтоле?

Добавлено 29.04.11, 08:23

Цитата Romkin @ 29.04.11, 08:13

А в Delphi - нет. Код, что я привел, вызывается в момент создания. Если у объекта нет конструктора - значит, у него конструктор предка. Так понятнее?

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

Цитата D_KEY @ 29.04.11, 07:02

Добавлено Сегодня, 11:21
Romkin, ну так что на счет задачки по интерфейсам?

Хм. Уже и сомневаюсь. Ок.
Есть объект, в частности, это был пинг. Предоставляет он интерфейс IPing, с возможностью задать адрес и собственно метод ping. Есть и событие у объекта, OnPing, когда ответ пришел. Параметр - запись, адрес и время ответа. После вызова Ping идут периодические пинги до уничтожения объекта.
В общем, сделал я. А сисадмин говорит, что пинговать ему одновременно надо много, нужна коллекция этих объектов. Причем чтобы можно было добавлять в нее элемент и извлекать его оттуда (вне коллекции). Элементы предоставляют IPing, у коллекции одно событие OnPing на всех (собственно, это и была цель).
Что получилось:
Элемент коллекции являетсяв враппером для класса, реализующего IPing, при этом выставляет его интерфейс. При извлечении элемента враппер уничтожается, реализация IPing продолжает работу. Сделано это было без реализации IPing враппером.
Понятно изложил или путано?

Цитата Romkin @ 29.04.11, 08:13

Цитата Flex Ferrum @ 29.04.11, 06:58

Правильно ли я понимаю, что создав TButton (в Delphi), я не смогу передать созданный экземпляр в метод, который принимает на вход TAbstractButton? Ведь TButton - неделимая сущность...

Не ерничай. Наследуются данные и поведение. Но они становятся собственными данными и поведением потомка. Точнее, даже можно сказать, что наследуется только поведение, данные становятся собственными данными потомка, в этом и тонкость.
То есть нет разделения на данные предка и потомка, все его. Приватные данные предка недоступны, логически их нет (физически - да, место занимают).
Отсюда и взгляд на объект как на единую сущность, собственно говоря, она создается единым действием, причем одинаковым для любого класса.

Так он и есть единая сущность. И такой сущностью он становится после выполнения конструктора.
Никто не может гарантировать соблюдения инварианта порожденного объекта, кроме конструктора.

Цитата

Цитата D_KEY @ 29.04.11, 07:02

Объект единое целое, никто не спорит, но объект производного класса так же является и объектом базового, а гарантировать это в состоянии только конструктор базового класса.

Не является.

Является.

Цитата

Его можно попользовать как объект базового класса, но заставить его им являться достаточно трудно.

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

Цитата

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

Не приплетай нормальные языки, где нет каши, в отличие от

Цитата KILLER @ 29.04.11, 08:21

Как же так?
Ну вот допустим у нас такая иерархия:
class Car; //! Класс машина
class BMW: public Car //! Класс BMW наследуется от класса машина

Получается что BMW - это BMW, и заставить ее являтся машиной - достаточно трудно, так чтоле?

Ты можешь сказать, что BMW - это Car, и подсовывать его всюду как Car, но вести он себя будет всегда как MBW.

Цитата KILLER @ 29.04.11, 08:21

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

Ты так и не понял, что я сказал Один конструктор на все объекты. Нет этапа конструирования предка, андестенд?

Добавлено 29.04.11, 08:33

Цитата D_KEY @ 29.04.11, 08:31

Производный класс не может знать, что нужно делать, чтобы быть объектом базового.

А он и не должен быть никогда объектом базового. С какого бодуна?

Цитата Romkin @ 29.04.11, 08:32

Ты можешь сказать, что BMW - это Car, и подсовывать его всюду как Car, но вести он себя будет всегда как MBW.

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

Цитата Romkin @ 29.04.11, 08:32

Ты так и не понял, что я сказал Один конструктор на все объекты. Нет этапа конструирования предка, андестенд?

Если у меня есть такая иерархия, что описана мною выше, и при этом класс Car имеет конструктор, а класс BMW не имеет конструктор, и если мы создадим экземпляр класса BMW, конструктор Car - вызван не будет?

Сообщение отредактировано: KILLER - 29.04.11, 08:37

Цитата KILLER @ 29.04.11, 08:36

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

Верно, поведение унаследовано. Но не забывай о полиморфизме, поведение-то потомок может изменить в виртуальных методах. Это же одна из основных идей ООП.

Цитата KILLER @ 29.04.11, 08:36

Если у меня есть такая иерархия, что описана мною выше, и при этом класс Car имеет конструктор, а класс BMW не имеет конструктор, и если мы создадим экземпляр класса BMW, конструктор Car - вызван не будет?

Он будет вызван как обычный метод инициализации, в виде inherited Create. Можешь говорить что нет.

Добавлено 29.04.11, 08:47
Еще раз: в Delphi есть метакласс. Для тех кто в танке: это такая штучка, которая организуется при компиляции и обладает всей информацией, нужной для создания экземпляра своего класса. Ему нет нужды спрашивать о чем-то предков. В С++ же конструирование класса - это сборка предков.

Цитата Romkin @ 29.04.11, 08:44

Верно, поведение унаследовано. Но не забывай о полиморфизме, поведение-то потомок может изменить в виртуальных методах. Это же одна из основных идей ООП.

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

Цитата Romkin @ 29.04.11, 08:44

Он будет вызван как обычный метод инициализации, в виде inherited Create. Можешь говорить что нет.

Он будет вызван автоматически, или же мне нужно будет его руками вызывать, что бы он отработал? Если вручную - то какая же это автоматизация, о которой мы тут говорили? И о каких конструкторах, которые нужно постоянно писать ручками, в С++ ты говорил тогда?

Цитата Romkin @ 29.04.11, 08:32

Ты можешь сказать, что BMW - это Car, и подсовывать его всюду как Car, но вести он себя будет всегда как MBW.

И как BMW, и как Car. Иначе наследование не оправдано.

Цитата

Цитата D_KEY @ 29.04.11, 08:31

Производный класс не может знать, что нужно делать, чтобы быть объектом базового.

А он и не должен быть никогда объектом базового. С какого бодуна?

Должен Иначе наследование не нужно.

Добавлено 29.04.11, 08:52

Цитата Romkin @ 29.04.11, 08:44

Еще раз: в Delphi есть метакласс. Для тех кто в танке: это такая штучка, которая организуется при компиляции и обладает всей информацией, нужной для создания экземпляра своего класса. Ему нет нужды спрашивать о чем-то предков. В С++ же конструирование класса - это сборка предков.

Метаклассы - это прекрасно. Мы вроде говорим о конструировании не классов(как объектов), а их экземпляров.

Цитата KILLER @ 29.04.11, 08:49

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

А смысл тогда наследовать-то?

Цитата KILLER @ 29.04.11, 08:49

Он будет вызван автоматически, или же мне нужно будет его руками вызывать, что бы он отработал? Если вручную - то какая же это автоматизация, о которой мы тут говорили? И о каких конструкторах, которые нужно постоянно писать ручками, в С++ ты говорил тогда?

Руками вызывается в нужном месте. Ты разве не можешь вызвать метод предка из метода потомка, чтобы он что-то там сделал? Причем в нужном месте.

Цитата Romkin @ 29.04.11, 08:53

Руками вызывается в нужном месте. Ты разве не можешь вызвать метод предка из метода потомка, чтобы он что-то там сделал? Причем в нужном месте.

Да, но конструктор не является методом объекта Максимум - методом класса.

Цитата D_KEY @ 29.04.11, 08:50

И как BMW, и как Car. Иначе наследование не оправдано.

Что значит "как Car"? Не согласен. Например, у Car есть абстрактный метод "переключить скорость". В BMV он реализован. В каком это случае мне нужно, чтобы BMW вел себя как Car?! Чтобы получить ошибку вызова абстрактного метода?

Цитата D_KEY @ 29.04.11, 08:50

Должен Иначе наследование не нужно.

См выше. "Быть" - это значит и вести себя так же. Не должен.

Цитата Romkin @ 29.04.11, 08:53

А смысл тогда наследовать-то?

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

Цитата Romkin @ 29.04.11, 08:53

Руками вызывается в нужном месте. Ты разве не можешь вызвать метод предка из метода потомка, чтобы он что-то там сделал? Причем в нужном месте.

Могу, но тут ведь речь не о простых методах идет, а об конструкторах! Конструкторы, должны вызыватся автоматически! Я просто могу забыть вызвать метод базового класса, и у меня поля не проинициализируются, и потом окажется что я работаю с мусором какимто...

Цитата D_KEY @ 29.04.11, 08:54

Да, но конструктор не является методом объекта Максимум - методом класса.

Интересно, а как это метод класса может иметь доступ к полям экземпляра? В Delphi это запрещено.

Добавлено 29.04.11, 09:01

Цитата KILLER @ 29.04.11, 08:56

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

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

Цитата Romkin @ 29.04.11, 08:55

Цитата D_KEY @ 29.04.11, 08:50

И как BMW, и как Car. Иначе наследование не оправдано.

Что значит "как Car"? Не согласен. Например, у Car есть абстрактный метод "переключить скорость". В BMV он реализован. В каком это случае мне нужно, чтобы BMW вел себя как Car?! Чтобы получить ошибку вызова абстрактного метода?

Брр... Абстрактный метод определяет, что мы умеем, как решается позднее. Это всего-лишь позднее связывание, оно не связано с логикой работы.
Машина по "сигналу" "переключить скорость" должна переключать скорость, а не кушать пиццу. Понимаешь, о чем я?

Цитата

Цитата D_KEY @ 29.04.11, 08:50

Должен Иначе наследование не нужно.

См выше. "Быть" - это значит и вести себя так же. Не должен.

Он и ведет себя также. "Переключает скорость".