On 05/16/2013 06:45 PM, Tedd Sperling wrote:
Thanks to both Bastien and Sebastian:
While I understand that an interface is like an abstract Class, in that you don't have to flesh-out your methods, but rather where you define exactly how Classes who implement that interface will be required to flesh-out those methods. But so what? What's the point?
Without giving me complicated examples, just give me one simple example that illustrates the advantage of using an interface over writing a new Class where you flesh-out whatever methods you want. After all, an interface requires the same thing, does it not?
As such, I just don't see the advantage interfaces bring.
Cheers,
tedd
Practical example, PSR-3:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md
Say you're writing a stand-alone library, maybe a Twitter-connecting
library. You want to be able to log stuff, but don't want to have to
deal with opening log files yourself. You also want to allow your
library to be used by people running Symfony, Code Igniter, Drupal, Zend
Framework, or PHPBB, all of which have their own logging systems in
place that may talk to syslog, a database, files on disk, or whatever.
People using those frameworks don't want your library spewing log files
all over their file system.
Instead, you simply support the PSR-3 logging interface. You accept an
object that implements that interface in your constructor, and then
write to it. What happens on the other side? Who gives a damn!
For your own testing, you can write a simple class that implements that
interface and dumps log messages to disk.
When someone uses your library with Symfony, they just pass in a Monolog
object (the logging system used by Symfony), and your code is now
logging errors to whatever they have Monolog configured to do.
When someone uses your library with Drupal, they just pass in the Drupal
Watchog logger object (which is being rewritten to use PSR-3 as we
speak), and now your library is logging errors to Drupal's logging
system (which could be syslog or a DB table, depending on how the user
has their site configured).
And you don't give a damn about any of that. All you care about is that
you support "any object that matches this interface". What that object
does with the messages you send it, and where that object came from, you
don't have to give a crap about.
Now take that same concept and apply it at a smaller scale, within your
own project. Swap out your database-based cache system for a
memcache-based one. Your code doesn't change, because it's writing to
an interface, not to the database. Swap out your data store with one
that is used just for testing. Etc.
That's what interfaces give you. Loose coupling, and the ability to
divide-and-conquer... and even let someone else solve problems for you. :-)
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
