Re: Properly handling multiple constructors.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Peter Lind wrote:
One of the main points of the OP was that you can document the code
properly. Your example doesn't allow for nice docblocks in any way, as
you'll either have to param points or a whole lot of noise.

I dunno, seems highly documentable to me. Each route is handled by it's own method with the parameters being fully declared in the handler method's signature.

Quick note: __ prefixed functions are "reserved", you shouldn't use
that prefix for any of your own functions. However unlikely it is that
PHP will ever have a __construct_bluh() function ...

Yeah, I know... I threw caution to the wind in this quick example. But for the sake of archives and newbies reading them, I shouldn't have :)

Cheers,
Rob.



On 24 March 2010 15:22, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
Robert Cummings wrote:
Richard Quadling wrote:
Hi.

I have a scenario where I would _like_ to have multiple constructors
for a class.

Each constructor has a greater number of parameters than the previous
one.

e.g.

<?php
class myClass {
__construct(string $Key) // use key to get the complex details.
__construct(string $Part1, string $Part2, string $Part3) //
Alternative route to the complex details.
__construct(array $Complex) // All the details
}

Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
and 3 are the main details and well documented defaults for the rest
of the rules. Complex is all the rules.

Each constructor will end up with all the parts being known ($Key,
$Part1, $Part2, $Part3, $Complex).

But, PHP doesn't support multiple constructors.

Initially I thought about this ...

__construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)

But then documenting the first param as being 1 of three different
meanings is pretty much a no go.

So I'm looking for a clean and easily understood way to provide this.

I won't be the only user of the code and not everyone has the same
knowledge level, hence a mechanism that is easily documentable.

I think I may need a factory with multiple methods (FactoryKey,
FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
All these methods eventually call the real class with the complex
rule.

Is that obvious enough?
Factory method is probably the cleanest and simplest solution. Just pass
an ID as the first parameter to the real constructor and then it can route
to the appropriate behaviour:
Here's a better example (tested):

<?php

class Foo
{
   const CONSTRUCT_BLAH = 1;
   const CONSTRUCT_BLEH = 2;
   const CONSTRUCT_BLUH = 3;

   function __construct( $constructId )
   {
       static $map = array
       (
           self::CONSTRUCT_BLAH => '__construct_blah',
           self::CONSTRUCT_BLEH => '__construct_bleh',
           self::CONSTRUCT_BLUH => '__construct_bluh',
       );

       $obj = null;

       if( isset( $map[$constructId] ) )
       {
           $args = func_get_args();
           $args = array_shift( $args );

           call_user_func_array(
               array( 'self', $map[$constructId] ), $args );
       }
       else
       {
           // Generate an error or exception.
       }
   }

   static function __construct_bleh( $arg1 )
   {
       echo "Called: ".__FUNCTION__."( $arg1 )\n";
   }

   static function __construct_blah( $arg1 )
   {
       echo "Called: ".__FUNCTION__."( $arg1 )\n";
   }

   static function __construct_bluh( $arg1 )
   {
       echo "Called: ".__FUNCTION__."( $arg1 )\n";
   }

   static function getBlah( $arg1 )
   {
       return new Foo( self::CONSTRUCT_BLAH, $arg1 );
   }

   static function getBleh( $arg1 )
   {
       return new Foo( self::CONSTRUCT_BLEH, $arg1 );
   }

   static function getBluh( $arg1 )
   {
       return new Foo( self::CONSTRUCT_BLUH, $arg1 );
   }
}

$obj = Foo::getBlah( 'blah' );
$obj = Foo::getBleh( 'bleh' );
$obj = Foo::getBluh( 'bluh' );

?>

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

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






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

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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux