Re: [PHP] A Good OOP Tutorial/Read?

Hey Guys,

Thanks for all this good information so far.  I'll keep you posted on my
edumacation!

-Dan


On Thu, May 16, 2013 at 11:16 PM, Larry Garfield <[email protected]>wrote:

> 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<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
>
>


-- 
-Dan Joseph

http://www.danjoseph.me
http://www.dansrollingbbq.com
http://www.youtube.com/DansRollingBBQ