seems nobody has a proper example of how
a defined abstract class and/or interface can actually
be usefu beyond documentation or compile time checks.
well consider this (no code, it would take too much I think):
1. a CMS that manages a dynamic, user-created tree of nodes, each
node containing 'something'
2. each node could be represented by an Object which implements
various Interfaces that determine what kind of output and admin
interface it had. (the CMS would know about registered Interfaces)
3. each afore mentioned Object could be of a subclass of a
abstract (to disallow instantion) base class that stipulated an
api and functionality that allowed the CMS to determine the
tree-interaction rules for the object, permissions, etc.
the idea being to allow a generic body of code to act on, in
a meaningful way (display,edit,publish,etc), a user-created tree of
objects so that no explicit knowledge of the available 'node classes'
is required. interaction would be based on the known interfaces
each object implements.
I know what mean atleast :-)
Daevid Vincent schreef:
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/oops-in-php5/oops-in-php5-tutorial-abstract-class
http://www.hiteshagrawal.com/php/oops-in-php5/oops-in-php5-using-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/Object-Oriented-Programming-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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
