On Wed, Apr 16, 2008 at 9:13 PM, Daevid Vincent <[EMAIL PROTECTED]> wrote:
> > >> All that extra code for absolutely no benefit! It is
> > possible to define an
> > >> interface (as in API) without actually using the term
> > "interface", so IMHO
> > >> the term "interface" is totally redundant and a waste of time.
> > >
> > > While I agree that Interfaces are mostly a lot of extra
> > code, I have to
> > > also say that they are there primarily to enforce a
> > contract between the
> > > user of the interface and their classes that claim to implement the
> > > interface. If someone creates a class that "Implements" an
> > interface,
> > > then when I have to go edit or use the class, it had better
> > damn well
> > > implement what it says it does :)
> >
> > "enforcing a contract" is a lot of maningless gobbledegook.
> > The simple fact
> > is that it is possible to have an interface without ever
> > using the term
> > "interface". Nothing extra is added by using the term
> > "interface" (except
> > for effort) so there is absolutely no advantage in doing so.
> > That is why I
> > say that the term "interface" is a waste of effort as
> > absolutely nothng is
> > gained.
>
> So if the only real benefit is to be some kind of required template for
> methods in 'extended' classes, why wasn't it "implemented" (excuse the pun)
> to be something like this (with interface as a keyword like abstract is or
> final or static):
>
> class Template
> {
> private $vars = array();
>
> interface public function setVariable($name, $var)
> {
> $this->vars[$name] = $var;
> }
>
> interface public function getHtml($template)
> {
> foreach($this->vars as $name => $value) {
> $template = str_replace('{' . $name . '}', $value, $template);
> }
>
> return $template;
> }
>
> interface public function notYetCreatedMethod($foo) {}
>
> interface public function notYetCreatedMethod2($bar)
> {
> return true;
> }
>
> public function someNotRequiredMethod ($fee)
> {
> return $fee + $fo;
> }
> }
>
> So now it would seem that the four methods are 'required' to be in
> extension classes and can be defined or not defined just like an abstract
> class right?
right, just like an abstract class; not like an interface. heres where it
shys away from the interface concept,
interface public function setVariable($name, $var)
{
$this->vars[$name] = $var;
}
youve specified a concrete method here; thats not allowed in an interface.
if you want to do it w/ an abstract class, this is how you do it.
abstract class Silly {
abstract function a() {}
abstract function b() {}
}
does that make sense? great, so how do we use it;
abstract class Cool extends Silly {
function a() { // define behavior }
function b() { // define behavior }
}
damn! we just threw away our 1 chance to extend something on the Cool
class; and i thought it was supposed to be cool! the whole problem is, php
is a single inheritance language. that means you cannot extend classes more
than once. therefore, using the extends keyword on a class is :read a BFD.
so how do we handle multiple inheritance in a single inheritance language?
simple (ive posted this before, but f-it; if dupes are common place then so
be it) by using composition.
so to try and keep it brief:
interface A { function a() }
interface B { function b() }
interface AImpl { function a() { // standard concrete implementation } }
interface BImpl { function b() { // standard concrete implementation } }
class C function c() { // do concrete stuff here }
class D extends C implements A, B {
$a = null; $b = null;
function __construct() {
$a = new AImpl();
$b = new BImpl();.
}
function a() { // do standard concrete A stuff via delegation
return $this->a->a();
}
function b() { // do standard concrete B stuff via delegation
return $this->b->b();
}
}
we do this is because we php doesnt support the following;
class D extends A, B, C { // you know the rest }
could it be done w/o interfaces; of course. but then it becomes difficult
to determine what the hell is going on. why does D have a() and b() ??
because theres some client code out there that expects it. better know
about that code otherwise youre SOL. by using interfaces its clear when
reading this code, using this code or creating similar code that it *must*
have those methods because its obligated by claiming it implements the
interface.
I have to agree with Tony. This whole "interface" business just seems
> redundant and a waste of code.
well lets think about it. what is polymorphism??? that means multiple
things support the same action; period. so looking at an example w/o
interfaces, supposedly we wont have redundant code; lets zoom in on this
theory.
class A {
function a() {}
function b() {}
}
nice; i have a little class; it does 2 things. so, i have some code that i
use to call it right, cause its really useful; lets take a look:
function doStuff($aThing) {
$aThing->a();
$aThing->b();
}
$a = new A();
doStuff($a);
now i want to build some more cool stuff, cause i just love programming
these awesome classes. but i want to be smart about it; i dont want to
clutter up my doStuff method w/ some worthless conditionals, or switch code;
thats for old timers ;) so ill try this out:
class B {
function a() {}
function b() {}
}
holy crap !! now i can use instances of the B class wherever i can use
instances of the A class and i dont even have to bother checking which type
of class the instance actually is :O that *is* the advantage polymorphism
brings to the table. so you tell me; have we duplicated anything in classes
A and B ?? looks like weve duplicated a() and b() in the instance methods.
if you ask me, thats the entire point. to duplicate a set of methods, an
interface. that is what polymorphism is all about.
all the interface construct is, is another step down this road:
interface IlearnedSomethingNewToday {
function a()
function b()
}
now A and B can both implement this interface and we can all go home early
because we didnt spend all day coming to the realization that A and B have a
common set of methods for a particular reason. and we dont have to know
about doStuff() wanting to call all those methods either. any client code
that works w/ IlearnedSomethingNewToday can rightfully expect support of
both a() and b(). but i ask you, is writing the interface any more
*duplication* than adding an additional class to the system (w/o interfaces)
?
class C {
function a() {}
function b() {}
}
no, its not. does it clarify WTF is going on in the code for us; yes. is
it faster than run time checks in userspace
eg.
function isIlearnedSomethingNewToday($instance) {
if(is_object($instance) && is_method($instance, 'a') &&
is_method($instance, 'b')) { return true; }
else { return false; }
}
yes. and we know at compile time if new classes are missing methods theyre
supposed to have. also, in php5 we can use type hinting as well:
function doStuff(IlearnedSomethingNewToday $aThing) { //...
and this is still just the tip of the iceberg; previously i thought php
didnt support interface inheritance, search the archives; last time around
in this conversation i lamented about it. but in recent history (again in
the archives; i discovered this is supported). so for example
interface A {
function a()
}
interface B {
function b()
}
interface C extends A, B {
function c()
}
class D implements C {
function a() {}
function b() {}
function c() {}
}
why would you want to do that? the same reasons you would want multiple
inheritance in a class hierarchy. interfaces are lightweight abstract
classes; they are entirely abstract; and they dont cost you an extends
keyword. they are very powerful.
here is yet another common pitfall of inheritance alone
class Z {
function a() {}
function b() {}
function c() {} // note use only in C subclass
}
specific methods for specific subclasses are disastrous. interfaces to the
rescue:
class Z {
function a() {}
function b() {}
}
interface CStuff {
function c() {}
}
for those of you who still doubt me i submit the following;
1. if interfaces are a useless waste of code duplication, then why have they
been ported to a number of languages, php included?
2. read the first chapter of Head First Design Patterns. when you find out
how joe got burnt by inheritance, your perspective will be changed.
-nathan
