The term "abstract" has been adequately defined in this thread, so I won't
repeat it.
However, there is one important aspect of the term "interface" which I think
that most people seem to miss - it is not necessary to use the term
"interface" in order to have an interface. Let me explain with a code
sample:
class foo {
function something ($arg1, $arg2, ...) {
....
} // end something
} // end class foo
Here I have defined a class "foo" with a method called "something". This
method as it stands is already an interface (as in Application Program
Interface or API) and does not require anything extra for it to be accessed.
All I need is the following:
$foo = new foo.
$result = $foo->something($arg1, $arg2, ...);
In order to include the term "interface" in the code you need something like
the following (which is taken from the PHP manual):
// Declare the interface 'iTemplate'
interface iTemplate
{
public function setVariable($name, $var);
public function getHtml($template);
}
// Implement the interface
// This will work
class Template implements iTemplate
{
private $vars = array();
public function setVariable($name, $var)
{
$this->vars[$name] = $var;
}
public function getHtml($template)
{
foreach($this->vars as $name => $value) {
$template = str_replace('{' . $name . '}', $value, $template);
}
return $template;
}
}
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.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
""Daevid Vincent"" <daevid@xxxxxxxxxx> wrote in message
news:0ba401c89f88$a7395460$450a0a0a@xxxxxxxxxx
> -----Original Message-----
> From: Larry Garfield [mailto:larry@xxxxxxxxxxxxxxxx]
>
> If your code doesn't have an API and clear separation of
> parts, then neither
> abstract classes nor interfaces are useful to you.
>
> If you're coding anything of respectable size, vis, more than
> a one-off 1000
> line script or less, then you either want to have an API and
> clear separation
> of parts or I don't want to hire you, because your code is
> going to be an unmaintainable mess.
That is soooo not true. My last company had nearly 15 developers and we
never used either of these concepts in the six years the company existed. We
had perhaps 50+ classes and some had upwards of 5-KLOC each. We had three
databases with almost 300 tables. We had an external XML API that hooked
into these classes with 'set', 'get', 'add', 'delete' and all the commands
you would expect. And we weren't doing simple stuff either. This was an
extremely complex appliance that was HEAVILY PHP/Ruby driven
(http://www.lockdownnetworks.com).
I'm not trying to start a war here, I just really don't see how any PHP
project other than the very fringe examples such as a DB abstraction project
or huge PEAR project has any _real_ need for this. Sure, it's all text-book
and "proper" perhaps, but to me it just seems like bloat and if you intend
to extend a given class, you STILL have to read the source code and examine
the abstract class or interface anyways to know what you have to implement
in your derived class (right?)
90% of the LAMP projects amount to some website/service, some user
registration, some blogs or threaded discussion, some database entries.
They're really not all that complex in the big picture.
I can sort of see the use for these if you were designing an operating
system or a device driver or something HUGE. But come on -- a website is
really not that big (code wise). It may have thousands of pages, but they're
built from a relatively small amount of dynamic PHP pages.
In any event, thanks for your detailed reply Larry. I get the concepts. I
just don't see the general-use-case need in PHP's OOP world. Maybe sometime
the light-switch will flip on for me and I'll realize I've been skating
uphill all these years...
Daevid.
P.S. you should look at my resume before you decide not to hire me ;-p
http://resume.daevid.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
