си, паттерны ооп, разбиение на объекты, parent's parent, детско-родительские отношения Опции

[Idle]

не использую си++, использую си, абстрактные типы данных через incomplete structure pointer-ы
собственно вопрос, как правильно организовывать взаимодействие объектов, когда "вложенный объект" должен вызывать родителя родителя?

ну например, есть палета ящиков с помидорами, ящик с помидорами, и помидор
помидор портится через неделю и вызывает владельца всей палеты, что я мол испорчен

что почитать на эту тему с учётом языка?

Сообщение отредактировал Idle - Aug 15 2012, 18:59

[ARV]

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

[Idle]

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

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

Это понятИйное
Idle, без хотя бы альтернативной формулировки, тема так и останется флеймообразной. Мсм.

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

[kolobok0]

...всё равно скажут что у меня всё протухло и надо всё переделывать а вот это мне не надо - всё переделать не в моей власти

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

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

[Idle]

Вы хотите чтоб тут народ родил за вас объектную модель вашего бизнеса(задания)??? А Вы чтоб потом закодили...кхм.. красиво аднака...

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

возвращаясь к баранам...

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

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

Xenia, спасибо!


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