php-general Digest 17 May 2013 13:04:16 -0000 Issue 8233
Topics (messages 321093 through 321101):
Re: A Good OOP Tutorial/Read?
321093 by: Nick Khamis
321094 by: Sebastian Krebs
321095 by: Bastien
321096 by: Tedd Sperling
321097 by: Nick Khamis
321098 by: Larry Garfield
321099 by: Dan Joseph
321100 by: tamouse mailing lists
321101 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
OO comes from the heart. You know you have it when everything you look at
turn into objects, attributes, accessors, mutators, and constructors.
When IBM transitioned from functional to OO level programming, they had their
top level engineers walk into a room and tell their employees that 80% of their
employes will not be able to make the transition. Which percent are you?
Ninus Khamis (PhD)
--- End Message ---
--- Begin Message ---
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
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.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
>
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2013-05-16, at 5:28 PM, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> -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.
>
> Other than that, from my perspective interfaces are mythicode.
>
> So, if you find a good reference, please let me know.
>
> Cheers,
>
> tedd
>
>
> _____________________
>
Tedd,
The best argument I've seen for interfaces is to abstract calling classes to
avoid binding to a particular framework. Phpmaster was where I saw that.
The idea was that by implementing an interface, the swapping out a framework
was much simpler since the only code that needed to be written was more the
interface adapter to the new framework
Bastien
--- End Message ---
--- Begin Message ---
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
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
interface Shape {
public double getArea();
}
class Circle implements Shape {
double radius;
public Circle(int double radius) {
this.radius = radius;
}
public double getArea() {
return (radius * radius * 3.1415);
}
}
class Square implements Shape {
double side;
public Square(int double side) {
this.side = side;
}
double getArea() {
return (side * side);
}
}
Please make an effort to understand polymorphic concepts of OOP as
they are rudimentary. Without that one will never grasp OO Patterns
(Gang of Four).
Ninus.
On 5/16/13, Tedd Sperling <tedd.sperl...@gmail.com> 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
>
>
> _____________________
> tedd.sperl...@gmail.com
> http://sperling.com
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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 <la...@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
--- End Message ---
--- Begin Message ---
Back to the OP's request, Ken Pugh's "Interface Oriented Design" goes quite
a long way in describing OO* and directly to the heart of why interfaces
make so much sense as a way of designing your code. It does not show PHP
examples, it tries to remain agnostic to language.
--- End Message ---
--- Begin Message ---
Nick:
I thank you for your addition, but what you provided did nothing to explain the
difference between abstract and interface.
In your example:
An abstract Shape with Circle and Square inheriting.
OR
An interface Shape with Circle and Square implementing.
Does exactly the same thing -- so where's the difference?
Also, your:
Please make an effort to understand polymorphic concepts of OOP as
they are rudimentary. Without that one will never grasp OO Patterns
(Gang of Four).
Was more insulting than helpful. Polymorphism was not the question asked.
Clearly the getArea() method is polymorphic and overridden in both Circle and
Shape classes and also in BOTH abstract and interface examples.
Additionally, I'm not sure what:
> (int double side)
means.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
-----
On May 16, 2013, at 8:47 PM, Nick Khamis <sym...@gmail.com> wrote:
> interface Shape {
> public double getArea();
> }
>
> class Circle implements Shape {
> double radius;
> public Circle(int double radius) {
> this.radius = radius;
> }
>
> public double getArea() {
> return (radius * radius * 3.1415);
> }
>
> }
>
> class Square implements Shape {
> double side;
>
> public Square(int double side) {
> this.side = side;
> }
>
> double getArea() {
> return (side * side);
> }
> }
>
>
> Please make an effort to understand polymorphic concepts of OOP as
> they are rudimentary. Without that one will never grasp OO Patterns
> (Gang of Four).
>
> Ninus.
>
> On 5/16/13, Tedd Sperling <tedd.sperl...@gmail.com> 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
>>
>>
>> _____________________
>> tedd.sperl...@gmail.com
>> http://sperling.com
>>
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--- End Message ---
