Why is a Collection an Interface?
Hi,
I am just curious about why there are interfaces for Collection, List, Set etc,. and abstract classes each implementing the interface .. Why couldn't they have just started with
AbstractCollection , AbstractSet etc.,
And am I right about a convention not being followed about naming interfaces as 'verb' (I don't know english grammar well ) instead of Noun for Collection, List , Set etc. ...... ?
thanks & regards,
Bhargava Ram
[480 byte] By [
BHARGAVAa] at [2007-11-27 11:01:05]
# 1
So that you can have alternate implementations ...
ejpa at 2007-7-29 12:34:17 >
# 2
ejp,
you mean even the methods defined in abstract classes (Collection, List etc.,) can be different and so they have created interface one level above these abstract classes?
what about the naming convention ? ;)
# 3
I mean that the abstract classes are there to support specific styles of implementation. In e.g. an implementation of persistence collections from a database you probably wouldn't want anything that those abstract classes presently do, you would just want to implement to the interface. In general specifying an API via an interface is always preferable.
Re the naming convention, it used to be adverbial, e.g. Cloneable, Serializable, Externalizable, Remote, etc. This was nice but it was probably impossible to continue with. Would you really want Collectible?
ejpa at 2007-7-29 12:34:17 >
# 4
This naming convention whereby interfaces are adverbs, I'm not so keen on. Sometimes it's appropriate - as well as those Esmond named, Runnable leaps to mind - but interfaces are also used to define types within a domain model. In that instance, adverbs aren't at all appropriate, nouns are. We wouldn't conceive of modelling employees as Employable, or Payable would we? (Although I could see a use for a Payable supertype which Employee, Supplier etc inherited)
# 5
I've had a few employees who were neither Employable nor Payable ;-)
ejpa at 2007-7-29 12:34:17 >
# 6
Thanks for the replies guys... I understand your points and I have just one more question ...
I want to design a Filter (It does filter somethings) and subclasses actually handle filtering. 'Filter ' won't provide any implementation what so ever except a declaration of abstract method 'filter(....)'. Which is the better design wrting an abstract class or an interface?
To my knowledge, I would write it as abstract class because it is , well, a noun and it does not provide any implementation ... what say?
# 7
> Thanks for the replies guys... I understand your
> points and I have just one more question ...
>
> I want to design a Filter (It does filter somethings)
> and subclasses actually handle filtering. 'Filter '
> won't provide any implementation what so ever
> except a declaration of abstract method
> 'filter(....)'. Which is the better design wrting an
> abstract class or an interface?
>
> To my knowledge, I would write it as abstract class
> because it is , well, a noun and it does not provide
> any implementation ... what say?
Absolutely not. If it provides no implementation at all, make it an interface. Don't get too hung up on mapping nouns to classes. An interface is really just a special kind of class anyway. Sort-of. I'm not getting into a debate about how the JLS defines "class" and "interface", to most intents and purposes they're much the same
# 8
georgemc ,
thank you for the suggestion. I now understand that naming of interfaces with adverbs should be done only if it makes sense otherwise you can just name them as classes .. and use abstract classes if a subset of needed methods have proper definitions and now it make much sense to me to have an interface and abstract class which implements some methods of interface ............. , or am I thinking too much into trifle of an issue?
# 9
> georgemc ,
> thank you for the
> suggestion. I now understand that naming of
> interfaces with adverbs should be done only if it
> makes sense otherwise you can just name them as
> classes .. and use abstract classes if a subset of
> needed methods have proper definitions and now it
> make much sense to me to have an interface and
> abstract class which implements some methods of
> interface ............. , or am I thinking too much
> into trifle of an issue?
No I think you're thinking about it the right amount :-)
# 10
> > Thanks for the replies guys... I understand your
> > points and I have just one more question ...
> >
> > I want to design a Filter (It does filter
> somethings)
> > and subclasses actually handle filtering. 'Filter
> '
> > won't provide any implementation what so ever
> > except a declaration of abstract method
> > 'filter(....)'. Which is the better design wrting
> an
> > abstract class or an interface?
> >
> > To my knowledge, I would write it as abstract
> class
> > because it is , well, a noun and it does not
> provide
> > any implementation ... what say?
>
> Absolutely not. If it provides no
> implementation at all, make it an interface. Don't
> get too hung up on mapping nouns to classes. An
> interface is really just a special kind of class
> anyway. Sort-of. I'm not getting into a debate about
> how the JLS defines "class" and "interface", to most
> intents and purposes they're much the same
Actually, not even sort of (ie, it is a fully true statement. Wait; fully true? That doesn't exist. We may need to extend boolean logic here.) The "Class" object is defined as representing both classes and interfaces. Java treats them the same.
# 11
> > > Thanks for the replies guys... I understand
> your
> > > points and I have just one more question ...
> > >
> > > I want to design a Filter (It does filter
> > somethings)
> > > and subclasses actually handle filtering.
> 'Filter
> > '
> > > won't provide any implementation what so ever
> > > except a declaration of abstract method
> > > 'filter(....)'. Which is the better design
> wrting
> > an
> > > abstract class or an interface?
> > >
> > > To my knowledge, I would write it as abstract
> > class
> > > because it is , well, a noun and it does not
> > provide
> > > any implementation ... what say?
> >
> > Absolutely not. If it provides no
> > implementation at all, make it an interface. Don't
> > get too hung up on mapping nouns to classes. An
> > interface is really just a special kind of class
> > anyway. Sort-of. I'm not getting into a debate
> about
> > how the JLS defines "class" and "interface", to
> most
> > intents and purposes they're much the same
>
> Actually, not even sort of (ie, it is a fully true
> statement. Wait; fully true? That doesn't exist. We
> may need to extend boolean logic here.) The "Class"
> object is defined as representing both classes and
> interfaces. Java treats them the same.
Heh heh the "sort-of" condition was to fend off the JLS-quoting argumentative types :-)
Had pretty much exactly that argument in the past.
# 12
> Absolutely not. If it provides no
> implementation at all, make it an interface.
And another thing the OP should be aware of is that YourClass can inherit from one superclass only -- while you can have YourClass implement as many interfaces as you want. So if you designed YourClass to extend an abstract class (without need) and suddenly your design requires it to extend another class... you're stuck.
# 13
and when differentiating between classes even if they are abstract and interface, lets not forget what generalization and realization mean from an OO perspective!!
