Я взаимодействую с 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, который можно использовать при написании модульных тестов для нового компонента, который его использует.
Это правильный способ сделать это? Можно ли это сделать по-другому?
Спасибо
