I've had at least three job interviews in the past two weeks, and each one has asked me this rather "text book academic" question regarding the difference between "abstract" vs. "interface". I've been coding for nearly 20 years, and at least 10 of those have been in PHP and another 3 in J++. I have NEVER used either of these concepts/keywords? Am I missing some exciting tool/feature?

All the reading I've done tonight just reinforces my thoughts that these are, for the most part useless. Unless you're building some HUGE project that has an API and there are teams of people that are going to extend your framework, then what good are they?

This DB wrapper is the closest to an answer I've come across.

http://www.developer.com/lang/php/article.php/3604111

But that still doesn't explain the difference between abstract and interface, it only illustrates the possible need for a 'template' so others know which methods they must implement. In my mind, it just seems like overhead, as if you were going to write another DB wrapper using this one, then wouldn't you just look at their code (example) and implement those same methods anyways? I mean, you'd have to look at the abstract/interface to find out the required methods, so why not skip that and just look at the actual class instead?

Here are two more pages that still don't seem to answer why there are both and when you'd use one over the other?

http://www.hiteshagrawal.com/php/oop...abstract-class
http://www.hiteshagrawal.com/php/oop...sing-interface

And then this completely absurd over the top use of them for a HelloWorld example, which seems to use them just for the sake of using them...

http://marc.info/?l=php-general&m=115950654928311&w=2

Lastly was this page:

http://www.phpro.org/tutorials/Objec...-with-PHP.html

Which seems to only really provide a "hack" (printerFax) to circumvent the lack of multiple inheritance.


Can someone clear this up for me?

Daevid.
http://daevid.com

Look at this url:
http://www.codeproject.com/KB/cs/abs...nterfaces.aspx Iñigo


--
--------
Iñigo Medina García
Librería Díaz de Santos Madrid (Spain)
imedina@diazdesantos.es facilmejor@gmail.com

[snip]
....stuff...
[/snip]

The practical use of an abstract class is in its ability to define
criteria for classes that inherit from it. How practical would it be to
define a 'truck' class with 4 wheels and then define a 'car' class with
4 wheels when we could define an abstract class that defines vehicles
with 4 wheels? Both of our classes can now inherit from that abstract
class and we can define features only relevant to them. If you refactor
diligently you will no doubt find places where you need to create
abstract classes.

The methods that are exposed by an object define the interface for that
object. It is how everything outside of the object interacts with the
object. You don't have to know how the method works all you need is the
interface....like the gas pedal on the car.

Just adding one line to the topic...
Interfaces are like C or C++ headers files. Them are used to another
class(program in C) to call methods without care the implementation. In
other hand abstract classes are (as the name says) an abstract way to use
multiple specializations of the same group of classes. Like vehicle is an
abstraction to car, motorbike, bike... with that you can use the method ride
to all these vehicles using an vehicle variable pointing to an instance of
car, motorbike or bike.

Cheers.

Rodrigo Reis.

2008/4/15, Jay Blanchard <jblanchard@pocket.com>:

--
Atenciosamente,
Rodrigo.

You've just answered your own question, albeit in a rather naive way.

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.

Abstract classes and interfaces are a standardized, syntactic way to establish
an API and clean separation of parts. They are not the only way to
accomplish that goal by any means, but they are a commonly understood way
that, if used properly, can create a very good API and very clean separation
of parts. If used stupidly, of course, you'll create a system that is
completely inflexible and impossible to extend. That comes down to the skill
and experience of the developer and architect.

If you're not writing OOP code, then neither is of any use to you as both are
OOP concepts. (And you don't have to write OOP code if it doesn't make
sense, but don't shun it either because often it does make sense.)

In general, an interface defines a "front end" of a class, without specifying
anything about its implementation. All component A needs to know about
component B is that it implements interface Foo, meaning that you know,
absolutely, that you can call $b->foo() and get back a string and $b->bar()
and get back a database connection, because the interface says so. (If
that's not the case, then B is buggy by definition.) You don't know or care
how it goes about getting that database connection (creates it, loads it from
a cache, creates a fake one for you, etc.), just that you can call $b->bar()
and get back a database connection. A class may implement any number of
interfaces.

An abstract class defines a "front end" *and* the implementation behind it,
modulo some bits. It is exactly the same as any other parent class, except
that it defines bits of functionality that it is missing that its child
classes *must* finish. That's useful if you have some number of classes that
are *almost* the same, but have no "generic" form. Database abstraction
systems are probably the canonical example here.

Usually, you will want to use an interface (possibly with composition) over an
abstract class unless you have a ton of shared code, as interfaces are more
flexible in a single-inheritance system.

Yes, you can get by just fine without them. You can also get by without OOP
at all. However, there are some problems where OOP just makes things a lot
easier, and in OOP there are places where having a formal interface just
makes things a lot easier; like, say, when you're reading someone else's code
and trying to make sense of what it's supposed to do and what assumptions are
being made. Having that built right into the syntax can be quite useful,
even in a loosely typed language like PHP.

--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson

And, I believe that you can't instantiate abstract classes, they can
only be inherited.

-Shawn

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

Please take note of what I said. I did not say "if you're coding anything of
respectable size without interfaces and abstract classes, I don't want to
hire you." I said "If you're coding anything of respectable size clean
separation of parts and an API between them, I don't want to hire you."

Interfaces, abstract classes, and the rest of OOP are *A* way of defining an
API and separation of parts. It is not the only way. OOP is a tool, and
sometimes it's the right tool and sometimes it's not. Yes, it's overkill for
many small projects, but that doesn't make it never-useful.

I'm a Drupal developer. Our codebase is huge, and our contrib codebase is
over a million lines of code, I think. There's maybe 4 classes total in all
of that, all of them very recently added. :-) And yet the system itself is
extremely modular with clear APIs. It's the "modular and clear APIs" part
that makes it good, not the number of classes it has (or doesn't have).

Besides, interfaces and abstract classes only came to PHP in PHP 5. :-)

Now, that said, a 5000-line class? Unless 4500 lines of that is comments, I
have to question if you're understanding OO design properly. :-)

--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson

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


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

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

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP