2013/5/16 Tedd Sperling <tedd.sperling@xxxxxxxxx> > -Dan: > > I teach this stuff and still don't fully understand the why/when for > interfaces. > > Even the guru's I talk with can't give me a good explanation as to what > the advantages are in using them. I've done a lot of experimenting and > can't see any advantage for them other than grouping different classes > together and creating a new data-tytpe. > An interface is like an contract: It doesn't do anything itself, but every class, that implements it must follow. This isn't only about the signature of the methods, but also about the semantics, which is ideally described directly in the methods comment (DocBlocks). On the other hand the class is completely free on how it fulfill the contract. For example: A "QueueInterface". It probably defines the signatures for (at least) "enqueue()" and "dequeue()" and their semantics: "enqueue()" enqueues an element at the end of the queue and may fail with an XY-Exception, when the queue is full, "deuqeue()" dequeues an element from the front of the queue and throws an Z-Exception, when the queue is empty. An implementing class is free to implement this on top of a database, or an array, as well as the class is free to extend it with other methods as it like. Of course you could implement it as abstract class, but this leads (instantly, or later) to a mix between contract and implementation details, that (by the way) should be up to the implementing class anyway. Now that you have one, or more classes implementing that interface you can type hint against this contract and only against this one, because it is better to always hint against the most-simple type the methods requires. In this example this means: I, the method x(), expect a queue and I am completely uninterested in how it is implemented, or what other features it provides, because I don't use them anyway. Now you can give me a database-cursor, or a wrapped array as long as they _behave_ like a queue (--> implementing that interface). As a side effect: Sometimes it is more fail-safe, because if you change signatures, or add methods, you'll face the errors from wrongly implemented classes instantly ;) Oh: And you are not forced to extend a class :) Lets say I have a "Comparable"-interface and a "User"-Class. Would "Comparable" be a class, I have to extend it, which makes it impossible to extend any other class and also the semantic is wrong: A "User" _behaves_ like a "Comparable", but it _is not_ a "Comparable". (For me implementing an interface is usually more a "behaves like", "looks like", or "provides", whereas extending a class is directly a "is a"-relationship). This said, the difference between an interface and an abstract class is mostly in the head: An abstract class is in my opinion never such a strict contract, like an interface, especially because you can always leave the "contract-only"-restriction by implementing something into the class, what is then directly inherited by the subclasses. My 2 cent :) But for me this "idea" works quite fine :D Regards, Sebastian > > Other than that, from my perspective interfaces are mythicode. > > So, if you find a good reference, please let me know. > > Cheers, > > tedd > > > _____________________ > tedd.sperling@xxxxxxxxx > http://sperling.com > > > > > > On May 16, 2013, at 11:11 AM, Dan Joseph <dmjoseph@xxxxxxxxx> wrote: > > > Thanks! This looks like a good start. Covers some things I have > questions > > on. I like his approach. > > > > Now I just need something advanced to continue on after this. I'd like > to > > learn more about extending, interfaces, abstracts, and why/when they > should > > be used. > > > > Appreciate it! > > > > -Dan > > > > > > On Thu, May 16, 2013 at 11:01 AM, Francisco C Soares < > dotjunior@xxxxxxxxx>wrote: > > > >> On 05/16/2013 11:55 AM, Dan Joseph wrote: > >> > >> Hey Folks, > >> > >> I'm looking to refine my PHP 5 OOP skills. I know the basics, > understand > >> patterns, but have clearly missed a few things along the way. > >> > >> Do any of you have some real good PHP 5 OOP tutorials/reads bookmarked > you > >> could share? Something other than php.net/oop5. > >> > >> Try, > >> Tente, > >> > >> http://www.killerphp.com/tutorials/object-oriented-php/ > >> > >> Success! > >> Sucesso! > >> > >> ___________________________ > >> Francisco C Soares ( *Junior* ) > >> 403790c898466667cdbe5a262146de8fb93139c4 > >> > >> BLOG dotjunior.blogspot.com > >> > > > > > > > > -- > > -Dan Joseph > > > > http://www.danjoseph.me > > http://www.dansrollingbbq.com > > http://www.youtube.com/DansRollingBBQ > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- github.com/KingCrunch
