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

Question

Я взаимодействую с API, который имеет статические функции и не может быть открыт и изменен.

    public class WindowsNativeGraphAPI
    {
        public static IEnumerable<IGraphData> GetGraphData();
        public static bool DeleteGraphData(IGraphData data);
    }

Я хотел бы иметь возможность передать API в функцию или конструктор и соблюдатьвнедрение зависимостей (на всякий случай мы должны поменять API позже).

public void GatherGraphData(IGraphAPI api)
{...}

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

    public interface IGraphAPI
    {
        IEnumerable<IGraphData> GetGraphData();
        bool DeleteGraphData(IGraphData data);
    }

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

    public class WindowsGraphAPI : IGraphAPI
    {
        public IEnumerable<IGraphData> GetGraphData()
        {
            return WindowsNativeGraphAPI.GetGraphData();
        }

        public bool DeleteGraphData(IGraphData data)
        {
            return WindowsNativeGraphAPI.DeleteGraphData(data)
        }
    }

Мне не нравится идея создания другого класса для переноса API.Я понимаю, что эта обертка будет очень легкой и будет просто возвращать результаты API, но как мне проверить обертку?Оболочка, вероятно, также должна содержать некоторую обработку исключений, чтобы справляться с ошибками в API.Если бы нам пришлось перейти на другой API, который столкнулся с той же проблемой, нам пришлось бы снова создавать эти дополнительные классы и интерфейсы.

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

Это правильный способ сделать это?Можно ли это сделать по-другому?

Спасибо

Answer 1

Да, это правильный путь. Новый интерфейс API и прокси-класс инкапсулируют решение о том, какую базовую библиотеку использовать - единственная ответственность.

Answer 2

Да, это правильный путь.Я бы не стал обрабатывать исключения в вашей оболочке, все, что вы делаете, - это создаете класс, который вызывает статические методы, чтобы вы могли использовать DI.Вы хотите, чтобы оболочка вызывала те же исключения при тех же обстоятельствах, что и класс API со статическими методами.Таким образом, вы можете использовать ту же обработку исключений в вашем методе, что и при вызове класса со статическими методами.Затем вы можете выдать те же исключения при тех же обстоятельствах в своем классе mock api и протестировать обработку исключений.