Отображение данных: от "любого" класса до универсальной карты значения ключа (C++)

Для регистрации целей я хотел бы приспособить различные классы (поэтому, я хотел бы универсальный подход) к словарю значения ключа: это могло быть рассмотрено как "преобразование в последовательную форму значения ключа".

Давайте предположим, что ключи предопределены и что, в зависимости от входного класса мы действительно хотим приспособиться, каждая стоимость может соответствовать определенному признаку. Ценности могут всегда заключаться в капсулу в станд.:: последовательность.

Это было бы моим подходом:

Создайте класс адаптера, который может быть свален в базу данных

#include //enum with possible keys, defining type Key_t

namespace generic
{
    class Adapter
    {
        public:
            Adapter();
            virtual ~Adapter();
            virtual void init() = 0;

        private:
            std::map _data;
    }
}

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

например.

#include 

#include 
#include 
...
#include 

namespace client1
{
    class Adapter : public generic::Adapter
    {
        public:
            Adapter(const Bom1& bom1,
                    const Bom2& bom2,
                    const BomN& bomN)
            : _bom1(bom1), _bom2(bom2), _bomN(bomN)
            {}

            void init()
            {
               //Explicit data mapping in here
                 _map[NAME] = _bom1._name;
                 _map[TITLE] = _bom2._title;
                 ....
                 ....
            }

        private:
            Bom1 _bom1;
            Bom2 _bom2;
            BomN _bomN;
      }
}

Что вы думаете об этом подходе? Есть ли более универсальный способ достигнуть этого в C++? Каков был бы ваш дизайн?

Спасибо!

Обновление

Когда новый клиент осуществляется, регистрирующийся двигатель не должен изменяться: именно поэтому приспосабливающаяся логика должна быть распределена на клиентской стороне вместо того, чтобы быть осуществленной в ядре регистрирующегося двигателя. Регистрирующийся двигатель был бы обновлен, только если новые ключи требуются (это, вероятно, подразумевало бы структурное изменение базы данных).

1
nl ja de
Я думал об этом подходе также, но у меня есть много клиентов, и для каждого клиента много данных, чтобы нанести на карту: I' d нравится стараться не централизовать все отображение данных в единственную большую функцию templated, которая должна была бы быть специализирована для каждого клиента (у каждого есть ее собственные различные BOM); I' d предпочитают распределять отображение на клиентской стороне.
добавлено автор codeJack, источник
можно просто использовать функцию templated регистрации...
добавлено автор user1849534, источник
можно просто использовать функцию templated регистрации...
добавлено автор user1849534, источник

2 ответы

Я сохранил бы преобразованные в последовательную форму последовательности и для ключей и для ценностей.
Здесь Я использую ldbSerialize метод, который использует преобразование в последовательную форму повышения по умолчанию и может быть легко специализирован, не создавая новый класс. Поскольку каждый новый тип ключевого просто добавил бы новую специализацию:

template <> inline void ldbSerialize (string& bytes, const Key32& key) {
  bytes += key.whatever();
}
0
добавлено
Wouldn' t это быть простым преобразованием в последовательную форму в этом случае? Я мог бы пропускать что-то, но, пункт, я должен преобразовать в последовательную форму различные структуры во что-то, что является так или иначе статической и предопределенной картой данных. Этот подход сделал бы для части преобразования в последовательную форму, но что относительно адаптации?
добавлено автор codeJack, источник
Каково было бы преимущество этого против простой "logMe" перегрузки функции?
добавлено автор codeJack, источник
Хорошо, скроенный к вашему варианту использования это могло бы быть похожим на шаблон <> действующий недействительный logMe (станд.:: карта & данные, константа ключ Key32&) {данные [ИМЯ] = ключ. _ имя;} ; пункт должен иметь метод преобразования в последовательную форму по умолчанию и специализировать его для новых клиентов.
добавлено автор ArtemGr, источник
Преимущество (IMO) состоит в том, что у вас может быть дефолт logMe, не получая ваших клиентов из некоторого базового класса. Это менее навязчиво и легче осуществить для автора клиента. (И в моем случае функция по умолчанию использует преобразование в последовательную форму Повышения). Но так как вы написали выше этого you' d "любят стараться не централизовать все отображение данных в единственную большую функцию templated", возможно, ваш начальный подход является лучшим, хотя я don' t видят от вашего примера, как большой "init" метод отличался бы от большой специализированной функции "logMe".
добавлено автор ArtemGr, источник
И у вас могут быть templated функции помощника, например, logUsualFields, который можно назвать от logMe специализаций. Тем путем можно децентрализовать преобразование в последовательную форму. IMO это более чисто, чем питание с наследованием.
добавлено автор ArtemGr, источник

