Форум программистов, компьютерный форум, киберфорум
Наши страницы

C++

Войти
Регистрация
Восстановить пароль
 
 
Kastaneda
Jesus loves me
Эксперт С++
4689 / 2893 / 236
Регистрация: 12.12.2009
Сообщений: 7,357
Записей в блоге: 2
Завершенные тесты: 1
#1

Немного философии ООП - C++

17.09.2016, 07:15. Просмотров 1038. Ответов 24
Метки нет (Все метки)

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

Итак - есть проект, в проекте используется ООП, скатываться до С считается мовитоном и не приветствуется.
Есть структура сеттингов
C++
1
2
3
4
5
6
struct Settings
{
    std::string param1;
    int param2;
    // etc
};
понадобилось сделать сериализацию/десериализацию этой структуры. По сути нужны 2 функции serialize(Settings)/deserialize(Settings). Но 2 функции - это С, обернуть их в класс и сделать статичными - это вроде как ООП, но с запашком.
C++
1
2
3
4
5
6
7
class Foo
{
public:
    static PackedObject serialize(Settings);
    
    static Settings deserialize(PackedObject);
};
По сути этот класс является неймспейсом и если из него реально сделать неймспейс (и это правильно), то даже остальной код трогать не придется. т.к. синтаксис использования не изменится. Но это сведет нас к тем же 2м сишным функциям, которых мы хотели избежать.

Вопрос - как сделать правильно, чтоб было хорошее ООП?

Не по теме:

rikimaru2013, хотел интересных вопросов?

2
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
17.09.2016, 07:15
Здравствуйте! Я подобрал для вас темы с ответами на вопрос Немного философии ООП (C++):

Немного про std::string - C++
Привет, читал про std::string на разных сайтах. 1. Там говорят, С++ 11 гарантирует, что std::string будет stored contiguously in...

Обработка всех исключений TIdHTTP + немного ООП - C++ Builder
Приветствую. У меня возникла потребность в обработке всех исключений компонента TIdHTTP для более детального отчёта работы программы. А...

Немного бесплатного от Embarcadero - C++ Builder
Хочу напомнить, может кто не знает, но сегодня последний день, когда можно получить C++ Builder 10.1 Berlin Starter бесплатно. Сам...

Немного глупый вопрос - C++ Builder
Добрый день! У меня есть на форме компоненты Memo1 и Memo2 типа TMemo. Так вот в Memo1 есть большой текст. Короче как мне взять этот весь...

немного теории UPD - C++ Builder
Добрый день! Не мог бы ни кто объяснить про UPD. Почему у клиентов TIdUDPClient, нет как токовых событий Read как от сервера передавать...

Дать немного коментария по коду - C++ Builder
Здравсвуйте программисты! Дайте пожалуйста коментарий, желательно подробнее,что делается в этом коде, и правильно ли он написан, согласно...

