Re: Using abstract class that implements interface
On Sat, 18 Apr 2009, Zuisman Moshe wrote:
It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... For me it looks logical...
Abstract class keep common part of internal implementation, but for
"external world" they are all instances of foo_interface... But - my
colleges - that come from JAVA programming - says - it is redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA world"???
It's strictly a matter of taste and/or appropriateness to the situation.
Both are legal and defensible.
The interface + abstract base class pattern is quite common - the obvious
example that springs to mind is the set of pairings of List/AbstractList,
Map/AbstractMap, etc in the collections framework. However, it does mean a
little extra complexity, and the benefits may not justify that in all
situations.
Personally, i'd start with just the abstract base class, doing double duty
as an interface definition and a home for common methods, and later on, if
i needed to, i'd refactor to separate the interface and implementation.
There's just no point building in more complexity than you need at the
start.
tom
--
curry in a sack