Zuisman Moshe wrote:
It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA [sic] (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
All perfectly legitimate, idiomatic and beneficial.
colle[a]g[u]es - that come from JAVA [sic] programming - says - it is
redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA [sic] world"???
Your colleagues are wrong. You should publish the interface name, not the
class name; that is the best practice. That way if you need to create an
additional inheritance tree for the interface or directly implement the
interface in a concrete class, you don't break client code.
Point your colleagues to the many articles about "programming to the
interface", a best practice in O-O programming, and Java programming in
particular. They need to study more, and pay more attention to your
wisdom.
methods. What in Smalltalk would be called a 'protocol'. An abstract base