Basic Design Problem: Using an interface as flag

Question

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.
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?

Answer 1

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.
%