Interfaces

[Ratty]

Some of the core library classes implement interfaces, but not all of them.

In a website I developed with CakePHP I had need of a caching version of HttpSocket and a throttled version ( this version only allows 1 request per second to be made ) these were specifically to talk to the Amazon servers. I proceeded with creating my own interface ISocket with a dummy version of HttpSocket (NormalSocket)  which extended HttpSocket and implemented the interface. I then created a caching version and a throttled version. All three classes took an ISocket in their constructor so I could create a socket that could Cache, Throttle or Both at creation time. $socket = new CachedSocket( new ThrottledSocket( new NormalSocket() ) ); Would create a Cached and Throttled version of HttpSocket().

This also aided greatly in testing my code since all I needed to do was create a dummy class that implemented ISocket() and pass it to CachedSocket() for example so I could test all the caching functionality without making any requests.

So basically the implementing of interfaces does, in my opinion, aid greatly to the flexibility of the code we write. So would it be a good idea to have ALL library classes that may need extending as implementers of interfaces ?

[mark_story]

I don't think interfaces for the sake of interfaces really adds that much.  Sure they can give you a warm and fuzzy feeling as you go about adding type hints to your code thinking you'll be safe from some foolish developer who tries to pass some random object into your method.  However, PHP doesn't work like that. Type hints are just that hints.  You get a non-fatal warning when you ignore the type hint, and then you get the normal fatal error when the random object.  In the end no-one has benefitted.   The fatal error wasn't avoided, and all you got was two errors.

Interfaces also create problems with compatibility going forward.  When creating non bc-breaking releases you *cannot* modify interfaces.  The same goes for adding new abstract methods.  The only real problem interfaces solve is by letting end developers know which methods other things are expecting a thing to have.  Like a development checklist really.

With that said, I think having a few interfaces/abstract classes where people actually routinely extend things makes sense.  In 2.0 we added a few interfaces for the most commonly extended classes that require the end developer to flesh out methods.  I wouldn't have put HttpSocket in that camp though.  Outside of datasources and dbosource, I can't think of any classes that really should have an interface that currently don't.  Most of the extension points are currently handled by base classes. I guess its arguable that there should be an interface for every base class, but I think that's a bit ludicrous, but maybe I'm wrong :)

-Mark

[Steve Found]

I think interfaces are a little deeper than adding type hints and a
function checklist to be fair :). They were introduced into Java as a
solution to the fact that it (like PHP) has single object inheritance
and you could therefore not have multiple inheritance like C++ does. So
in effect, an interface is analogous to a base class and passing an
object that implements an interface to a method is stating that the
object can be treated as if it were an instance of that class. PHP does
also error if you declare a class as implementing an interface and you
have not implemented all the declared methods.

I am probably being over zealous as my background is in Java and C++, I
have only really become interested in PHP over the last couple of years
and it should never be forgotten that PHP is an interpreted language
whose main reason of existence is to deliver web pages as quickly as
possible. Adding interface dependencies to everything would indeed be
ludicrous. I just found it nice to have in Sockets since it made my own
socket more flexible without the need to inherit behaviour from
HttpSocket or CakeSocket and testing so much easier.

With regard to breaking backwards compatibility though, why can you not
modify interfaces ? As long as the modification is backwardly
compatible just as it would have to be with classes and there is nothing
to stop you extending an interface and marking the original as
deprecated would there be a problem ?

Steve (Ratty)

[mark_story]

Just like a checklist really.  Interfaces in PHP do enforce parameter counts and default arguments, but don't enforce return types at all.  So they really aren't the same as interfaces in c++ or java.

 

I am probably being over zealous as my background is in Java and C++, I
have only really become interested in PHP over the last couple of years
and it should never be forgotten that PHP is an interpreted language
whose main reason of existence is to deliver web pages as quickly as
possible. Adding interface dependencies to everything would indeed be
ludicrous. I just found it nice to have in Sockets since it made my own
socket more flexible without the need to inherit behaviour from
HttpSocket or CakeSocket and testing so much easier.

With regard to breaking backwards compatibility though, why can you not
modify interfaces ?  As long as the modification is backwardly
compatible just as it would have to be with classes and there is nothing
to stop you extending an interface and marking the original as
deprecated would there be a problem ?

I was thinking more around adding methods to an interface, this breaks existing code that attempts to upgrade as the implementor probably lacks the new methods.  Creating new interfaces is the one way to avoid that issue though. 

Steve (Ratty)