Re: Properly handling multiple constructors.

Peter Lind wrote:

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.

Absolutely, delegating responsibility to manage complexity is very good. My proposed solution does this.

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.

No, you're getting different objects. If they come from different classes then they are different. Yes they may be subclasses, but the OP indicated they differ only by how they are built. Adding 10 different subclasses just to facilitate constructor overloading seems egregious, especially if the object already has logical subclasses.

    class Dog
    class Dog_construct1 extends Dog
    class Dog_construct2 extends Dog
    class Dog_construct3 extends Dog
    class Dog_construct4 extends Dog

    class Dalmation extends Dog
    class Dalmation_construct1 extends Dog_construct1
    class Dalmation_construct2 extends Dog_construct2
    class Dalmation_construct3 extends Dog_construct3
    class Dalmation_construct4 extends Dog_construct4

But now Dalmation_construct1 isn't related to Dalmation... or do you propose the following:

    class Dalmation extends Dalmation
    class Dalmation_construct1 extends Dalmation
    class Dalmation_construct2 extends Dalmation
    class Dalmation_construct3 extends Dalmation
    class Dalmation_construct4 extends Dalmation

But now Dalmation_construct1 isn't related Dog_construct1. This seems problematic from a design perspective unless I'm missing something in your proposal. 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.

Sorry, switches, foreach, and isset are not equivalent. My approach is O( lg n ). Foreach and switches are O( n ) to find a candidate. Additionally, my constructor does 1 thing, it delegates to the appropriate constructor which does one thing also... builds the object according to intent.

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?

No, I said probably because I put classes in separate files. I was saying there is probably another added maintenance headache of all these new class files. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP