Re: Using abstract class that implements interface
- From: "Matt Humphrey" <matth@xxxxxxxx>
- Date: Sat, 18 Apr 2009 14:34:07 -0400
"Zuisman Moshe" <zuismanm@xxxxxxxxx> wrote in message
news:655662de-4d5f-4f5c-a7fb-d360d08ec0b4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi dear All...
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"???
For me the issue of optimizing the tradeoff of using an interface vs. an
abstract class is in whether all instances must be required to share the
base class. If your design works using an interface, the fact that some
implementations happen to share a base class does not make it redundant.
The design permits future implementations that do not share the same base
class. They may even use a concrete foo instance, which follows the
guideline of preferring composition over inheritance. The design simply
needs to be clear that the interface defines the contract and the abstract
class is a hidden detail of the implementation.
On the other hand, if your design works with all instances as subclasses to
the abstract class, there is no problem in skipping the formality of the
interface. The abstract class itself defines the contract. At this point,
the interface is unnecessary and would create confusion as to which one
should be used.
It is not clear to me which case applies to your design. You seem to
generally use foo_interface, but you also talk about how all real classes
inherit from foo_abstract_class. If you *never* use the object as
foo_abstract_class, go ahead with the interface route. Otherwise, if you
can't easily distinguish them, drop the interface.
(As an aside, the variable type you use to "keep them as instances" has no
effect on how the object behaves. It does not affect serialization,
methods, etc. It only affects how the compiler perceives the object
reference.)
Matt Humphrey http://www.iviz.com/
.
- References:
- Using abstract class that implements interface
- From: Zuisman Moshe
- Using abstract class that implements interface
- Prev by Date: Re: Using abstract class that implements interface
- Next by Date: Re: Using abstract class that implements interface
- Previous by thread: Re: Using abstract class that implements interface
- Next by thread: Re: Using abstract class that implements interface
- Index(es):
Relevant Pages
|
