Reputation: 6546
public interface MemcachedAccessor {
void set(String key, Object value, int cacheTime, long timeout,
TimeUnit timeUnit);
Object get(String key);
}
I have one interface: MemcachedAccessor
and an implementation: MemcachedAccessorImpl
.
Which name style is better?
MemcachedAccessor
and MemcachedAccessorImpl
or
MemcachedAccess
and MemcachedAccessImpl
?
any rules?
Upvotes: 0
Views: 217
Reputation: 48045
The interface could be even more general:
public interface CacheAccessor {
}
While the implementation shows the intent (to access a Memcached distributed cache):
public class MemcachedAccessor implements CacheAccessor {
...
}
Upvotes: 7
Reputation: 1327
I'd only use names like accessor when issueing a command pattern or so. In this it's
class MemCache implements Cache {
}
Upvotes: 2
Reputation: 3207
If it is an interface, you'll most certainly avoid *Impl, because it indicates Implementation of the interface.
EDIT
This answer was posted before the question was edited by another user, but ok, keep down-voting :)
In addition, my personal preference is to use .Net style for instantly visible clarity: interface would be ICachedAccessor
, and the class implementing it would be CachedAccessor
.
Upvotes: 1
Reputation: 160170
Just to be contrarian, I'll say neither, and instead vote for:
Memcacheable
and DefaultMemcacheable
or:
Memcached
and DefaultMemcached
There are no "rules" per se, but "-able"/"-ible" interface names are pretty common. The only real rule is to name things in a way that clearly and concisely indicates their intent. I extend that a bit to try and make sure that names (hence code) sound good when read out loud, like the code is telling a story.
Upvotes: 2