Is this a violation of Conceptual Integrity?

Question

I'm building an application with several Connector classes that interface with varied data silos. For an example, see an earlier question of mine here. Anyways, as is the case in my example, almost all of these data sources are expensive time-wise on access, so each Connector maintains a cache to limit accesses. For every data silo, there is an IDataSource that fetches data, and a Connector that caches. The Connector is accessed by passing in an IDataSource to a factory method on my AppFactory class.

Unfortunately, there is exactly 1 Connector that does not fit this model. The Active Directory silo is fast enough to not need a cache, so there is no need for an ActiveDirectoryConnector, nor would there be a factory method on my AppFactory class. As I said before, in EVERY other case, data is requested from a Connector object, which can only be gotten from a method call to the AppFactory with an IDataSource parameter.

As far as I can tell, my options are to have a shallow ActiveDirectoryConnector object that just forwards requests straight to its IActiveDirectoryDataSource, or to not have an ActiveDirectoryConnector at all. In the former case, I maintain conceptual integrity with the rest of my Connectors, but I have a useless level of indirection. In the latter, I sacrifice conceptual integrity for directness. Which is the lesser evil?

Answer 1

I would say to keep your model in place and don't introduce the complexity of the special case handling. It's perfectly reasonable to have a Connector that just forwards on the request to the eventual data source. You're not bending over backwards here, there's nothing fundamental to the Connector metaphor that requires it to have a cache. The cache is just a performance optimization and the Connector concept seems to be a useful abstraction layer that allows you to introduce a cache (or other processing) when needed.

Conceptually this is somewhat similar to the practice of accessing member data for an object through accessor methods instead of directly using the member variable, which is considered a best practice by many. The reason for that is similar: if you add a level of indirection in between the client and the data, it allows you to introduce additional processing or optimization in the future when that data needs to be accessed.