Форум: "Потрепаться";
Текущий архив: 2003.12.26;
Скачать: [xml.tar.bz2];
Вниз
Виртуальные классы Найти похожие ветки
← →
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
← →
euru (2003-11-13 13:45) [41]Я в кладовку "Прочее" выложил исходник, в котором разделены декларация класса и его реализация. Также имеется возможность поменять реализацию отдельному ОБЪЕКТУ класса. Поддерживается наследование реализаций класса.
http://www.delphimaster.ru/cgi-bin/download.pl?get=1068720088&n=2
← →
Goffman (2003-11-13 14:19) [42][38] euru © (13.11.03 12:26)
Во-первых о доказательствах и т.п. матем. терминах. Математика является описанием мира, следовательно любое матем. утверждение мы должны доказать.
ООП же скорее общая философия разрабоки программ, но имеющая определенные законы, выработанные временем. Это как теория реляционных БД, она небольшая, в ней нет теорем и доказательств, но ей следуют все СУРБД, а за ними и мы, смертные (хотя вроде никто не заставляет).
Инкапсуляция
> Зачем в декларативную часть класса вводить секцию private?
> Она ведь влияет только на внутренние состояние и поведение
> класса, и другие классы все равно никак не смогут ими воспользоваться.
> Не лучше ли было поместить эту секцию в раздел реализации?
На мой взгляд не лишено смысла.Но в принципе-то что изменится? Ну вынесешь состояние в раздел имплементации, все равно оно останется статическим. Ведь объект конструируется не на пустом месте, а как экземпляр класса.
Наследование.
> Разве нельзя использовать механизм, позволяющий реализовать
> наследование именно реализаций, не затрагивая декларативную
> часть класса.
Честно говоря не понял, объясни на птичках:)
Полиморфизм.
> Почему полиморфизм рассматривается на уровне методов? Почему
> не рассматривать весь класс полиморфным?
А разве класс имеющий виртуальный методы не становится полиморфным автоматически?
← →
ИдиотЪ (2003-11-13 14:23) [43]Ты хочешь поменять реализацию отдельного метода, так ?
А как отследить все последствия такой замены ?
любой метод поменять у предка чревато нарушением целостности работы объекта, для тебя ж остальное должно быть черным ящиком.
Все вышеперечисленные методы может не являются необходимыми, но достаточными для обеспечения целостности и непротиворечивости ООП.
можешь конечно придумать свою реализациюю ООП, кто-ж мешает, но над этим думали люди, и какие люди !
ПС
А что должно быть в классе полиморфным ?
← →
euru (2003-11-13 14:44) [44]>Goffman © (13.11.03 14:19) [42]
Есть такие математические утверждения, которые не доказываются. Аксиомами называются. На основании их строится и доказывается вся остальная теория.
РБД, в отличие от ООБД, построены на строгой математике - теории реляционных отношений.
Перенос приватной секции в раздел имплементации дает следующее:
1. философско-эстетическое - зачем показывать всем свои внутренности?
2. прагматичное - если в дальнейшем изменится что-либо в приватной секции, то это никак не затронет описание объекта, и достаточно будет перекомпилировать только модуль, содержащий реализацию этого класса, и не затрагивать модули, содержащие его потомков.
Ссылку на птички :) я дал выше.
← →
ИдиотЪ (2003-11-13 14:47) [45]перекомпилировать реализацию, не трогая остального, с С++ такое можно, там нет жесткой структуры модуля )
← →
euru (2003-11-13 15:00) [46]>ИдиотЪ © (13.11.03 14:23) [43]
Любой класс и все его методы имеют спецификацию, выраженную в декларативной части. Там четко сказано, какие методы у класса есть, какие параметры подаются на вход, что получаем на выходе. Что должен делать данный метод описывается в документации. А нарушить целостность работы можно и в обычном ООП: наследовать класс, а в нем перекрыть виртуальный метод, чтобы он делал не то, что написано в документации (например, вместо перерисовки экрана отформатировал диск).
В полиморфном классе должна быть полиморфной его реализация. См. пример в кладовке.
← →
[NIKEL] (2003-11-13 15:04) [47]
Допустим, инкапсуляция, наследование и полиморфизм - это необходимые признаки. А как же достаточность? Если доказано, что для ООП необходимы эти три признака (кстати, где получить информацию о доказательстве, что необходимы именно эти три признака), но не доказано, что их достаточно, значит, теория неполна, значит, для достаточности могут понадобиться еще какие-то признаки.
ух, как ловко и круто у тебя все сходится :)
а при чем здесь достаточность? ты сам этот термин придумал?
И не получишь ты ни где такую инфу! Такие вещи как ООП COM не доказываются их либо принимают либо нет. Borland приняла ООП (хотя и обрезанную или немного переработанную) если хочешь программировать на дельфине то ты соглашаешься с этими условиями.
Тем более ООП это не теория, это подход к программированию\моделированию.
Инкапсуляция. Позволяет объединить свойства и поведение класса в единое целое с необходимым уровнем доступа к ним (public, protected, private). Зачем в декларативную часть класса вводить секцию private? Она ведь влияет только на внутренние состояние и поведение класса, и другие классы все равно никак не смогут ими воспользоваться. Не лучше ли было поместить эту секцию в раздел реализации?
Какой-такой раздел реализации? зачем придрался к private? У каждого объекта данного класса(человек) могут быть свои закрытые данные(деньги). И никакой другой объект данного класса не сможет получить эти данные (деньги).
Наследование. Почему наследование делается на уровне деклараций, а не реализаций? Почему, чтобы изменить поведение объекта, я должен сначала сделать декларативное наследование, а затем у потомка изменить реализацию? Разве нельзя использовать механизм, позволяющий реализовать наследование именно реализаций, не затрагивая декларативную часть класса.
Да потому, чтобы знать иерархию! Вдумайся в понятие наследование!
чтобы изменить поведение объекта, ты должен определить и реализовать соответствующий код реализации! Придумали же события, надо, присваивай один обработчик, надо - другой.
Никто тебе не неразрешает использование данного механизма(позволяющий реализовать наследование именно реализаций) просто такого механизма нет в идиальном варианте! И ваще, не надо забывать о уровне и механизмаз компилирования и исполнения кода, ты хочешь невозможного. Понимаешь, ты хочешь в уже скомпилированной программе иметь изменяющийся код. Но где условия для таких изменений?
Полиморфизм. Класс полиморфен, если у него есть полиморфные методы (они же виртуальные). Почему полиморфизм рассматривается на уровне методов? Почему не рассматривать весь класс полиморфным?
класс и является полиморфным, если у него есть одинаковые методы (с разной декларацией)
И что ты хочешь от полиморфного ВСЕГО класса? Какие он должен иметь особенности, свойства?
← →
[NIKEL] (2003-11-13 15:10) [48]
А нарушить целостность работы можно и в обычном ООП: наследовать класс, а в нем перекрыть виртуальный метод, чтобы он делал не то, что написано в документации (например, вместо перерисовки экрана отформатировал диск)
ну это не нарушение а правило
любой класс может перекрыть виртуальный метод, для этого и сделана виртуальность методов, чтобы их можно было перекрывать\переопределять в нужных классах а внекоторых наоборот остовлять (зачем дублировать код?).
Ну а твой пример... ты же сам себе не враг, правильно?
Ну а вдругой программе, перекрыть в рамках ООП ты уже ничего не сможешь.
← →
ИдиотЪ (2003-11-13 15:15) [49]любая технология, налагая правила, ограничивает программиста
и это не только в программировании, нравится это или нет.
можно мириться или идти своим путем.
Упорядочение хаоса рождает что-то определенное.
← →
Goffman (2003-11-13 16:41) [50]2euru
Если уж дал пример, напиши уж пару-тройку абзацев в качестве документации.
А то там 4 модуля, на разборки нужно целый день угробить:)
← →
euru (2003-11-13 17:41) [51]>Goffman © (13.11.03 16:41) [50]
ClassMgr.pas можно не смотреть - там реализация механизма идеи.
Entities.pas - собственно сама идея.
Класс TEntity отвечает за декларативную часть. К нему присоединяются все декларации, которые должны характеризовать его поведение и свойства. Он также отвечает за корректное использование реализаций.
Класс TRoleHelper отвечает за реализацию класса. Методы, реализуемые этим классом в контексте кдасса TEntity, объявляются через интерфейсы. При обращении к методам этого класса через объекты класса TEntity или его потомков свойство TRoleHelper.Entity хранит контекст этого объекта. Свойство Super возвращает предыдущую реализацию, таким образом достигается наследование реализаций.
Связь между классами TEntity и TRoleHelper устанавливается с помощью функции assignClassRoles. В нее передаются тип класса, отвечающего за декларативную часть, интерфейсы, описывающие методы, которые принадлежат этому классу, но реализуются отдельно, и класс, реализующий эти методы. Если одному и тому же классу, одному и тому же интерфейсу присвоить новый класс реализации, то он добавится в конец списка реализаций, а к предыдущей реализации можно добраться через свойство Super.
С помощью функции assignObjectRoles можно изменить реализацию отдельному объекту.
TestUnit.pas - это тестовый пример.
Класс TEntityTest - это "подопытный кролик". В разделе инициализации ему присваиваются методы методы интерфейсов IText и IShowText. Реализация этих методов напрямую никак не связана с классом TEntityTest. Однако класс TEntityTestHelper подразумевает, что обращение к ним будет в контексте класса TEntityText. Хочу обратить внимание на реализацию функции showText., а именно, на доступ к свойству Text.
Main.pas - пример использования класса TEntityTest.
Создаются два объекта FEC и FEO этого класса. По умолчанию, у них уже определена реализация методов интерфейсов IText и IShowText. Однако объекту (объекту, а можно было и всему классу) FEO назначается новая реализация методов интерфейса IShowText. Причем ему доступна предыдущая реализация, чем он успешно и пользуется.
Вот, собственно говоря, и все. Что непонятно, спрашивайте.
← →
SkyRanger (2003-11-14 08:10) [52]Инкапсуляция
> Зачем в декларативную часть класса вводить секцию private?
> Она ведь влияет только на внутренние состояние и поведение
> класса, и другие классы все равно никак не смогут ими воспользоваться.
> Не лучше ли было поместить эту секцию в раздел реализации?
А вот сделанно и для того чтобы программа не лазила куда не просят и не получала от ОС "по рукам" (access violetion - будь он проклят!) Все что объявленно в private ЗАЩИЩЕНО и не может быть исковерканно никем кроме этого самого класса и его методами. Тем более что так более "карасивей", нагляднее и правильнее на мой взягляд. Все должно быть в одном месте ...
Наследование.
> Разве нельзя использовать механизм, позволяющий реализовать
> наследование именно реализаций, не затрагивая декларативную
> часть класса.
Если честно мне тоже приходила мысль в голову, но опять же нельзя так жить :) Мы имеем дело с компом, который тупой и ему конкретно нада разжевать что, куда и как! В противном случае чем обстрактней класс, тем больше вероятнее что мозги у проги завернуться в узел, который даже Македонский со своими способностями не распутает! :)
А вообще гляньте сюды: http://alldelphi.front.ru/Manual
Тут неплохо рассказано о класах и наследовании и др. Просто и доступно!
← →
ИдиотЪ (2003-11-14 08:18) [53]еще одна причина жесткости связей - в скорости доступа и вызова методов и свойств. А то компутер будет сначала вспоминать, кто он есть, потом что у него есть и как это вызвать, то что у него есть .
Чисто человеческое поведение, но не думаю, что надо уподоблять компьютер себе .
Я не против виртуальности и полиморфии, но должны быть границы какие-то !
← →
Vuk (2003-11-14 10:25) [54]to euru:
По большому счету, полиморфизм - возможность выполнения операции с одной и той же сигнатурой разными классами разным образом. Обратите внимание, что понятия полиморфизма классов не существует просто потому, что оно не имеет смысла. В принципе, полиморфизм может быть реализован не только при помощи виртуальных методов. Это можно сделать при помощи интерфейсов или той же реализации IDispatch. В WinAPI есть полиморфизм связанный с обработкой сообщений элементами управления.
> Разве нельзя использовать механизм, позволяющий реализовать
> наследование именно реализаций, не затрагивая декларативную
> часть класса.
Наследование - именно декларативная операция. А иначе это уже не наследование, а агрегация + делегирование.
← →
euru (2003-11-17 15:17) [55]Да уж... Не очень-то бурно...
На все мои вопросы "Почему так, а не иначе?" ответы можно сгруппировать следующим образом.
1. Теория ООП. ООП построено на какой-то теоретической базе. Т.е. существует некая математическая формализация ООП, что означает наличие неких непротиворечащих друг другу аксиом, на основании которых строятся определения, теоремы, выводятся вполне определенные и однозначно трактуемые закономерности. И из всего этого должно следовать, что ООП должно быть именно таким.
Однако я такой теории не встречал и думаю, что ее, скорее всего, нет. Если я все-таки не прав, прошу указать мне источники информации.
2. Философия ООП. ООП - это такая концепция, рождению которой мы обязаны великим умам великих людей, и не наше это "холопье" дело интересоваться, почему ООП все-таки такое и почему оно не может быть другим.
3. Так устроен мир. Возможности человека и компьютера не позволят адекватно воспринять какие-либо другие варианты ООП, поэтому лучше все оставить как есть.
4. Некомпетентность. Это уже в мой адрес. Но, по-моему, в тех исходниках, которые я предоставил, видно, что с понятиями классического ООП я знаком.
Так что вопрос остается открытым. :)
← →
euru (2003-11-24 09:29) [56]up
← →
SkyRanger (2003-11-24 09:43) [57]Ну чтож по пунктам:
1. Да такой теории скорее всего нет, но существують логически выведенные правила, которые используются так сказать в процессе...
2. Ну не сказал бы, как писать - дело каждого, просто надо понимать что программа будет работать совместно с другими и надо идти на компромис, дабы они не лезли к друг другу, а ОСь потом обоим давала по шее (Access Violation)
3. Варианты есть, но это личное дело каждого как работать, если вам удобнее иначе - вперед, но не говорите что Вас не предупреждали, коды будите ловить очередной БАГ :)
4. Ну не без этого, а вообще все знать низя, мы для этого и общаемся здесь, дабы повысить свой уровень знаний и умений, и поделится с другими тем что знаешь!
← →
euru (2003-11-27 15:34) [58]>SkyRanger © (24.11.03 09:43) [57]
1. Наверно все-таки эти правила выведены не логически, а эмпирически (методом научного тыка): сначала никаких правил не было, потом появилось структурное программирование, абстрактные типы данных и, наконец, объектно-ориентированное программирование. Вопрос в том, что дальше? Какие еще конструкции могут появиться, расширяющие ООП? Или текущая концепция ООП - это лучшее, что можно было придумать, и ничего нового больше не будет?
2 и 3. Честно говоря, я не совсем понял ответы. Если мы будем писать программы на языке, поддерживающем какие-то новые концепции ООП, то корректность реализации этих концепций при их корректном использовании целиком и полностью лежит на языке программирования. Другое дело, если их неправильно использовать, но это сплошь и рядом встречается и в программах, написанных на текущих языках программирования.
4. Так, собственно, для общения я и написал тему. Ведь для повышения своих знаний и умений нужно не только отвечать на вопросы "как сделать то-то и то-то?", но и пытаться разобраться с вопросами "почему так, а не иначе?".
← →
SkyRanger (2003-11-28 01:55) [59]>euru © (27.11.03 15:34) [58]
>1
Дальше ничего, до тех пор, пока не создадут теорию и не реализуют на практике Искуственный Интелект (AI), вот ему уже понадобятся новые способы описания и формализации данных... Близкие к человеческому мышлению, а енто просто кошмар, мы в самих себя разобраться не можем никак, в своем сознании, так что сначала надо познать все стороны своей психики, а уже потом идти дальше....
>2 и 3
С первой частью согласен, если вы правильно все прописали траблов быть не должно
>Другое дело, если их неправильно использовать, но это сплошь и >рядом встречается и в программах, написанных на текущих языках >программирования.
Я тут имел ввиду что не хотите не придерживайтесь правил, в противном случае может получится то что вы написали.
Это вполне реальный результат.
>4.
Полностью согласен и поддерживаю
← →
euru (2003-12-04 10:01) [60]>SkyRanger © (28.11.03 01:55) [59]
Т.е. если вдруг создание теории искусственного интеллекта затянется эдак лет на двести, развитие методов программирования остановится на достигнутом на данный момент этапе и никаких изменений не будет. Вы в это верите? Я нет. Потому что есть и другие области деятельности, где используется программирование. А они могут развиваться гораздо быстрее теории AI, и им уже не будет хватать возможностей ООП.
Я попытался представить один из возможных вариантов развития ООП, когда уже не классы содержат виртуальные методы, а некоторые сущности могут состоять из виртуальных классов. Причем виртуальные классы не заменяют виртуальные методы, а являются дополнительным средством, расширяющим понятие класса. Так, в свое время добавление в структуру методов раширило возможности этих структур.
В качестве дополнительной информации предлагаю прочесть небольшую статью: http://www.sciteclibrary.ru/rus/catalog/pages/6667.html
По-моему, у меня получилось создать нечто похожее на то, что описывает автор этой статьи.
← →
Странник (2003-12-04 11:40) [61]> euru
Все твои размышлизмы привязаня исключительно к Паскалю.
Но! Мил человек, на Паскале свет клином не сошелся, ООП применяется и в других языках.
Как тебе такая декларация без реализации:
// -- counter.h --
// C++
class counter
{ counter() { value = 0; }
private: int value;
public : getCurrent() { return value; }
getFree() { return ++value; }
}
Все. Никакого модуля реализации нет, но все приличия ООП соблюдены.
← →
euru (2003-12-04 12:25) [62]>Странник © (04.12.03 11:40) [61]
1. Странно, а чем тогда по-твоему являютсяreturn valueиreturn ++value. Мне все-таки кажется, что они как раз-таки и являются реализацией объявленных в классе методов. Так что декларацией без реализации здесь не пахнет.
2. По-моему, я нигде о разделении класса на модули декларации и реализации не писал.
3. А конкретно можешь указать, какие именно "размышлизмы" привязаны к Паскалю. А то как-то неубедительно твое утверждение.
Страницы: 1 2 вся ветка
Форум: "Потрепаться";
Текущий архив: 2003.12.26;
Скачать: [xml.tar.bz2];
Память: 0.67 MB
Время: 0.01 c
