NYCPHP Meetup

[Andrew Yochum]

On Fri, Oct 08, 2004 at 02:41:22PM -0400, csnyder wrote:
> Correct me if I'm wrong (as you will!), but Interface definitions
> can't contain code. You're specifying method names, but not actually
> defining those methods.

Right... interfaces just declare the methods that a implementing class must
define.
 
> So how can you inherit from them? 

Many call it a solution for multiple inheritance, but really it is an
alternative that doesn't achieve exactly the same thing...  but they are really
really useful!
 
> As far as I'm concerned, Interfaces are a pre-production tool for
> large or distributed projects. A lead developer writes the Interface
> definitions, then directs the coders to write Classes that implement
> those Interfaces.

Interfaces aren't JUST for that.  They can be useful for creating an API that
will be guaranteed to be implemented.  Think of it as a contract between the
caller and called code.  If two pieces of code can expect each other to
implement particular interfaces, they in theory should be able to inter-operate
without changes.
 
> I don't see the utility for smaller or single developer projects,
> unless there is a code repository (!!!) somewhere that has a
> collection of extremely-well-written standard interfaces.

Consider the the SPL API in PHP 5... it defines a collection of very useful
interfaces that will allow code to operate on your custom classes seamlessly
provided they implement the interfaces.  Right now it is limited to just
Iterators, but eventually I'm sure we will have more and more standard
interfaces in PHP that will help inter-operation between various libraries and
applications, or just simply standard methods for doing the same thing.  For
instance, nearly every OO database abstraction layer I've used in PHP operates
differently.  If they all implemented the Iterator, at least I could loop over
results the same way.

C++ has the STL. Java has all kinds of standard interfaces... Collections,
JDBC, JAX, JAAS, JSP, etc...  the list goes on and on.  What Java has
accomplished with these collections of interfaces are common APIs that allow
multiple implementations of the same API to be swapped in and out for each
other.  It gives you plugin-like functionality because they emerge out of
common patterns in coding.  It isn't necessary to do things the same across
multiple code bases, but it helps interoperability if you do.

Consider the following example of a single developer taking advantage of this
in Java.  There is an array of items that to date was static in memory, and
they're stored in a List java object.  Since a List is an interface and it
can't be instantiated, the ArrayList implementation is used because it offers
constant random access time, it's low-overhead, BUT it doesn't offer constant
time to add or delete many items to it.  But now, this list has become dynamic
in memory and the performance is sub-optimal.  The implementation class can
easily be swapped out for the LinkedList implementation of the List interface
which is optimal in this situation because it offers constant time for adding
and removing elements from the list, however, it offers poor random access
time.  So the change is simply what class gets instantiated... which can
actually be decided by a configuration/properties file or even dynamically at
runtime.

I'd suspect that most PHP developers aren't concerned about things like this
but increasingly there are many that are... maybe because their applications
demand such behavior or their business requirements dictated this.  As PHP
grows-up and becomes adopted in enterprise (eek, i said that word) applications
more and more, there will be a need for more and more interfaces.  Hopefully
these interfaces will be made public and standard, and not kept internally.
Individual developers will reap the benefits of them because of well-documented
and standard APIs that allow for easy integration of external libraries or
applications into their own.

Andrew