Я сохранил бы преобразованные в последовательную форму последовательности и для ключей и для ценностей.
Здесь Я использую ldbSerialize метод, который использует преобразование в последовательную форму повышения по умолчанию и может быть легко специализирован, не создавая новый класс. Поскольку каждый новый тип ключевого просто добавил бы новую специализацию:

template <> inline void ldbSerialize (string& bytes, const Key32& key) {
  bytes += key.whatever();
}
0
добавлено
Wouldn' t это быть простым преобразованием в последовательную форму в этом случае? Я мог бы пропускать что-то, но, пункт, я должен преобразовать в последовательную форму различные структуры во что-то, что является так или иначе статической и предопределенной картой данных. Этот подход сделал бы для части преобразования в последовательную форму, но что относительно адаптации?
добавлено автор codeJack, источник
Каково было бы преимущество этого против простой "logMe" перегрузки функции?
добавлено автор codeJack, источник
Хорошо, скроенный к вашему варианту использования это могло бы быть похожим на шаблон <> действующий недействительный logMe (станд.:: карта & данные, константа ключ Key32&) {данные [ИМЯ] = ключ. _ имя;} ; пункт должен иметь метод преобразования в последовательную форму по умолчанию и специализировать его для новых клиентов.
добавлено автор ArtemGr, источник
Преимущество (IMO) состоит в том, что у вас может быть дефолт logMe, не получая ваших клиентов из некоторого базового класса. Это менее навязчиво и легче осуществить для автора клиента. (И в моем случае функция по умолчанию использует преобразование в последовательную форму Повышения). Но так как вы написали выше этого you' d "любят стараться не централизовать все отображение данных в единственную большую функцию templated", возможно, ваш начальный подход является лучшим, хотя я don' t видят от вашего примера, как большой "init" метод отличался бы от большой специализированной функции "logMe".
добавлено автор ArtemGr, источник
И у вас могут быть templated функции помощника, например, logUsualFields, который можно назвать от logMe специализаций. Тем путем можно децентрализовать преобразование в последовательную форму. IMO это более чисто, чем питание с наследованием.
добавлено автор ArtemGr, источник
pro.cxx
pro.cxx
3 049 участник(ов)

C/C++ chat 0. Простые вопросы, лабы и о IDE — в чат новичков @supapro 1. Не хамим, не переходим на личности, не вбрасываем утверждения без доказательств 2. No Ads, offtop, flood Объявления о вакансиях и евенты - в лс @AlexFails https://t.me/ProCxx/259155

supapro.cxx
supapro.cxx
1 925 участник(ов)

Чат для тех, кто немного знает C++, простые вопросы по реализации, синтаксису и ide – сюда, а для другого есть: /Главный чат по серьезным вопросам — @ProCxx /Чат по обсуждению всего — @fludpac

C++ Russia
C++ Russia
384 участник(ов)

Сообщество разработчиков C++ в Telegram.

cxx.Дискуссионная
cxx.Дискуссионная
298 участник(ов)

это не двач, общайтесь вежливо; разговор на почти любые темы; Не согласны с баном? В лс @AlexFails, @ivario

C++ для маленьких и тупых
C++ для маленьких и тупых
105 участник(ов)

Лоу левел (по среднему IQ участников) чатик ExtremeCode @extremecode Флудилка @extremecode_rest