24
Kastaneda
Jesus loves me
Эксперт С++
4689 / 2893 / 236
Регистрация: 12.12.2009
Сообщений: 7,357
Записей в блоге: 2
Завершенные тесты: 1
18.09.2016, 19:09  [ТС] #16
castaway, мне на чисто интуитивном уровне кажется, что структура (любая) не должна уметь менять свое представление (упаковываться), этим должен заматься кто-то со стороны, кто знает о наличии этой структуры и формата представления (то, во что сериализуется структура). Сама же структура не должна ничего знать о, скажем, классе DataTransferObject, ей эти знания ни к чему, а без этих знаний она не может упаковывать сама себя в DataTransferObject.
0
castaway
Эксперт С++
4915 / 3023 / 370
Регистрация: 10.11.2010
Сообщений: 11,081
Записей в блоге: 10
Завершенные тесты: 1
18.09.2016, 19:17 #17
Kastaneda, так какой же вариант лучший?
0
IGPIGP
Комп_Оратор)
Эксперт по математике/физике
6503 / 3142 / 307
Регистрация: 04.12.2011
Сообщений: 8,673
Записей в блоге: 5
18.09.2016, 19:21 #18
Цитата Сообщение от Kastaneda Посмотреть сообщение
мне на чисто интуитивном уровне кажется, что структура (любая) не должна уметь менять свое представление (упаковываться), этим должен заматься кто-то со стороны,
Это значит, что кто-то со стороны должен знать о данной структуре. Я не помню точно, но кажется создатель работая в Центре компьютерных исследований фирмы Bell Labs решал задачи распределения вычислений между различными машинами и различными OS на них. Так как легче, научить внешние ресурсы работе со структурой или попросить разрабов поддержать структуру в разных средах? Конечно, это не о данной структуре, хотя из вопроса не видно, что она примитивна. Иначе вопрос о чём?
0
Kastaneda
Jesus loves me
Эксперт С++
4689 / 2893 / 236
Регистрация: 12.12.2009
Сообщений: 7,357
Записей в блоге: 2
Завершенные тесты: 1
18.09.2016, 19:23  [ТС] #19
Цитата Сообщение от castaway Посмотреть сообщение
Kastaneda, так какой же вариант лучший?
Слово "лучший" тут наверное тоже не совсем уместно. Можно рассуждать так (поэтапно):
1. Мы решили, что Settings не должен уметь сам себя сериализовывать/десериализовывать
2. Значит выносим эти функции в отдельный класс
3. Эти функции не меняют состояние объекта класса, значит должны быть статичными
4. Класс, кроме этих двух статичных функций, больше ничего не содержит, а значит семантически это получается неймспейс
5. Делаем из класса неймспейс, получаем 2 сишные функции

Получаем 2 функции, которые являются интерфейсными (как пишут умные люди) для структуры Settings, при этом семантика Settings не нарушена.

Добавлено через 56 секунд
Цитата Сообщение от IGPIGP Посмотреть сообщение
Это значит, что кто-то со стороны должен знать о данной структуре.
да, и о выходном формате. Этого "кого-то" можно считать "специально обученным для этого дела" )
0
castaway
Эксперт С++
4915 / 3023 / 370
Регистрация: 10.11.2010
Сообщений: 11,081
Записей в блоге: 10
Завершенные тесты: 1
18.09.2016, 19:35 #20
Цитата Сообщение от Kastaneda Посмотреть сообщение
Получаем 2 функции, которые являются интерфейсными (как пишут умные люди) для структуры Settings, при этом семантика Settings не нарушена.
но ведь:
Цитата Сообщение от Kastaneda Посмотреть сообщение
скатываться до С считается мовитоном и не приветствуется.
0
Kastaneda
Jesus loves me
Эксперт С++
4689 / 2893 / 236
Регистрация: 12.12.2009
Сообщений: 7,357
Записей в блоге: 2
Завершенные тесты: 1
18.09.2016, 19:42  [ТС] #21
Цитата Сообщение от castaway Посмотреть сообщение
но ведь:
это были изначальные условия, от которых мы отталкивались. Потом (прочитав Мейерса), пришли к тому, что я написал в предыдущем посте. Собственно это решение сразу было на виду, но не хотели его принимать, т.к. "не ООП же")
0
hoggy
6703 / 2885 / 494
Регистрация: 15.11.2014
Сообщений: 6,485
Завершенные тесты: 1
20.09.2016, 00:08 #22
boost.serialization/cereal
1
pav1uxa
1846 / 1698 / 644
Регистрация: 23.01.2014
Сообщений: 6,078
Завершенные тесты: 1
21.09.2016, 22:28 #23
Отклонюсь в сторону.

Почему 2 функции в неймспейсе это "сишный подход" и моветон? STL переполнена такими функциями. Или я чего-то не так понимаю?

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

Все к тому и сводится: нужен доступ к приватным членам - статик, не нужен - отдельные функции.

ООП ради ООП, как уже сказали, это ведь в разы хуже чем "сишный подход"
0
rikimaru2013
C++ Game Dev
2439 / 1133 / 240
Регистрация: 30.11.2013
Сообщений: 3,690
22.09.2016, 18:14 #24
Я согласен с castaway - Settings хоть и структура, должна в первую очередь знать, что ей нужно сериализовать. Пусть она не имеет алгоритмы, но должна предоставить метод для тех кто умеет. И посему 22 пост, как по мне, лучше всего это делает. Ведь в идеале структура в одном файле, и добавив поле не хотелось бы искать, где её сериализатор. В СИ такого вопроса не возникало, потому что структура писалась как sizeof(), а тут нужен ООП подход: объект знает всю private кухню и подскажет алгоритму сохранению, что ему делать
0
AlexVRud
459 / 170 / 44
Регистрация: 04.07.2014
Сообщений: 475
26.09.2016, 12:22 #25
1. Settings - стоит определить как class, т.к. он содержит не Pod-тип внутри себя, и для него будут сгенерированы конструкторы/деструкторы для управления памятью

