Separation of interface and implementation

One of the first things I was told in OO is to separate the interface from implementation. In languages like java, which supports the "interface" keyword, this is kept almost religously by some people. I recenlty looked at the source code of the popular Bittorrent client Azureus, almost every thing comes in pairs, e.g., IFoo.java and FooImpl.java. Of course, all the java standards from Sun are really just interfaces. My understanding of the reason for this separation is so that people can substitute a new implementation for the same interface. This is very handy for such things like XML parsers, and the logging API.

In perl, there isn't an "interface" keyword. The only built-in construct (that I can think of) that has this interface substitution is the "tie" function, with which one can subsitute different implementations of arrays, hashes, etc. There are many modules that use this principle, e.g., DBI.

I'm of the opinion that to qualify for a real separation of interface and implementation, one should be able to switch an implementation without changing a single line of client code. In java, this is often accomplished via the Factory pattern (i.e., the client never need to call "new", which would require the client to know the name of implementation class.) I haven't looked enough to see much use of that pattern in perl, I assume that is not really necessary since in perl even the class name can be a variable.

Comment on Separation of interface and implementation

Replies are listed 'Best First'.
Re: Separation of interface and implementation by eyepopslikeamosquito (Archbishop) on Dec 20, 2004 at 08:46 UTC
This is discussed in section 6.2.5 ("Implementing abstract methods") of TheDamian's classic book, Object Oriented Perl. The technique he outlines is simply to define the method normally and ensure its code throws a suitable exception. If it gets too tedious to do this manually, he presents a utility method to do it. Given the number of questions you ask and your obvious love of Perl, I'm sure you'll get many hours of enjoyment from this wonderful book. ;-) And it has an excellent appendix comparing Perl with Java (and C++, Smalltalk, and Eiffel) feature-by-feature.	[reply]
Re^2: Separation of interface and implementation by johnnywang (Priest) on Dec 20, 2004 at 18:52 UTC
Thanks, I do have the book, and am in the process of reading it, but I always found it helpful to re-organize any book in my own mind, and seek comments/viewpoints from others. PM is the perfect place for anything perl.	[reply]
Re: Separation of interface and implementation by demerphq (Chancellor) on Dec 20, 2004 at 10:46 UTC
One of the first things I was told in OO is to separate the interface from implementation. Just so you know this isnt just an OO thing. Its a general programming thing. OO just presents one way to do it "easier". --- demerphq	[reply]
Re: Separation of interface and implementation by Thilosophy (Curate) on Dec 20, 2004 at 11:19 UTC
In perl, there isn't an "interface" keyword. The "interface" keyword in Java provides a way for the compiler to check that a certain class implements the set of methods that make up this interface. The Perl compiler does not do this for you, so you cannot declare an "interface" to the compiler. You can, however, declare it to the programmer, for example in a POD. A good example of many independent implementations of such an interface are the low-calorie drop-in replacements for CGI.pm, or Apache::Request which emulates CGI.pm for use under mod_perl. Note that none of these implementations provides the whole interface of CGI.pm (they are, in fact, making a point of not doing so), that the Perl compiler cannot warn you about this, and that things work anyway (if you read their POD).	[reply]
Re: Separation of interface and implementation by chromatic (Archbishop) on Dec 20, 2004 at 18:55 UTC
Java's interfaces have some limitations, including: No code re-use. No run-time decoration or class annotation (to my knowledge) that allows you to say that a specific class implements an interface. No shared namespace between class names and interface names, so if you want to substitute a class of a different name where library code does not use an interface, you cannot. The first is the most annoying, though if you're using Java without a code generator, you've asked for it. The third is the most serious.	[reply]