RE: [PHP] Class and interface location
| From: | Tommy Pham | Date: | Thu, 20 Jan 2011 02:56:50 +0000 |
| Subject: | RE: [PHP] Class and interface location | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-310888@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: larry@garfieldtech.com [mailto:larry@garfieldtech.com]
> Sent: Wednesday, January 19, 2011 2:21 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Class and interface location
>
> On 1/19/11 3:44 PM, David Harkness wrote:
> > What about creating your own docblock tag such as @plugin-interface?
> > While it still requires each plugin to explicitly define the
> > interface(s) it implements, it won't be in the class declaration. This
> > would be very easy to nab for a tree of files using grep, removing the
> > need to do any static analysis or parse PHP code.
> >
> > David
>
> I'm not sure I see the advantage of that over specifying the interface in
the
> code:
>
> /**
> * Bob does stuff.
> *
> * @implements Foo
> */
> class Bob implements Foo {
>
> }
>
> Either way developers need to explicitly define which interfaces (of those
> we care about) the class implements, and we'll have to string parse the
file
> to find the string "Foo". As far as I know the extra implements in the
class
> declaration doesn't hurt PHP, it's just redundant.
>
> And actually, thinking about it, I wonder if requiring the explicit
declaration
> is a good thing anyway because then it's immediately obvious and
> greppable what the class does. :-)
>
> --Larry Garfield
>
You mean requiring explicit declaration of
> class Bob implements Foo {
>
> }
It's so you can guarantee your app from future breakage because the
interface guarantees minimum functionality and still maintain great
flexibility such that:
interface IDatabase
{
function connect();
function close();
function query();
// etc....
}
class MySQLDatabase implements IDatabase
{
function connect() { }
function close() { }
function query() { }
// other interface methods
function nonInterfaceMethod() { }
}
class PostgresDatabase implements IDatabase
{
function connect() { }
function close() { }
function query() { }
// other interface methods
function nonInterfaceMethod() { }
}
class MyObjectMapper extends MySQLDatabase
{
function getAll() { }
function edit() {}
// etc...
}
class Process
{
function _init(IDatabase $db)
{
$db->connect();
$db->query();
$db->close();
}
function exec() { }
// etc...
}
class PhonyObject
{
// miscellaneous methods even if the methods match exactly as the
IDatabase
}
$mdb = new MySQLDatabase();
$pdb = new PostgresDatabase();
$mom = new MyObjectMapper();
$phony = new PhonyObject();
$p = new Process();
$p->_init($mdb); // works
$p->_init($pdb); // works
$p->_init($mom); // works
$p->_init($phony); // fatal error
Hence the
I in the API. The interface prevents from app breakage because
all classes must have matching method name(s) and the respective function
call parameters. Though, because PHP isn't a strong typed language like
C/C++/C#, Java, etc... the return value type, if any, _may_ break the app
;)
Regards,
Tommy
PS: outlook may wrap the lines... it happened once/twice before.