Re: Properly handling multiple constructors.

Peter Lind wrote:

On 24 March 2010 16:09, Robert Cummings <robert@interjinn.com> wrote:

Peter Lind wrote:

On 24 March 2010 15:33, Robert Cummings <robert@interjinn.com> wrote:

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.

Only problem is the OP wanted to be able to created objects with variable amounts of arguments. I.e. passing just one argument to the constructor wasn't an option, far as I could tell. That's why he was looking at c++/c# overloading: creating a constructor for each scenario because the amount and kind of arguments varied. Which means that the docblock for your constructor will look something like /** * dynamic constructor * * @param int $constructor_type * @param string|array|object|whatever_you_could_think_to_throw_at_it $something * @param string|array|object|whatever_you_could_think_to_throw_at_it $something this is optional * @param etc * * @access public * @return void */

Actually, I would write it more like the following:

/** * dynamic constructor that delegates construction and parameters to a * registered alternate constructor. See specific constructors for * supported parameters. * * @param int $constructor_type * @param mixed $param,.... * * @access public * @return void */

The ,... is a supported syntax. Then I'd add the appropriate docblock for the alternate constructors.

It might be but in effect the documentation you're left with is vague and has double the amount of documentation lookups, to find out which parameters you can pass. Using a separate object to create the one you want avoids this.

But then you need to keep track of many different classes/objects rather than a single. You also run into confusion as to what the difference is when really they are the same, just built differently. In this context you have even more document points to review since you must read the class information in addition to the method signature. Also using a separate class just to facilitate a different constructor seems abusive of class semantics since the objects are intended to be identical, just built differently. I would find this more unwieldy to deal with in an environement than just viewing the alternate methods.

However, which solution fits the problem best is determined by the angle you're looking from. If you want to avoid extra classes, having a constructor like you're supposing is probably the best idea.

Extra classes is also more code, probably more files (if you put them in separate files), more points of management. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP