Re: 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 <larry@garfieldtech.com>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