2. Результат сериализации - нечто иное как представление класса, следовательно, она не должен фигурировать в нём.

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
#include <iostream>
#include <sstream>
#include <string>
#include <utility>
 
class Settings {
  std::string param1_;
  int param2_;
 
public:
  Settings()
      : param1_("default")
      , param2_(0) {};
 
  template <class T>
  Settings(T &&param1, int param2)
      : param1_(std::forward<std::string>(param1))
      , param2_(param2)
  {
  }
 
  std::string getParam1() const
  {
    return param1_;
  };
  int getParam2() const
  {
    return param2_;
  };
};
 
class JsonStringPacker {
  bool need_new_line_;
  bool need_tab_to_spaces_;
  uint8_t tab_width_;
 
public:
  JsonStringPacker(bool need_new_line = true, bool need_tab_to_spaces = true, uint8_t tab_width = 4)
      : need_new_line_(need_new_line)
      , need_tab_to_spaces_(need_tab_to_spaces)
      , tab_width_(tab_width) {};
 
  std::string pack(const Settings &settings)
  {
    std::stringstream ss;
    ss << "{";
    if (need_new_line_) {
      ss << "\n" << (need_tab_to_spaces_ ? std::string(tab_width_, ' ') : std::string("\t"));
    }
    ss << "'param1': '" << settings.getParam1() << "',";
    if (need_new_line_) {
      ss << "\n" << (need_tab_to_spaces_ ? std::string(tab_width_, ' ') : std::string("\t"));
    } else {
      ss << " ";
    }
    ss << "'param2': " << settings.getParam2();
    if (need_new_line_) {
      ss << "\n}\n";
    } else {
      ss << "}";
    }
    return ss.str();
  };
};
 
int main()
{
  Settings settings = Settings("Hello world", 13);
  JsonStringPacker packer1;
  JsonStringPacker packer2 = JsonStringPacker(false);
  std::cout << packer1.pack(settings);
  std::cout << packer2.pack(settings) << std::endl;
  std::cout << JsonStringPacker(true, false).pack(settings);
  std::cout << JsonStringPacker(true, true, 2).pack(settings);
  return 0;
}
Результат:

JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
{
    'param1': 'Hello world',
    'param2': 13
}
{'param1': 'Hello world', 'param2': 13}
{
        'param1': 'Hello world',
        'param2': 13
}
{
  'param1': 'Hello world',
  'param2': 13
}
Добавлено через 6 минут
Цитата Сообщение от rikimaru2013 Посмотреть сообщение
Settings хоть и структура, должна в первую очередь знать, что ей нужно сериализовать
Если исходить из этого, то должно знать "представление данных" и не сами "данные", что и как надо сериализовать, т.е. PacketObject (которые тогда правильнее назвать PacketSettings )
1
26.09.2016, 12:22
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
26.09.2016, 12:22
Привет! Вот еще темы с ответами:

Помогите немного переделать программу - C++ Builder
Вот код поисковой программы void Scan(AnsiString Path) { TSearchRec sr; if(FindFirst(Path + &quot;*.*&quot;, faAnyFile, sr) == 0) ...

Полезные Хедеры и немного инфы о них - C++ Builder
Сразу к делу... Я сегодня в одном исходнике обнаружил в куче файлов обычно присущих проэкту, хедер файл который я скопировал в другой...

Загрузка изображений через Indy + немного оптимизации - C++ Builder
Я разобрался как используя Indy авторизовываться на файлообменниках :) Теперь мне интересно как можно используя инди залить изображение на...

Немного теории ООП - ООП и паттерны
Добрый день! ООП отражает поведение объектов реального мира. Объект - набор данных, и методов для работы с ними. Например,...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
25
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru