Правильно ли я понял принцип одной обязанности в классе?

Question

[Дмитрий]

Читая книгу Фриман и Фриман. Паттерны проектирования увидел прикольный принцип: «Класс должен иметь только одну причину для изменения» это стр. 361 в книге.

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

Возьмем к примеру простейший класс:

class CustomFormat
{
public:
  Header1 getHeader1();
  std::vector<Header2> getHeader2Array();
  void load();
  void save();  
};

Мне кажется что основной задачей класса является предоставление методов для работы со значениями заголовков. Но он также имеет и дополнительную задачу: класс имеет методы по чтению\записи.

Вопрос: Я правильно понимаю, что если следовать этому принципу, то мы должны методы load\save вынести в другой класс к примеру в какой-нить CustomFormatSerializer?

Меня не интересуют слова вида: «Вы знаете на практике… ». Меня очень волнует именно вопрос следования этому принципу, а не возможные компромиссы для достижения задач на практичеке.

Comments

[Дмитрий]

Спасибо @xSci. Уточню строение класса и с каким форматом он работает. Этот класс работает со интерфейсом стрима, к примеру std::iostream. Ссылка на интерфейс передается в конструкторе класса CustomFormat. Клиент открывает потомка std::iostream, любой из: файловый или память или сеть, не важно и передает этому классу CustomFormat. Строение хидеров простое, к примеру:

struct Header1
{
  uint32_t magic;
  uint8t  reseverd[10];
};

struct Header2
{
  uint64_t offset;
  uint32_t size;
};

[ixSci]

Клиент открывает потомка std::iostream, любой из: файловый или память или сеть, не важно и передает этому классу CustomFormat

Надо понимать, что это должно звучать как «Клиент создает объект класса-потомка std::iostream, любой из: файловый или память или сеть, не важно и передает этот объект, объекту класса CustomFormat при создании». Так?

Answer 1

[ixSci]

Мне кажется что основной задачей класса является предоставление методов для работы со значениями заголовков. Но он также имеет и дополнительную задачу: класс имеет методы по чтению\записи.

Если следовать этой логике дол конца, то методы load и save полностью отвечают данной семантике, т.к. load изменяет(загружает) заголовки, а save их сохраняет. Т.е. при данной постановке задачи load/save являются методами CustomFormat заслуженно.

Comments

[Дмитрий]

С Вами не соглассны в этом комментарии, слова:
Если по сути вопроса — то ответ «да», для следования указанному принципу нужно сериализацию выводить за пределы класса.

[ixSci]

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

[Дмитрий]

А суть этой темы не в том что лучше на практике, повторюсь уже в третий раз в этой теме, в том что «Следуя этому принципу, именно этому принципу одной обязанности на класс, нужно или нет выносить операции load\save за пределы этого класса?». Прошу почитать этот принцип и ответить не из практических соображений, а отталкиваясь исключительно от этого принципа.
Я отлично понимаю, что принципы иногда нужно нарушать, но в этой теме я задал вопрос сугубо теоретический, а не практический!

[ixSci]

Я еще раз повторяю, что данных не достаточно. Если, к примеру, load/save сериализуют в набор байт, тогда они должны быть членом класса. Если load/save пишут в БД\файл\etc., тогда это должна быть внешняя сущность. Так я ПОНИМАЮ этот принцип.
Суть не меняется, но меняется семантика операция load/save в первом случае она внутренняя и декомпозиция не нужна, во втором внешняя, и декомпозиция была бы кстати.

[ixSci]

Вообще плохой у Вас пример. Добавьте метод sendHeaderByHttp и всё сразу станет проще, это будет явный кандидат на выделение в отедльный метод(или класс). Т.к. передача по сети не является задачей класса по сути.

[Дмитрий]

Ну почему же плохой, примеров других классов приближенных к этому достаточно много. К примеру: PE lib она правда уже немного устарела, не тем не менее она очень похожа этот класс за исключением нескольких нюансов

[ixSci]

Плохой, потомучто из ваших данных нельзя дать однозначного ответа.

[Дмитрий]

По Вашей просьбе уточнил.

[ixSci]

load/save должны бить членами класса.

[Дмитрий]

Можете сформулировать и написать, хочу поставить ваш ответ решением?

[ixSci]

В силу того, что класс представляет собой работу с неким заранее известным форматом. Методы чтения и записи данных, в этом формате, во внешнюю среду, должны являться частью объекта CustomFormat в широком смысле ООП, т.е. должны быть методами класса CustomFormat или же свободными функциями ассоциированными с этим объектом.

[Дмитрий]

Спасибо! Вопрос исчерпан.

Answer 2

[kaladhara]

Мне кажется что основной задачей класса является предоставление методов для работы со значениями заголовков

Вам не должно казаться, класс создаётся для решения конкретной задачи, и разработчик должен понимать а не догадываться.

Меня очень волнует именно вопрос следования этому принципу

Прям-таки «очень»? Эта, извините за мой французский, херня Вас волнует?

Если по сути вопроса — то ответ «да», для следования указанному принципу нужно сериализацию выводить за пределы класса.
Если же следовать другому принципу , то сериализацию следует рассматривать как вспомогательную функцию для решения основной задачи, потому выносить не нужно.

Comments

[Дмитрий]

>>Эта, извините за мой французский, херня Вас волнует?
Если по сути вопроса — то ответ «да», для следования указанному принципу нужно сериализацию выводить за пределы класса.

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

[kaladhara]

Просто когда сталкиваешься с задачей то нужно иметь рабочий инструмент

Здесь есть нюанс: правильный выбор рабочего инструмента, в Вашей терминологии — принцип (он же «парадигма», он же «методология» и т.д.).

Выбор не того принципа для решения задачи может быть чреват последствиями, и зачастую негативными.

Самый лучший принцип — следовать совету К.Пруткова: «зри в корень», т.е. концентрироваться именно на решении задачи, подбирая соответствующий инструментарий, а не наоборот.

Answer 3

[ertaquo]

Насколько я понимаю, это зависит от глубины разбиения задач. Например, стоит задача — сделать простую рисовалку. Вы можете засунуть все в класс типа CPaintBox. Но можно разбить эту большую задачу на несколько более мелких — работу с кистью, загрузку, сохранение, наложение фильтров. Работу с кистью тоже можно разбить — на работу с формой кисти и на работу с ее цветом.

Answer 4

[Seter17]

Если несколько форматов — то да, стоит вынести в другой класс. И работать на абстрактном уровне через интерфейсы.
По идее класс должен работать только со совими полями(свойствами). Так что во многом зависит от цели методов save/load

Answer 5

[Анатолий]

ru.wikipedia.org/wiki/Принцип_единственной_обязанности

Comments

[Дмитрий]

Хотите сказать Фриман писать не умеет и надо читать в википедиа? Вопрос стоит не так «объясните мне принцип», а так «прошу проверить правильно ли я понял». Это означает что хоть минуту но уделил чтению и обдумыванию!

[Анатолий]

В википедии люди часто размусоливают то, что другие излагают кратко или двузначно. В этом плане это очень хороший рессурс.
У вас плохой пример, загрузка и сохранение, возможно, никак не мешают вашему классу. Что у вас за класс? Что он должен делать? Как работать? Пока нет ответа на все эти вопросы, нельзя сказать точно выполняет ли он что-то лишнее или нет.