class TButton
{
...
virtual LRESULT OnClick();
...
}
class TEdit
{
...
}
Гуру ООП подскажите как лучше cделать?
Решили написать простенькую прогу на winapi, для того чтобы научиться.
Написали класс кнопки, класс поля ввода, класс окна, каждый клас имеет у нас свой обработчик событий,всебы хорошо, но есть такая проблема как взаимодействие этих классов. Т.е.
хотелось бы что бы все было гибко, удобно и красиво, для того и сделали все на классах, но смотрите:
Создаем объект окна от класса TWindow, создаем кнопку на окне, создаем edit, и тут возникает проблема, как сделать так, чтобы в событии OnClick(TButton) можно было работать с обьектом от TEdit(как в билдере или дельфи, если знакомы). Друг друга то они не видят...
пока есть только одна мысль работать через сообщения... но может как то иначе можно работать?
Написали класс кнопки, класс поля ввода, класс окна, каждый клас имеет у нас свой обработчик событий,всебы хорошо, но есть такая проблема как взаимодействие этих классов. Т.е.
Код:
хотелось бы что бы все было гибко, удобно и красиво, для того и сделали все на классах, но смотрите:
Создаем объект окна от класса TWindow, создаем кнопку на окне, создаем edit, и тут возникает проблема, как сделать так, чтобы в событии OnClick(TButton) можно было работать с обьектом от TEdit(как в билдере или дельфи, если знакомы). Друг друга то они не видят...
пока есть только одна мысль работать через сообщения... но может как то иначе можно работать?
В качестве обработчиков, я бы посоветовал использовать указатели на ф-ции.
По умолчанию указатели указывают на пустую команду, сооветсвенно можно менять адрес в указателе.
По умолчанию указатели указывают на пустую команду, сооветсвенно можно менять адрес в указателе.
Если хочешь, действительно, красивое решение в ООП стиле, то примени паттерн "Посредник" ("Mediator"), т.к. завязка одного контрола на другой - это уже принципиально неверно.
Цитата:
Originally posted by Green
Если хочешь, действительно, красивое решение в ООП стиле, то примени паттерн "Посредник" ("Mediator"), т.к. завязка одного контрола на другой - это уже принципиально неверно.
Если хочешь, действительно, красивое решение в ООП стиле, то примени паттерн "Посредник" ("Mediator"), т.к. завязка одного контрола на другой - это уже принципиально неверно.
честно говоря ничего не понял, где можно про это почитать или если не трудно раскажи немного подробнее.
Цитата:
Originally posted by bleed
честно говоря ничего не понял, где можно про это почитать или если не трудно раскажи немного подробнее.
честно говоря ничего не понял, где можно про это почитать или если не трудно раскажи немного подробнее.
Извини, забыл ссылочку прикрепить.
Исправляюсь: http://ooad.asf.ru/patterns/patterninfo.asp?id=23
даа. я про эти паттрены. какаято мысль непонятная.
может автор гдето просто неправильно выразил идею, но нет. несколько раз перечитал - все верно. абсолютный ужас. перенести логику взаимодействий в один класс. это просто нереальная задача при мало-мальски сложном UI. ктомуже на директоре весит задача маршрутизации и передачи данных. если непредполагаецца запускать такое на 100процессорной системе, то я в недоумении. я вообщето за "меньше циклов-больше указателей".
хотя в целом, если коечто пересмотреть, то идея неплохая, но больше смахивает на пятиколесный велосипед.
Если ближе к теме, то я бы порекомендовал организовать элементы управления(ЭУ) в иерархию и управлять ими через своеобразный адаптер.
CObj
CContainer* p_childs; //контейнер для детей.
CContainer* p_parent; //ptr на parent-контейнер.
CContanier
CObj* p_wrappedobj; //обернутый объект
CContanier* p_next;
CContanier* p_prev;
CComponent: public CObj
CApp* p_application;
// класс для управления иерархией
CAdapter
CObj* p_obj; //управляемый ЭУ.
Add_(); Find_(); CD_(); etc...
Канешна, организовать ЭУ в иерархию можно разными способами, но главная идея здесь в том, что в каждый ЭУ можно поместить соответсвующий код(порожденный от CApp), который будет осуществлять соответственную логику взаимодействий. Критикам сразу хачу сказать что эта идея разрабатывалясь около 5 лет и спорить о ее целесообразности или работоспособности я наверно небуду. :))
может автор гдето просто неправильно выразил идею, но нет. несколько раз перечитал - все верно. абсолютный ужас. перенести логику взаимодействий в один класс. это просто нереальная задача при мало-мальски сложном UI. ктомуже на директоре весит задача маршрутизации и передачи данных. если непредполагаецца запускать такое на 100процессорной системе, то я в недоумении. я вообщето за "меньше циклов-больше указателей".
хотя в целом, если коечто пересмотреть, то идея неплохая, но больше смахивает на пятиколесный велосипед.
Если ближе к теме, то я бы порекомендовал организовать элементы управления(ЭУ) в иерархию и управлять ими через своеобразный адаптер.
CObj
CContainer* p_childs; //контейнер для детей.
CContainer* p_parent; //ptr на parent-контейнер.
CContanier
CObj* p_wrappedobj; //обернутый объект
CContanier* p_next;
CContanier* p_prev;
CComponent: public CObj
CApp* p_application;
// класс для управления иерархией
CAdapter
CObj* p_obj; //управляемый ЭУ.
Add_(); Find_(); CD_(); etc...
Канешна, организовать ЭУ в иерархию можно разными способами, но главная идея здесь в том, что в каждый ЭУ можно поместить соответсвующий код(порожденный от CApp), который будет осуществлять соответственную логику взаимодействий. Критикам сразу хачу сказать что эта идея разрабатывалясь около 5 лет и спорить о ее целесообразности или работоспособности я наверно небуду. :))
Цитата:
Originally posted by kaban_
даа. я про эти паттрены. какаято мысль непонятная.
может автор гдето просто неправильно выразил идею, но нет. несколько раз перечитал - все верно. абсолютный ужас.
даа. я про эти паттрены. какаято мысль непонятная.
может автор гдето просто неправильно выразил идею, но нет. несколько раз перечитал - все верно. абсолютный ужас.
Ну вообще-то автор не один, а основателей четыре и тысячи последователей.
Думаю, проблема в том, что ты не смог понять того, что хотели донести основатели теории паттернов.
Цитата:
Originally posted by kaban_
перенести логику взаимодействий в один класс. это просто нереальная задача при мало-мальски сложном UI.
ктомуже на директоре весит задача маршрутизации и передачи данных.
перенести логику взаимодействий в один класс. это просто нереальная задача при мало-мальски сложном UI.
ктомуже на директоре весит задача маршрутизации и передачи данных.
А кто сказал, что медиатор будет одним?
Почему не организовать иерерхию медиаторов и др. паттернов.
Кроме того элементы управления не несут никакой логики обработки данный и т.п., они лишь являются элементами представления данных и получения команд управления. Сама же бизнесс-логика - это отдельная часть не относящаяся к UI.
Цитата:
Originally posted by kaban_
но главная идея здесь в том, что в каждый ЭУ можно поместить соответсвующий код(порожденный от CApp), который будет осуществлять соответственную логику взаимодействий.
но главная идея здесь в том, что в каждый ЭУ можно поместить соответсвующий код(порожденный от CApp), который будет осуществлять соответственную логику взаимодействий.
Бизнесслогику в каждый элемент?!
Типичная ошибка новичков C++ Builder.
Какое отношение контролл имеет к бизнесс логике?
Кнопка должна знать, что она кнопка калькулятора выполняющая операцию сложения, или он кнопка дверного замка?
Нет. Она должна только замыкать контакты.
Так почему контролл BUTTON должен знать, что по его нажатию надо сложить два числа и вывести их в EDIT ?
Единственная логика взаимодействий - послать сигнал о своём событии посреднику, в случае применения паттерна "медиатор", или всем желающим, в случае применения паттерна "наблюдатель". Как этот сигнал будет интерпретирован и обработан кнопки не касается.
Цитата:
Originally posted by kaban_
Критикам сразу хачу сказать что эта идея разрабатывалясь около 5 лет и спорить о ее целесообразности или работоспособности я наверно небуду. :))
Критикам сразу хачу сказать что эта идея разрабатывалясь около 5 лет и спорить о ее целесообразности или работоспособности я наверно небуду. :))
А зря...
Идея не выдерживает критики в том свете, как ты её представил.
bleed
Создай все объекты в общей области видимости
и тогда все будут друг друга видеть.
Для начала это вполне достаточно и красоты в самой идее построения уже хватит.
Создай все объекты в общей области видимости
и тогда все будут друг друга видеть.
Для начала это вполне достаточно и красоты в самой идее построения уже хватит.