On 24 March 2010 16:23, Robert Cummings <rob...@interjinn.com> wrote:
> Peter Lind wrote:
>> On 24 March 2010 16:09, Robert Cummings <rob...@interjinn.com> wrote:
>>> Peter Lind wrote:
>>>> On 24 March 2010 15:33, Robert Cummings <rob...@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.

Yes, you have to keep track of two different objects instead of one.
Managing complexity by delegating responsibility is normally a good
thing. And no, there is no confusion: you're building the same object
in different ways, so you're getting the same object, not one that
merely looks the same. As for abusing class semantics ... I don't see
it. Using separate classes for different things is what OOP is about.
If your constructor is trying to do 15 different things you're
designing it wrong - methods shouldn't have to rely upon massive
switches or the equivalent done using foreach loops and arrays.
 As for more documentation: You'd have two class docblocks plus a
docblock for each build method, so I suppose you're right, that is one
extra docblock.

>> 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.

Yes. What does your code look like? One big file containing everything?

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

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51

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

Reply via email to