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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
