This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Re: Interface everywhere?
Posted by Pierre-Antoine Champin on 16 Dec 1998, 12:14 AM
> So should I use an interface to wrap every
> class whose implementation might change in the future?
IMHO this is not the point:
You should wrap a class in an Interface if you think another
class with a totally different implementation could have the
same behaviour than yours - and you want to be able to handle
one or the other in the same piece of code...
> Depending on your level of paranoia about implementation changes,
> this could include almost every class of a program.
Sure that could, but that's more a matter of flexibility than
> For example, suppose we pretend Java's File class does not
> exist. Should a File class that I might write be have an
> interface? Surely the implementation of delete() method
> that allows a file to remove itself will change if I decide
> to port my application from UNIX (rm) to DOS (del).
I think the delete methodis quite tricky here - this precise one
is more like a native method (the system-dependant implementation
is done in the VM, not in the java classes).
But if you plan to use an exotic file system (say, access
files through the network through FTP) and handle exotic file
just the same way as "normal" files, that could be useful for
File to implement an interface you could implement too.
Btw, that's just too bad Sun didn't think of it...
> What is the rule of thumb for setting this level of paranoia?
Hard to say :)
Mine would be quite extremist, since I'm a flexibility maniac,
but actually even I don't write an Interface for every class I
And I thank you for giving me the occasion to preach once again
for the "inheritance insertion", mentioned in other mails on
that group :
since Sun didn't wrap the class File in an interface, if I need
such an interface, that would be great if I could define such
an interaface (copying the public methods of File) and declare
a posteriori that java.io.File and my.package.FTPFile both
implement this interface.
With such a feature, you shouldn't have to worry about the
possible use of the classes you write. People could add the
needed interfaces after you, so you don't have to wrape your
classes - unless your application need more than one class
with the same interface, of course...
This is one step further in the flexibility interfaces offer.
Thanks for listening me *again* :)