[prog.c++] Обновление json_dto с очередным уроком на тему собственных просчетов

Есть у нас небольшой и пока еще не очень старый проект json_dto. Ему чуть больше пяти лет, но уже даже на таком небольшом временном интервале проявляется важный эффект: когда проект развивается, то ты неизбежно сталкиваешься с собственными просчетами, допущенными когда-то в прошлом.

Выпущенная давеча версия 0.3.0 как раз один такой просчет и устраняет.

Суть в том, что в json_dto есть функции mandatory, optional, optional_no_default, которые связывают подлежащее (де)сериализации поле объекта с информацией о том, как это поле должно выглядеть в JSON-е:

struct message_t {    std::string m_from;    std::int64_t m_when;    std::string m_text;    // Entry point for json_dto.    template<typename Json_Io>    void json_io(Json_Io & io)    {       io & json_dto::mandatory("from", m_from)          & json_dto::mandatory("when", m_when)          & json_dto::optional("text", m_text);    } };

Связывание происходит посредством создания объекта-binder-а в котором хранится имя поля в JSON, ссылка на само поле и, возможно, еще какая-то информация (вроде валидаторов десериализуемых значений).

А объект-binder -- это экземпляр шаблонного класса, одним из шаблонных параметров которого является т.н. manopt_policy (mandatory-optional policy). Свойство manopt_policy определяет то, является ли поле обязательным или опциональным, есть ли у него значение по умолчанию (которое можно и не сериализовать в JSON).

Соответственно, в json_dto есть несколько реализаций manopt_policy: одна реализация отвечает за поддержку обязательных полей, вторая -- за поддержку опциональных с наличием дефолтного значения, третья -- за поддержку опциональных без дефолтного значения.

Этого набора реализаций manopt_policy до сих пор хватало.

Но недавно мы наступили на грабли, которые сами же заложили в json_dto пять лет назад.

Грабли эти состояли в том, что manopt_policy обрабатывал только ситуации с отсутствием значения при десериализации. Но вот если поле присутствовало, но имело значение null, то тут manopt_policy игнорировался, а на помощь приходила свободная функция-шаблон set_attr_value_null. Т.е. при десериализации выполнялось что-то вроде:

const auto it = object.FindMember( binder_data.field_name() ); if( object.MemberEnd() != it ) // Значение в JSON присутствует. {    const auto & value = it->value;    if( !value.IsNull() ) // И это не null, поэтому можно читать значение.    {       binder_data.reader_writer().read(             binder_data.field_for_deserialization(), value );    }    else // А вот null обрабатывается особым образом.    {       set_attr_null_value(             binder_data.field_for_deserialization() );    } } else // Значения нет, тут в дело вступает manopt_policy. {    binder_data.manopt_policy().on_field_not_defined(          binder_data.field_for_deserialization() ); }

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

Исправление тривиальное и, на данный момент, выглядящее очевидным: обработка null-а теперь так же отдается на откуп manopt_policy:

const auto it = object.FindMember( binder_data.field_name() ); if( object.MemberEnd() != it ) // Значение в JSON присутствует. {    const auto & value = it->value;    if( !value.IsNull() ) // И это не null, поэтому можно читать значение.    {       binder_data.reader_writer().read(             binder_data.field_for_deserialization(), value );    }    else // Теперь null обрабатывается через manopt_policy.    {       binder_data.manopt_policy().on_null(             binder_data.field_for_deserialization() );    } } else // Значения нет, тут в дело вступает manopt_policy. {    binder_data.manopt_policy().on_field_not_defined(          binder_data.field_for_deserialization() ); }

И основной вопрос, который я задаю сейчас самому себе, выглядит так: "Если это настолько тривиально и очевидно, то почему мы не додумались до этого пять лет назад?"

PS. Если бы мне нужно было подвести какую-то мораль под этой историей, то она была бы какой-то такой: если вам повезет сделать собственный проект с нуля, а потом много лет работать над этим проектом, то вы неизбежно столкнетесь с собственными ошибками/просчетами, допущенными когда-то давным-давно. И, т.к. это будут именно что ваши собственные ошибки/просчеты, то винить в этом вы сможете только самого себя.

PPS. Мне повезло с проектами, которые были сделаны с нуля и развивались в течении многих лет, что это привело к следующему мнению: "классность" решения -- это функция, обратно пропорциональная времени. Принятое вами сегодня решение может казаться "классным", но спустя 2-3 года оно уже может быть "решение как решение", а лет через десять -- откровенно "дырявым".