Как-то не вяжется) С одной стороны надо упрощать (я читаю как "реализовывать без всяких классов, в Си-стиле"), с другой стороны - прятать в классы и использовать ООП-модель построения программы.
Я поясню на примере. Постараюсь совсем простой.
Есть плата с микроконтроллером, есть компьютер. Я пишу код для МК, попутно разрабатывая протокол. Чел, который пишет приложение на ПК говорит - "ну ты это, протокол состряпай, а я его поддержу у себя". Окей.
Допустим, все мои параметры, которые я отправляю на комп, умещаются в одно u32 слово. Ну не все сразу, а раздельно - как будто union-ом закодированы. Это слово поделено на битовые поля. Одно из полей - обязательное, и находится в одном месте для разных по смыслу объектов u32.
Я сразу заготовлю шаблоны всех видов этого самого u32 (что в нем и где хранится). Разумеется, это будут классы. Я прячу u32 внутрь базового класса и конечно же определяю метод извлечения (чтения) типа сообщения MessageID, чтобы как и мне, так и программисту ПК-шной части не делать одинаковую работу по написанию портянки извлечения битовых полей из rawDataFrame
enum MessageID {
TEMPERATURE,
VOLTAGE,
CURRENT
};
class MessageRaw {
public:
MessageRaw(MessageID id) : rawDataFrame(/* тут выражение упаковки id в нужное поле по маске ID_MASK*/) {}
MessageID getMessageID() {
return ... ; // тут каким-то образом извлекаю битовое поле, где хранится MessageID в rawDataFrame
}
protected:
u32 rawDataFrame;
enum {
ID_MASK = 0xFu
};
};
Как видно, базовый класс уже "оброс" вспомогательным методом.
Вот "конкретные" классы (на примере одного, который заполняет температуру)
template<MessageID>
class Message;
// фрейм, который кодирует данные о температуре
template<>
class Message<TEMPERATURE> : public MessageRaw {
public:
Message(u32 temp) : MessageRaw(TEMPERATURE) {
// тут заполняем соответствующее битовое поле TEMPERATURE_MASK значением temp
}
u32 getTemperature() {
return ...; // извлекаем из rawData базового класса битовое поле TEMPERATURE_MASK
}
private:
enum {
TEMPERATURE_MASK = 0x00FFFFF0u // младшие 4 бита всегда отведены под MessageID
};
};
У классов с MessageID == VOLTAGE или CURRENT битовые поля могут находиться в других местах и, разумеется, пересекаться. Этакий union.
Видно, что конкретный Message<TEMPERATURE> уже оброс, как минимум, методом извлечения кодированной температуры (скорее, полезно для программиста ПК-шной части, кому я это хозяйство отправлять буду). Для своей же части (микроконтроллерной) для удобства я еще определяю конструктор, чтобы можно было написать
u32 temp = getTemperature();
Message<TEMPERATURE> msg(temp); // прикинь удобно как, в msg уже автоматически (ОДНОЙ СТРОЧКОЙ) записалась температура куда надо
Ага. Круто. Еще круто, что при создании msg сначала вызовется конструктор базового класса, который сразу заполнит MessageID!
И теперь этим готовым классом могу пользоваться и я, и другой разраб. Но есть одно западло. Как только я во всю эту красосту привнес конструкторы, я потерял POD-овость объектов. А значит реализовать функции приема/передачи в программные очереди (и оттуда в интерфейс) надежно я не могу. Потому что слетает гарантия одинакового представления layout-ов классов у меня и у другого разраба (у меня микроконтроллер и компилятор Clang, у разраба - хрен пойми что, мне возможно даже не очень известное). Вот и приехали.
