RE: Class and interface location

["Tommy Pham" <tommyhp2@xxxxxxxxx>]

> -----Original Message-----
> From: larry@xxxxxxxxxxxxxxxx [mailto:larry@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, January 19, 2011 2:21 PM
> To: php-general@xxxxxxxxxxxxx
> Subject: Re:  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.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php