ALarry Garfield wrote:
On Tuesday 15 April 2008, Daevid Vincent wrote:
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?
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.
And, I believe that you can't instantiate abstract classes, they can
only be inherited.
-Shawn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
