Скачать: CL | DM;

Виртуальные классы   Найти похожие ветки 

← →
euru ©   (2003-11-12 15:37) [0]

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

Почему тогда нет виртуальных классов, в которых реализация класса не зависит от его декларации?

---

← →
vuk ©   (2003-11-12 15:40) [1]

Виртуальные методы - всего лишь средство реализации полиморфизма. Разрыв каких-то там связей здесь ни при чем.

---

← →
Кулюкин Олег ©   (2003-11-12 15:41) [2]

> Почему тогда нет виртуальных классов

А интерфейсы Вам не подойдут?

---

← →
euru ©   (2003-11-12 15:48) [3]

vuk © (12.11.03 15:40) [1]
А что тогда такое полиморфизм?

Кулюкин Олег © (12.11.03 15:41) [2]
Нет. Потому что нельзя создать экземпляр интерфейса.

---

← →
Mike B. ©   (2003-11-12 15:58) [4]

>euru © (12.11.03 15:37)
Интересно, как вы это себе представляете?

---

← →
Reindeer Moss Eater ©   (2003-11-12 15:59) [5]

Почему тогда нет виртуальных классов, в которых реализация класса не зависит от его декларации?

Это как? В интерфейсной секции объявлено одно, а в реализации другое?
Так что ли?

---

← →
ИдиотЪ ©   (2003-11-12 16:02) [6]

Удалено модератором
Примечание: Offtopic

---

← →
han_malign ©   (2003-11-12 16:03) [7]

>euru © (12.11.03 15:37)
- это вопрос, или сарказм?

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

Скажите людям откуда цитата - чтобы знали, чего не нужно читать...

З.Ы. Вообще "виртуальный класс" - это синоним "полиморфного класса", все интерфейсные методы(public) которого виртуальные. Если базовый "виртуальный класс", не имеет ни каккой реализации (есть только методы объявленные - "...;virtual;abstract;"), такой класс называют - "абстрактный класс", или "класс с абстрактным интерфейсом"...

---

← →
REA ©   (2003-11-12 16:04) [8]

Есть еще идея (не знаю уж насколько разумная) сделать наследование данных в базах данных.
Т.е. объявляется например существо с полями руки, ноги, хвост, на его базе человек (плюс мозг), на его базе доцент. Если характеристики нового объекта не заполнены, то берутся из предка.
(Вобщем сам не понял чего хотел)

---

← →
euru ©   (2003-11-12 16:09) [9]

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

---

← →
Кулюкин Олег ©   (2003-11-12 16:16) [10]

> Я себе это представляю так: виртуальный класс - это такой
> класс, реализация которого привязывается не во время компиляции

Мощно задвинул, внушает (с) Гоблин

---

← →
NeyroSpace ©   (2003-11-12 16:18) [11]

>ИдиотЪ © (12.11.03 16:02) [6]
уже сделано, хотя и не компилятор.
посмотри в исходниках Innerfuse Pascal Script 3

---

← →
arbiter ©   (2003-11-12 16:18) [12]

> euru © (12.11.03 16:09) [9]
Интерфейсы

---

← →
Кулюкин Олег ©   (2003-11-12 16:20) [13]

> arbiter © (12.11.03 16:18) [12]
> Интерфейсы

