Рефакторинг IOManager с применением принципа единственной ответственности (SRP)

Условие

Необходимо переработать монолитный класс, отвечающий за ввод‑вывод, разбив его на несколько специализированных компонентов. Каждый из новых классов будет выполнять операции только с одним типом хранилища, тем самым соблюдая принцип единственной ответственности.

class UnifiedIOManager {
public:
    void SaveToFile(const std::string& path);
    void ReadFromFile(const std::string& path);

    void SaveToDB(const std::string& endpoint);
    void ReadFromDB(const std::string& endpoint);

    void SaveToServer(const std::string& endpoint);
    void ReadFromServer(const std::string& endpoint);
};

После разделения следует создать отдельные классы, например FileStorage, DatabaseStorage и ServerStorage, каждый из которых будет реализовывать только соответствующие методы сохранения и чтения.

Ответ

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

Например:

class FileStorage {
public:
    void Save(const std::string& path);
    void Read(const std::string& path);
};
class DatabaseStorage {
public:
    void Save(const std::string& endpoint);
    void Read(const std::string& endpoint);
};
class ServerStorage {
public:
    void Save(const std::string& endpoint);
    void Read(const std::string& endpoint);
};

Это схема интерфейсов, а не реализации доступа к данным. Общий интерфейс нужен только при действительно одинаковом контракте: формате результата, ошибках и гарантиях сохранения. Старый UnifiedIOManager можно временно оставить фасадом, делегирующим операции этим компонентам.