Виртуальные классы

← →
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. Некомпетентность. Это уже в мой адрес. Но, по-моему, в тех исходниках, которые я предоставил, видно, что с понятиями классического ООП я знаком.

Так что вопрос остается открытым. :)

Ну чтож по пунктам:
1. Да такой теории скорее всего нет, но существують логически выведенные правила, которые используются так сказать в процессе...
2. Ну не сказал бы, как писать - дело каждого, просто надо понимать что программа будет работать совместно с другими и надо идти на компромис, дабы они не лезли к друг другу, а ОСь потом обоим давала по шее (Access Violation)
3. Варианты есть, но это личное дело каждого как работать, если вам удобнее иначе - вперед, но не говорите что Вас не предупреждали, коды будите ловить очередной БАГ :)
4. Ну не без этого, а вообще все знать низя, мы для этого и общаемся здесь, дабы повысить свой уровень знаний и умений, и поделится с другими тем что знаешь!

>SkyRanger © (24.11.03 09:43) [57]
1. Наверно все-таки эти правила выведены не логически, а эмпирически (методом научного тыка): сначала никаких правил не было, потом появилось структурное программирование, абстрактные типы данных и, наконец, объектно-ориентированное программирование. Вопрос в том, что дальше? Какие еще конструкции могут появиться, расширяющие ООП? Или текущая концепция ООП - это лучшее, что можно было придумать, и ничего нового больше не будет?

2 и 3. Честно говоря, я не совсем понял ответы. Если мы будем писать программы на языке, поддерживающем какие-то новые концепции ООП, то корректность реализации этих концепций при их корректном использовании целиком и полностью лежит на языке программирования. Другое дело, если их неправильно использовать, но это сплошь и рядом встречается и в программах, написанных на текущих языках программирования.

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

>euru © (27.11.03 15:34) [58]

>1
Дальше ничего, до тех пор, пока не создадут теорию и не реализуют на практике Искуственный Интелект (AI), вот ему уже понадобятся новые способы описания и формализации данных... Близкие к человеческому мышлению, а енто просто кошмар, мы в самих себя разобраться не можем никак, в своем сознании, так что сначала надо познать все стороны своей психики, а уже потом идти дальше....

>2 и 3
С первой частью согласен, если вы правильно все прописали траблов быть не должно

>Другое дело, если их неправильно использовать, но это сплошь и >рядом встречается и в программах, написанных на текущих языках >программирования.
Я тут имел ввиду что не хотите не придерживайтесь правил, в противном случае может получится то что вы написали.
Это вполне реальный результат.

>4.
Полностью согласен и поддерживаю

>SkyRanger © (28.11.03 01:55) [59]
Т.е. если вдруг создание теории искусственного интеллекта затянется эдак лет на двести, развитие методов программирования остановится на достигнутом на данный момент этапе и никаких изменений не будет. Вы в это верите? Я нет. Потому что есть и другие области деятельности, где используется программирование. А они могут развиваться гораздо быстрее теории AI, и им уже не будет хватать возможностей ООП.

Я попытался представить один из возможных вариантов развития ООП, когда уже не классы содержат виртуальные методы, а некоторые сущности могут состоять из виртуальных классов. Причем виртуальные классы не заменяют виртуальные методы, а являются дополнительным средством, расширяющим понятие класса. Так, в свое время добавление в структуру методов раширило возможности этих структур.

В качестве дополнительной информации предлагаю прочесть небольшую статью: http://www.sciteclibrary.ru/rus/catalog/pages/6667.html
По-моему, у меня получилось создать нечто похожее на то, что описывает автор этой статьи.

> euru
Все твои размышлизмы привязаня исключительно к Паскалю.
Но! Мил человек, на Паскале свет клином не сошелся, ООП применяется и в других языках.
Как тебе такая декларация без реализации:
// -- counter.h -- // C++ class counter { counter() { value = 0; } private: int value; public : getCurrent() { return value; } getFree() { return ++value; } }
Все. Никакого модуля реализации нет, но все приличия ООП соблюдены.

>Странник © (04.12.03 11:40) [61]
1. Странно, а чем тогда по-твоему являются return value и return ++value. Мне все-таки кажется, что они как раз-таки и являются реализацией объявленных в классе методов. Так что декларацией без реализации здесь не пахнет.
2. По-моему, я нигде о разделении класса на модули декларации и реализации не писал.
3. А конкретно можешь указать, какие именно "размышлизмы" привязаны к Паскалю. А то как-то неубедительно твое утверждение.

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