Расширение архитектуры: поддержка источников помимо файлов

Условие

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

Определите, какие дополнительные источники данных (например, базы данных, сетевые потоки, облачные хранилища) логично будет подключать, реализуя те же интерфейсы IConnection и IFile. Такое решение покажет, насколько гибко построена архитектура и как легко её можно адаптировать к новым требованиям.

class IConnection {
public:
    virtual void connect(std::string) = 0;
    virtual void disconnect() = 0;
    virtual ~IConnection() {}
};

class IFile {
public:
    virtual std::vector<std::string> Read() = 0;
    virtual void Write(std::vector<std::string>) = 0;
    virtual ~IFile() {}
};

class OurFile : public IConnection, public IFile {
    void connect(std::string);
    void disconnect();
    std::vector<std::string> Read();
    void Write(std::vector<std::string>);
};

Ответ

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

Например, RemoteFile может устанавливать соединение с файловым API и переводить Read/Write в его запросы. Существующий потребитель должен принимать интерфейс, а выбор реализации — происходить в фабрике или точке сборки зависимостей.

База данных не обязана естественно соответствовать «вектору строк файла». Нужно явно определить формат, ошибки и транзакционность. Для бесконечного сетевого потока Read, возвращающий весь результат разом, может быть неподходящим контрактом.