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

[Idle]

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

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

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

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

[_Pasha]

Дык... томат говорит "уберите меня!!!" т.е отправляет сообщение.
Тот, кому по должностной инструкции положено, обрабатывает сообщение и убирает.
Т.е., поскольку "всё уже украдено до нас" - основные дебри сложности переносятся на обработку и маршрутизацию эвентов. А Вы хотите их сразу же удобно типизировать а оно требует софта для принятия решения, куда это дальше перенаправить.

Сообщение отредактировал _Pasha - Aug 16 2012, 09:00

[Idle]

Тот, кому по должностной инструкции положено, обрабатывает сообщение и убирает.

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

А Вы хотите их сразу же удобно типизировать .

ну менеджер(компоненты системы) типизирован и абстрагирован без меня, моё дело - палета и ниже
а внутри я удобно типизирую ввиду тестирования и tdd из-за оболваненности западной пропагандой

А вот про исключения и их распространение в С++ и почитать. И вообще про механизм исключений (exeptions) в других языках.
Ибо то, что хочется это и есть типичное применение этого механизма, который можно и на С реализовать, если очень захотеть.

посмотрю, спасибо

имхо, все с ног на голову! яйцо курице ничего не сообщает
...
по-моему, так гораздо логичнее.

это всё классно, но "поллинг" штука накладная, поэтому в спецификации на склад мне специфицировали именно "прерывание"
но если именно так и принято, то спасибо за ответ

[ARV]

это всё классно, но "поллинг" штука накладная, поэтому в спецификации на склад мне специфицировали именно "прерывание"
но если именно так и принято, то спасибо за ответ

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


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