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

[Idle]

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

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

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

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

[Idle]

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

да, то что надо

ага

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

CODE

Kobjects are usually embedded in other structures and are generally not interesting on
their own. Instead, a more important structure, such as struct cdev, defined in
<linux/cdev.h>, has a kobj member:
/* cdev structure - object representing a character device */
struct cdev {
struct kobject kobj;
struct module *owner;
const struct file_operations *ops;
struct list_head list;
dev_t dev;
unsigned int count;
};

осталось, собственно, два момента
- как оформить интерфейсы между модулями: если везде передавать kobject, то будет куча container_of даже там, где вызов метода идёт сверху, а если делать разделение вызов сверху/снизу - будет путаница
- как юнит-тестить вызовы снизу вверх, т.е. нужно насоздавать цепочку родителей и только потом за_stub_ить метод

[_Pasha]

посмотрел на использование структуры kobject в ядре linux - оно
структура вставляется внутрь "класса" и указатель на неё (а не на сам экземпляр родителя) передаётся при создании потомка и сохраняется в kobject потомка в поле parent
и потом по цепочке parent->parent->...->parent можно добраться

Полиморфизм вынесен отдельно за пределы реализации класса.
А по отношению к экземплярам класса parent->parent->... превращается в доступ по указателю на указатель.
ЗЫ только что получил в рассылке виртуальные функции на Си
Еще не читал, но осуждаю
ЗЗЫ ремарка понравилась

C++ doesn't allow straightforward, dynamic changes to vtable entries (such changes inherently change the type of the object), but it does allow the implementation of a state machine just as you describe...

По первой части - таки да, на Си таблица виртуальных функций получается экономнее и интереснее... а стейт-машины и того проще

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