При чем тут фрэймворки...

Можно, но опять при чем тут это?
Ты же использует TObject тот же, если надо что-то визуальное сделать.


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

Складывает впечатление, что для тебя программирование делится на визуальное и не визуальное. Однобоко однако.

Далеко не только, тем не менее, такое структурирование - уместно ;)

TObject - это не более чем корневой объект фреймворка VCL, который существует не только для дельфей, но и для сей и для пхп.
искать по словам delphy for php - там и события и визуальный редактор и тп плюшки.
на уровне языка никаких событий нет. насколько мне известно на уровне языка события есть только в аспектно-ориентированных языках.

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

и ещё, в пыхе класс фактически является объектом-синглетоном. банально потому, что он умеет хранить в себе данные, то есть ведёт себя как объект.



Это сообщение отредактировал(а) egao - 6.8.2007, 20:42

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


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


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


Согласен.


Не согласен. Всякая вещь полезна если ею правильно пользоваться. И классы не исключение. Но и не панацея от всего.


Если ты про статические члены класса, то ты прав. Однако в данном случае это идет только на пользу. Кстати, как-то пытался использовать такую возможность в ObjectPascal и не нашел... мож ее там и нет?

Mal Hack, 
TObject, как уже было сказано, не более чем корневой объект фреймворка VCL. Это не базовый объект языка.

SamDark, 
Не VCL единым.


http://ru.wikipedia.org/wiki/TObject

http://www.delphisources.ru/pages/faq/faq_...Object.php.html


В большинстве языков с элементами ООП применен принцип базового класса - все остальне которые являются его наследником.
А в похапэ такого нет - да это особо и не нужно.

Это сообщение отредактировал(а) WolfON - 7.8.2007, 12:40

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


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


Да, так, но если честно, не совсем могу себе представить задачу, где бы это было бы необходимо.


Это базовый класс для описания визуальных объектов в среде OP...

ORM?

это базовый класс по умолчанию для любого user-defined класса.

я имел ввиду изменение интерфейса объекта во время работы.


Все поняли что это 

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

Daevaorn, 
Кстати, гадость ещё та т.к. тормознутая из-за дополнительных запросов...

да есть такое. но вопрос решаемый, т.е. найти оптимальный вариант можно. а положительные стороны перевешивают эти недостатки.

А на практике где применимо? Мне чисто из любопытсва интересно.

Mal Hack, 
На практике применяется обычно несколько другой вид ORM.

См. propel.