Это плохой дизайн, на мой взгляд. Более того, изначально на конкретного менеджера вообще ни у кого не должно быть указателя. Изначально там должна быть заглушка или null, для того, чтобы можно было класс тестировать изолированно.

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

Сообщение отредактировал Idle - Aug 17 2012, 10:06

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

уважаемые господа программисты! пожалуйста, вернитесь на грешную землю! никогда помидор ни при каких условиях НЕ МОЖЕТ, НЕ ДОЛЖЕН и даже НЕ ИМЕЕТ ПРАВО знать о палетте, о каком-то менеджере и т.д.! НУ НЕ ЕГО ЭТО ПОМИДОРСКОЕ ДЕЛО!

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

похабно впихнутое врядли можно с достоинством вытащить... см. выше

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

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

+100500

и ышо 5 копеек...
только траблы наступают раньше. ОО сущности от клиента = есть статика. А вот надуманное от программирования = без костылей не будет жить, если клиент всего-то потребовал модернизировать его логику. именно поэтому найденные сущности ОО методологией дают код малоизменяющийся на всём времени жизни проекта. а это существенный плюс, который не могут дать другие методологии разработки софта.

ОО сущности от клиента - это всегда пассивные объекта, ака структуры. Так что разбиение на структуры присущие предметной области - это и правда плюс. Но ООП тут и не пахнет.

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


нет, такого нет

тогда прошу вас подсказать: где по Вашему начинается проектирование?




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

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

ок, менять начальника/работу/страну я не буду по этому поводу, так что вот
и что делать в этом случае? опрос проходом сверху вниз? опрашивать сотни объектов? поллинг т.е. ?
как это называется, где написано что это плохо, по каким словам гуглить "c++ code smells" or what?

а если сотни объектов пошлют месседжи - это, конечно, кардинально изменяет ситуацию? где написано, что поллинг - плохо? в ОС Windows ВСЕ события рождаются в результате ПОЛЛИНГА, система callback-ов весьма слабенькая... и Билл Гейтс не рвет пейсы от этого

так сообщения ожидаются редко, или это не имеет значения?


не знаю, _ты_ мне скажи где написано как надо делать, ссылку пока дали только одну - ни с родителями ни с поллингом не связанную

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

Это понятИйное
Помидор не знает, где находится, но обязан знать, кому жаловаться на свое состояние. Такшта.
Но есть масса чисто технических вопросов: а кто ему, собсна, отдает поток исполнения, этому овосчу?
Становится похоже на то, что и эвенты и поллинг окажутся одинаково хлопотными по ресурсам.
Это всё от постановки задачи Idle, без хотя бы альтернативной формулировки, тема так и останется флеймообразной. Мсм.

традиционное, как я говорил, для программистов: обязать ни в чем не повинный помидор и потом с него требовать в реальной жизни так не бывает. и чем сильнее абстагирование от реальности, тем сложнее объяснить смысловые взаимосвязи... "Заводной апельсин" - читали?