Storager! :D

Sokhranyalka

Может быть назвать Writer )

Storage обычно называю, никто не жаловался

В данном случае классы не нужен. Есть сущность «файл» и операции load*() и save*().

Klass

Аноним прав. Пусть данные сохраняют себя.

Глупое какое-то утверждение, откуда тебе знать, нужен мне там класс или нет. Может быть у меня класс Image, и мне нужно разные форматы уметь загружать и потом в другой формат сохранять, мне что, теперь под каждый формат заводить внутри Image метод save и load? как-то не очень удобно.

Глупое какое-то утверждение, откуда тебе знать, нужен мне там класс или нет.

Глупо натягивать сову на глобус, изобретая «сохранялку» :-)

Может быть у меня класс Image, и мне нужно разные форматы уметь загружать и потом в другой формат сохранять, мне что, теперь под каждый формат заводить внутри Image метод save и load?

Класс Image - это базовая абстракция :-) Если есть принципиальные отличия в алгоритмах load/save для jpeg или gif, то эти методы должны быть виртуальными, реализованными в JpegImage и GifImage :-)

Аноним прав. Пусть данные сохраняют себя.

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

handler

Не прав - данные одни, а способов сохранения может быть много.

Способов сохранения чего? :-) Сущность какая? :-) Файл :-) Вот и пусть сохраняет файл разными способами, реализованными в виртуальных методах, а не изобретает сохранялки :-)

И в общем случае коду, который работает только с данными, нафиг не нужны зависимости от сериализаторов.

А каким образом этот код получит зависимость?

Ну учитывая что обычно полагается использовать «парные» термины, типа reader - writer, то в твоем случае unloader 8), сам виноват.

<trollMode>
    Clamp/Fixer (фиксатор)
</trollMode>

P.S.: отличный вопрос для dev.

Класс Image - это базовая абстракция :-) Если есть принципиальные >отличия в алгоритмах load/save для jpeg или gif, то эти методы должны быть виртуальными, реализованными в JpegImage и GifImage :-)

Это тоже не всегда удобно, если я хочу пересохранить изображение из GIF в JPEG? Я согласен, что в большинстве случаев так и надо делать, когда у меня простая логика, но у меня в классе много других методов, мне бы не хотелось впихивать туда еще и сохранение и загрузку. По сути у меня одна и та же сущность, если у меня будет BinData и TextData это может создать путаницу, хотя у меня данные всегда представленны в одном и том же виде, они только могут по разному загружаться и сохраняться. Да и если я захочу TextData сохранить в BinData, мне придется создать новый экземляр BinData с данными, которые находятся в TextData, тоже не удобно.

Ну да, думаю reader - writer наилучший вариант ))

Это тоже не всегда удобно, если я хочу пересохранить изображение из GIF в JPEG?

Легко

void foo(Image* img1)
{
  auto* img = JpegImage::fromImage(img1);
}

Я согласен, что в большинстве случаев так и надо делать, когда у меня простая логика, но у меня в классе много других методов, мне бы не хотелось впихивать туда еще и сохранение и загрузку.

Тут простая иерархия вырисовывается: File <-- Image <-- JpegImage :-)

По сути у меня одна и та же сущность, если у меня будет BinData и TextData это может создать путаницу, хотя у меня данные всегда представленны в одном и том же виде, они только могут по разному загружаться и сохраняться.

Почему ты думаешь, что «сохранялка» внесёт ясность? :-)

Да и если я захочу TextData сохранить в BinData, мне придется создать новый экземляр BinData с данными, которые находятся в TextData, тоже не удобно.

Другого способа нет - всё равно придётся создавать экземпляр при перекодировке :-)

Способов сохранения чего? :-) Сущность какая? :-) Файл :-)

Совсем умстенно отсталый что столько лыбишься?

Класс Image - это базовая абстракция :-) Если есть принципиальные отличия в алгоритмах load/save для jpeg или gif, то эти методы должны быть виртуальными, реализованными в JpegImage и GifImage

Если данные загружены как Jpeg, а сохранить нужно как Gif ... то что дальше? В данном случае есть две разные сущности - данные и сераилизатор (кодек), файла тут вообще нет (загрузка и выгрузка идут в поток или буфер, а не в файл).

SomethingStorage