Уже предлагал, отвергли :(

---

← →
euru ©   (2003-11-12 16:25) [14]

>han_malign © (12.11.03 16:03) [7]
Это вопрос.

А почему, собственно, бред? Если метод виртуальный, то при его вызове будет вызываться реализация, зависящая от класса, в котором он реализован.

---

← →
Dimka Maslov ©   (2003-11-12 16:27) [15]

Не путайте абстрактные классы (интерфейсы) и абстрактные методы с их виртуальными сородичами

---

← →
ИдиотЪ ©   (2003-11-12 16:30) [16]

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

---

← →
euru ©   (2003-11-12 16:39) [17]

Виртуальные классы позволили бы
1. уменьшить глубину иерархии классов
2. уменьшить "кустистость" иерархии классов
3. возможно, убрать противостояние между одиночным и множественным наследованием
4. и т.д.

---

← →
ИдиотЪ ©   (2003-11-12 16:40) [18]

ту euru ©
чем аргументируешь твои пункты ?

---

← →
y-soft ©   (2003-11-12 16:43) [19]

>euru © (12.11.03 16:39) [17]
Все это дают интерфейсы

---

← →
han_malign ©   (2003-11-12 17:06) [20]

> Если метод виртуальный, то при его вызове будет вызываться реализация, зависящая от класса, в котором он реализован.
- и что, "разрывается жесткая связь между объявлением метода и его реализацией"??? Каким образом?

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

---

← →
han_malign ©   (2003-11-12 17:20) [21]

> 1. уменьшить глубину иерархии классов
> 2. уменьшить "кустистость" иерархии классов
- это называется класс с "толстым интерфейсом"((с)Страуструп), влечет за собой уменьшение гибкости и увеличение объема кода...

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

З.Ы. Как уже говорили выше, вам нужен OLE интерфейс, в котором есть полезный метод Dispatch.

З.З.Ы. Прежде чем выдвигать "гениальные" идеи, почитайте, для начала, что умные люди пишут, хотя бы, тот же Вирт и Страуструп.

---

← →
euru ©   (2003-11-12 17:22) [22]

>ИдиотЪ © (12.11.03 16:40) [18]
1. Уменьшение глубины иерархии. Так как реализация класса не привязывается к его декларации, то не нужно будет создавать новый класс при изменении какого-либо метода. Достаточно будет указать классу, чтобы он использовал другую реализацию.
2. Уменьшение "кустистости" иерархии. Если нужно единообразно изменить какой-то метод всех потомков одного родителя, достаточно заменить реализацию родителя, а не порождать от каждого потомка новый класс.
3. Здесь пока на уровне интуиции :) Примеров нет.
4. Например. Есть 1000 объектов какого-то класса. Из них у 10 объектов поведение несколько отличается. Необязательно порождать новый класс. Достаточно заменить реализацию этим 10 ОБЪЕКТАМ.

---

← →
euru ©   (2003-11-12 17:39) [23]

han_malign © (12.11.03 17:06) [20]

type
TA = class
procedure M(); virtual;
end;

TB = class(TA)
procedure M(); override;

. . .

procedure X(O: TA);
begin
O.M();
end;

В процедуре X() будет вызываться либо TA.M(), либо TB.M() - в зависимости от объекта O. Какой из этих методов вызовется, определяет компилятор. В дальнейшем может появиться новый класс (потомок TA или TB) с другой реализацией метода M(). Однако это не приведет к переписыванию процедуры X().

OLE - это технология, а не свойство языка.

---

← →
Wizard_Ex ©   (2003-11-12 17:54) [24]

Удалено модератором
Примечание: Offtopic

---

← →
Goffman ©   (2003-11-12 17:57) [25]

[22] euru © (12.11.03 17:22)
Все перечисленное легко уживается с концепцией интерфейса
[23] euru © (12.11.03 17:39)
Ошибаешься, компилятор понятия не имеет экземпляр какого потомка вы передадите в процедуру Х

---

← →
han_malign ©   (2003-11-12 18:00) [26]

> procedure X(O: TA);
> begin
> O.M();
> end;
- вот о том я и говорю, сначала почитайте книги и разберитесь с терминологией - потому что O.M(); - это не реализация метода класса, а вызов метода экземпляра класса...

---

← →
euru ©   (2003-11-12 18:07) [27]

>Goffman © (12.11.03 17:57) [25]
Не совсем удачно выразился. Конечно, компилятор не знает, какой объект будет передаваться в процедуру, но организация механизма вызова метода в зависимости от класса объекта лежит на нем, а не на программисте.

---

← →
ИдиотЪ ©   (2003-11-12 18:32) [28]

ту euru ©
классы можно по разному проетировать снизу-вверх и наоборот.
Реализация со свойствами у Борланда прекрассный пример как можно экземпляры приспособить под конкретные нужды без необходимости писать потомков и менять реализацию их поведения

---

← →
Goffman ©   (2003-11-12 18:41) [29]

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

И что? на то он и компилятор:)
а как же ты собираешься вызывать методы своих, т.н. виртульных классов?
Invoke()? как у IDispatch?
:)

---

← →
euru ©   (2003-11-13 09:45) [30]

>ИдиотЪ © (12.11.03 18:32) [28]
Если все так замечательно, то почему создаются новые классы, необходимые только для того, чтобы изменить поведение их родителя? Неужели это обязательное условие, чтобы, к примеру, для добавления 3-мерных эффектов классу TLabel нужно создавать новый класс T3DLabel?

>Goffman © (12.11.03 18:41) [29]
А как вызываются виртуальные методы? Мы же не задумываемся метод какого класса будет вызываться на самом деле.

---

← →
[NIKEL] ©   (2003-11-13 10:08) [31]

Если все так замечательно, то почему создаются новые классы, необходимые только для того, чтобы изменить поведение их родителя? Неужели это обязательное условие, чтобы, к примеру, для добавления 3-мерных эффектов классу TLabel нужно создавать новый класс T3DLabel?

да потому что это концептуальная идея такая! это концепция классов!
так все и должно быть, если заложена в этот РОД,КЛАСС,СООБЩЕСТВО,КОЛЛЕКЦИЮ И Т.Д данная функциональность, то так и должно быть, класс определяется своими свойствами и событиями. Ты можешь определить ГРУППУ ОДИНАКОВЫХ объектов только потому, что они принадлежат одному классу! И ты 100% уверен, что у всех этих объектов ОДИНАКОВОЕ кол-во свойств и методов! И они все одинаково реализованы.

И если есть (надо сделать) какую то дополнительную\урезанную функционаьность то это уже будет ДРУГОЙ класс. А иначе ты не будешь уверен в функциональности данного класса. Если есть класс куколка, то он и до конца будет куколкой. И надо делать (наследовать) новый класс Бабочка. Надо явно определять где куколки, а где бабочки.

---

← →
ИдиотЪ ©   (2003-11-13 10:09) [32]

euru ©
а давай, сделай супер класс, который все в себя заранее включает, что можно сделать.
Между прочим ты можешь не делать новый класс 3д, вот только задание свойств, будет несколько неудобно

---

← →
euru ©   (2003-11-13 10:42) [33]

>[NIKEL] © (13.11.03 10:08) [31]

procedure repaint(Control: TControl);
begin
Control.repaint();
end;

Получается, здесь я должен начать мучительно сомневаться, потому что не могу быть уверен, repaint() какого класса будет вызываться в это месте.

---

← →
ИдиотЪ ©   (2003-11-13 10:45) [34]

euru ©
можно вызвать любого, хоть предка, хоть потомка при особом желании, только за последствия ты же и отвечаешь
нарушая определенные правила, или, хотя чего-то абстрактного, нельзя получить что-то определенно конкретное

---

← →
euru ©   (2003-11-13 10:48) [35]

>ИдиотЪ © (13.11.03 10:45) [34]
Какие правила я нарушаю?

---

← →
Goffman ©   (2003-11-13 10:55) [36]

2euru

Теория ООП оговаривает три необходимых признака объектной(или если угодно классовой) модели: инкапсуляция, наследование, полиморфизм. Как я понял из ты собираешься отказаться от них всех.
Что же ты предлагаешь взамен? Пока от тебя слышны только выкрики, причем не очень внятные(не в обиду). Приведи хотя бы один пример некорректности текущей теории ООП.

---

← →
[NIKEL] ©   (2003-11-13 10:59) [37]


procedure repaint(Control: TControl);
begin
Control.repaint();
end;

Получается, здесь я должен начать мучительно сомневаться, потому что не могу быть уверен, repaint() какого класса будет вызываться в это месте

именно!
а если repaint() данного контрола подразумевает (по твоей теории о мутированных 10 объектах из 1000 нормальных) обращение к БД для корректного репаинта содержимого?

repaint() какого класса будет вызываться в это месте
а почему ты говоришь о классах? ты же кричал о "тех некоторых объектах которые должны делать что-то подругому"

ЗЫ не надо надуманных задач

---

← →
euru ©   (2003-11-13 12:26) [38]

1. Я нигде не говорил о некорректности теории ООП.
2. Как таковой теории в ООП (в математическом смысле) нет. Если бы она была, по крайней мере, один из пунктов в споре между ООБД и реляционными БД можно было убрать.
3. Если все-таки есть теоретическая база ООП, где можно прочесть математически строгое доказательство, что ООП должно выглядеть именно таким образом.

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

Инкапсуляция. Позволяет объединить свойства и поведение класса в единое целое с необходимым уровнем доступа к ним (public, protected, private). Зачем в декларативную часть класса вводить секцию private? Она ведь влияет только на внутренние состояние и поведение класса, и другие классы все равно никак не смогут ими воспользоваться. Не лучше ли было поместить эту секцию в раздел реализации?

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

Полиморфизм. Класс полиморфен, если у него есть полиморфные методы (они же виртуальные). Почему полиморфизм рассматривается на уровне методов? Почему не рассматривать весь класс полиморфным?

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

---

← →
Igorek ©   (2003-11-13 12:29) [39]

2euru
Реализация класса состоит из реализаций методов. Значит если методы "разрывают связь", то и класс "разрывает"...

---

← →
icWasya ©   (2003-11-13 12:59) [40]

>euru © (12.11.03 17:22) [22]
для таких случаев В Дельфи изобретены Eventы - всякие там OnCreate, OnClick, OnPaint

---

Страницы: 1 2 вся ветка

Скачать: CL | DM;



Память: 0.56 MB
Время: 0.012 c