On 24 March 2010 16:48, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > 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. As I suspected, you didn't understand what I meant. The builder pattern lets you build complex objects in steps, separating out complexity. It's equally well suited to building one object as many objects and what I had in mind was a simplified builder/factory. Which means you have: class ObjectBuilder class Object where ObjectBuilder comes with several different ways of building Object. That's two objects, not the list of objects extending something you posted. > 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. Yes, your constructor does one thing, which is indirectly related to constructing instead of carrying out the actual constructing. I prefer constructors to construct something, but that's a matter of preference I expect. >> 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. There would be if one were to use your scheme of subclassing. What I proposed doesn't do that in any way, so there's not much of a maintenance headache. Anyway, all this is theoretical seeing as you can equally well use a set of static methods on the object to achieve the creation (the only difference to what I proposed is which class the constructing methods are in) and that solution seems to suit the OP. > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > -- <hype> 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 </hype> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
