2013/5/16 Tedd Sperling <tedd.sperl...@gmail.com>

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

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


> Other than that, from my perspective interfaces are mythicode.
> So, if you find a good reference, please let me know.
> Cheers,
> tedd
> _____________________
> tedd.sperl...@gmail.com
> http://sperling.com
> On May 16, 2013, at 11:11 AM, Dan Joseph <dmjos...@gmail.com> 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 <
> dotjun...@gmail.com>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


Reply via email to