Hi,
While presenting the hot rod client java API in Brno, we agreed to use a
RemoteCacheManager that would implement CacheManager (similar to the way in which
DefaultCacheManager implements CacheManager; it is used for clients from the same
namespace).
Looking at the CacheManager interface[1], most of the methods that do not make sense on
the RemoteCacheManager: defineConfiguration, getClusterName, getAddress, isCoordinator,
getStatus, getGlobalConfiguration, getDefaultConfiguration and getCacheNames.
The only two methods that really make sense are: getCache() and
getCache(cacheName:String). So here are some thoughts I have about having
RemoteCacheManager implementing CacheManager.
1. Approach 1 - throw exceptions for the unsupported methods. Not a very nice approach
IMO, given the fact that most of the methods fall in this category, which would make the
API a bit unusable
2. Approach 2 - do not extend it. This would result in a clearer API
3. Approach 2 - Extract the two getCache methods in an super interface (CacheHolder,
CacheRepository, ??) and have both CacheManager and RemoteCacheManager implement it - this
one I like the most as it encourages reusability and keeps the API clean.
Thoughts?
Cheers,
Mircea
[1]
http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/in...