а что мешает развить тему и как ты решил что меня это не интересует?


это секретная информация, мне просто заменить поток или фрагмент пакета на помидор, но придумать что-то дальше сложнее - всё равно скажут что у меня всё протухло и надо всё переделывать а вот это мне не надо - всё переделать не в моей власти

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

возвращаясь к баранам...
только опираясь на эти сущности (которыми оперируют в разговорах спецы рядом с вами) вы сможете выстроить (подчеркну ещё раз - это очень важно!) статическую модель сущностей которые будут константа на протяжении жизни всего объекта. т.е. они будут последними кандидатами на пересмотрение или модификацию. Исходя из этого ничего у вас не протухнет. Это будет означать, что бизнес задача вся сама по себе изменилась. что бывает крайне редко(война, наводнение, потоп, конец света - кстати скоро ). Отсюда видно, что переделывать Вам при таком подходе не придётся. Потому как если меняется бизнес задача - обычно делают заново всю структуру и взаимодействие. Это шире(!) чем рефакторинг...

ты очень лихо фантазируешь о том что я хочу, всегда так делаешь? в чём сложность спросить у меня "ты хочешь, чтобы я придумал объектную модель?" и подождать мой ответ? тебе так проще? что мне сделать, чтобы упростить наше общение чтобы тебе не пришлось фантазировать?


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

ни одной ссылки по делу, ни одной! хоть бы ссылку на главу бесплатной "thinking in с++" про главу с декомпозицией
весь трындёж про то, что мол в реальном мире помидор не говорит менеджеру и про заказчиков с требованиями

Xenia, спасибо!


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

Через вызов виртуального метода объекта, уже ж говорили.
Родитель смотрит, что это не ему, вызывает унаследованный метод. Про VMT , пример kobject и проч. поговорили. Других вариантов не видно. Аминь.

ок, "богородица, менеджера палеты прогони!"

В отпуске пропустил дискуссию, но выскажусь

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

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

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

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

так и делаю, вопрос в том как объекту узнать указатель на владельца владельца


согласен, правильно будет 'владелец', а не 'родитель'

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

Ба! Да у Вас (ТС) - налицо извечные проблемы взаимоотношений уровней OSI!!!
Дык это и решается тривиально: редкое событие == эвент, частое == поллинг. Ну я не могу...
А Вы думаете, чего оно так организовано? Правильна! Чтобы уровень 7 ваааще никак не трогать и дать возможность умереть от некрасивости энд-юзеру.

неа, такой проблемы нет
у меня проблема - незнание с++ , т.к. на работе си и как таковой c++ не нужен, а объектный подход нужен

Сообщение отредактировал Idle - Aug 20 2012, 14:49

да, тоже вариант