Является ли это нарушением концептуальной целостности?

Question

Я создаю приложение с несколькими классами Connector, которые взаимодействуют с различными хранилищами данных. Например, см. Предыдущий мой вопрос here. В любом случае, как и в моем примере, почти все эти источники данных имеют дорогостоящий временный доступ, поэтому каждый Connector поддерживает кеш, чтобы ограничить доступ. Для каждого силоса данных есть IDataSource, который извлекает данные, и Connector, который кэширует. Доступ к Connector осуществляется путем передачи в IDataSource заводского метода в моем классе AppFactory.

К сожалению, есть точно 1 Connector, который не подходит этой модели. Силос Active Directory достаточно быстр, чтобы не требоваться кеш, поэтому нет необходимости в ActiveDirectoryConnector, и не было бы фабричного метода в моем классе AppFactory. Как я уже говорил, в любом другом случае данные запрашиваются у объекта Connector, который может быть получен только от вызова метода до AppFactory с параметром IDataSource.

Насколько я могу сказать, мои варианты имеют неглубокую ActiveDirectoryConnector объект, который просто пересылает запросы прямо в его IActiveDirectoryDataSource или не иметь ActiveDirectoryConnector вообще. В первом случае я сохраняю концептуальную целостность с остальными моими Connector, но у меня есть бесполезный уровень косвенности. В последнем я жертвую концептуальной честностью для прямоты. Что представляет собой меньшее зло?

Answer 1

Я бы сказал, чтобы сохранить вашу модель на месте и не вводить сложность обработки специального корпуса. Совершенно разумно иметь Connector, который просто направляет запрос на конечный источник данных. Вы не наклоняетесь назад назад, нет ничего фундаментального для метафоры Connector, которая требует, чтобы у нее был кеш. Кэш - это просто оптимизация производительности, и концепция Connector представляется полезным слоем абстракции, который позволяет вам при необходимости вводить кеш (или другую обработку).

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