Basic Design Problem: Using an interface as flag
My problem is pretty basic - i just want to know the best way to design that:
Imagine, you have an interfaceExample. There are two abstract classes implementing this -ExampleOneandExampleTwo.
Now there may be dozens of classes that subclass one of these two. They provide certain things that may be cacheable or not. By default it should be, but if the class implementsNonCacheableExampleits results must not be cached.
I tried it by adding an attribute "cacheable = true" to theExample interface and "cacheable = false" to theNonCacheableExample. This doesn't work of course - when i try to retrieve the attribute from whatever class it is always "true", no matter if it implements NonCacheableExample or not. I guess the attribute inherited from the abstract class is "stronger" than the one from the interface.
The only easy way I could imagine would be to add an interfaceCacheableExample, so that a class needs to implement eitherCacheable- orNonCacheableExample- however I'd like it to be cacheable by default.
Puh... I hope that was somehow understandable. Any ideas?
[1188 byte] By [
sensemanna] at [2007-10-2 9:23:13]
> My problem is pretty basic - i just want to know the
> best way to design that:
>
> Imagine, you have an interface Example. There
> are two abstract classes implementing this -
> ExampleOne and ExampleTwo.
>
> Now there may be dozens of classes that subclass one
> of these two. They provide certain things that may be
> cacheable or not. By default it should be, but if the
> class implements NonCacheableExample its
> results must not be cached.
>
> I tried it by adding an attribute "cacheable = true"
> to the Example interface and "cacheable =
> false" to the NonCacheableExample. This
> doesn't work of course - when i try to retrieve the
> attribute from whatever class it is always "true", no
> matter if it implements NonCacheableExample or not. I
> guess the attribute inherited from the abstract class
> is "stronger" than the one from the interface.
Let's get one thing straight - there ARE no attributes associated with an interface. They're pure signatures, nothing else. You can have static data members, but no attributes.
If the abstract class appears "stronger", that's because it's the only one with attributes.
>
> The only easy way I could imagine would be to add an
> interface CacheableExample, so that a class
> needs to implement either Cacheable- or
> NonCacheableExample - however I'd like it to
> be cacheable by default.
>
> Puh... I hope that was somehow understandable. Any
> ideas?
You have have a Cacheable interface that includes addToCache() and removeFromCache() methods. The AbstractCacheable implementations of these methods can default to meaningful behavior. The AbstractNonCacheable can implement these methods in such a way that they're no-ops or throw the runtime exception that indicates OperationNotSupported.
Personally, I think this is a bad design. You don't want to build in cacheable or not into an object. If you look at what people are doing with POJO persistence, they go to a great deal of trouble not to have to build persistence into the objects. No marker interfaces like Persistable. I think you should follow this course, too.
Why would something NOT be cacheable? If you have a cache and an object, under what circumstances would you want to absolutely prohibit caching?
Better to stop spending so much time thinking about this and more time thinking about getting a good cache, preferrably not one that you have to write. EHCache and OSCache come to mind. Go get those and get on with it. Neither of them require anything like a Cacheable interface.
%
