Добрый день,

Реализую некий сетевой протокол. Получаю я данные в некий буфер (std::vector<unsigned char>), далее их следует привести в божеский вид, т.е. предоставить удобный интерфейс для доступа к данным. Тоже самое с генерацией, предоставить удобный интерфейс для заполнение полей и как-то сконвертировать в буфер. Сейчас рассматриваю два варианта, выделить упаковку/распаковку в отдельный класс и запихнуть эти функции в класс пакета. Проблема в том, что некоторые поля в заголовке не должны меняться пользователем (например Length), а некоторые - должны. Я либо должен предоставить интерфейс для установки Length в классе Packet либо нет. В общем не буду долго писать, хотелось бы услышать свежие идеи, как и как предложить реализовать данную задачу? Запихнуть функции упаковки и распаковки в класс пакета?
Громоздко и нелогично
выделить упаковку и распаковку в отдельный класс?
 А что делать с интерфейсом пакета? Подружить эти классы? Тоже не нравится.

Заранее спасибо.

Это сообщение отредактировал(а) azesmcar - 9.10.2009, 12:30

сериализация

А причем тут серилизация?  о какой серилизации идет речь?

azesmcar, экземпляров класса вестимо... Делать это, конечно, удобнее отдельным классом (см. boost::serialization).
Начет "не давать юзеру менять" - можно например сделать декоратор над реально содержащим данные классом....

jonie

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

azesmcar, это когда в класс добавляется метод serialize() где перечисляются поля класса которые надо передать
(или не метод, а свободная функция)


а потом это запихивается в архив и отправляется по сети, или принимается и читается из архива

GoldFinch

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

Если поле Length (или любое другое служебное поле) зависит только от полезной нагрузки пакета (payload), то оно вообще не имеет права на существование как поле класса. Вовсе не обязательно делать отображение один к одному полей пакета и полей класса. Служебные поля должен вычислять код сериализации и ему для этого должно быть достаточно открытого интерфейса класса.

Но в таком случае весь парсинг полученного пакета возлагается на плечи класса Packet (не парсить же заголовок в одном классе а атрибуты в другом), тогда класс получается немного громоздким и выполняет слишком много функций (серилизация, десерилизация и предоставляет интерфейс для получения данных из пакета).