SomethingStorage

StupidStorage :-)

Storage

Лорчую, похоже это название - победитель конкурса :)

Writer/Reader победило )

Serializer ну и производные от этого названия ISerializer, TextDataSerializer, BinDataSerializer и т.д

Отличная идея, спасибо.

Сколько нужно программистов, чтобы назвать класс?

Ответ: «10 + 1: 10 троллят, автор в конце называет как попало».

Судью на мыло! )))))

Как назвать класс?

Гнвоерк!

Может быть у меня класс Image, и мне нужно разные форматы уметь загружать и потом в другой формат сохранять, мне что, теперь под каждый формат заводить внутри Image метод save и load?

Если именно так, как ты написал - сделать базовый класс ImageFile с pure virtual методами save и load, а под каждый формат сделать класс-наследника, и у него эти методы переопределить. Это, разумеется, в том случае, если потрохами форматов твой код занимается сам. Ну и отдельно собственно Image, с которым твоя программа оперирует в форматонезависимых вопросах.

Это лучше, чем делать класс для сохранения и класс для загрузки. Классом более естественно делать сущность, а не действие.

По сути у меня одна и та же сущность, если у меня будет BinData и TextData это может создать путаницу, хотя у меня данные всегда представленны в одном и том же виде, они только могут по разному загружаться и сохраняться. Да и если я захочу TextData сохранить в BinData, мне придется создать новый экземляр BinData с данными, которые находятся в TextData, тоже не удобно.

Опять же - для одной сущности, без привязки к форматам, сделай Data. А для записи-сохранения сделай BinDataStorage и TextDataStorage, которые будут наследоваться от какого-нибудь IDataStorage и перекрывать save() и load(). Указанным save() и load() передаётся ссылка на экземпляр Data - для сохранения и заполнения соответственно.

Если у тебя именя классов заканчиваются на «er», то это признак проблемы в дизайне.

Пысы use ptb

Если у тебя именя классов заканчиваются на «er», то это признак проблемы в дизайне.

Таких проблемных полный гитхаб :-) Лол :-)

Перегружай или делай виртуальным.

И что в этом хорошего?

Это лучше, чем делать класс для сохранения и класс для загрузки. Классом более естественно делать сущность, а не действие.

Смешиваешь две проблемы в одну.

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

Представление кодека в виде реализации интерфейа с парой ф-ий это средство разделения кода на модули. Оно нужно если в приложении имеется некоторая сущность которая может динамически выбирать кодек из заранее неизвестного списка (модули, например, могут подгружаться). При этом в реализациях интерфейса за ф-ми load(...) и save(...) могут скрываться отдельные классы сериализатора.

И что в этом хорошего?

Как есть :-)

Представление кодека в виде реализации интерфейа с парой ф-ий это средство разделения кода на модули.

Тогда назови эту сущность Codec, а не придумывай хренотень вроде «сохранялка» :-) А то потом приходится «терпимо относится к коду других участников», но терпение не безгранично :-) Лол :-)

Вопрос уровня лора

бывает так, что load для image есть, а load — нет, а exceptions мы не кидаем, ибо принятый стандарт кода такой

тогда — имеет смысл в отдельные классы вынести

тьфу: load есть, а save нет — хотел сказать

От вопроса выпал в осадок. Надеюсь, ТС шутит :-) Тоже пошучу.

LoaderText, LoaderBin

Ну, с таким знанием английского рекомендую ZagruzchikTeksta или LoadingIzFaelov, впишется идеально, гу-гу-гу.

именя классов

Пысы

Включи спеллчекер!

как правильно назвать подобный класс? Saver? звучит как-то странновато ))

Ну хоть не keeper. Вообще назови его LoadSave.

Но вообще ты не прав. Ты же скорее всего данные тоже хранишь в пределах класса отвечающего за их обработку. Поэтому сделай у класса функцию ClassSave и метод ClassLoad.

Функция

 ClassSave () As String[] 

А функция

 ClassLoad (ArrayStrings As String[], Optional StartString As Integer = -1, Optional StopString As Integer=-1) 

Сами массивы строк ты можешь объединять хоть в XML, а так же сохранять и передавать по сети как тебе вздумается.

Sokhranyalka

А мне нравится %)

Reader + Writer или IO