Create an object based on different criteria

NogDog

I want to create an object, but depending on the situation, I might want to populate it based on a single parameter, or else based on two totally different parameters. As I have some time to do this "right", I'm wondering what might be considered the best practice(s) for this situation. One approach I'm not too crazy about:

public function __construct(PDO $pdo, $id=null, $arg1=null, $arg2=null)
{
    if(!empty($id)) {
        // populate $this by ID
    }
    elseif(!empty($arg1) and !empty($arg2)) {
        // populate $this by those 2 args
    }
    else {
        // probably throw an exception?
    }
}

Another approach, also one I'm not crazy about, is providing 2 different "populateBySomething()" methods you would call after first creating the (empty) object.

And then there are random neuron firings with vague thoughts about using some sort of Factory for this? Or make them into different classes extending an abstract class or implementing an interface?

I'm thinking the "best" solution is probably the one I haven't thought of yet in my current state of sleep deprivation.

laserlight

NogDog wrote:
One approach I'm not too crazy about:

This is fine to me, except that I think it works best with keyword/named arguments, which I believe PHP still does not allow.

NogDog wrote:
Another approach, also one I'm not crazy about, is providing 2 different "populateBySomething()" methods you would call after first creating the (empty) object.

I don't like two stage construction, so I would not go for this.

I think the old way of having two constructors with differing parameters would work well, but these days the unified __construct constructor is conventional. Therefore, one approach could be to have this single constructor, but make it protected. Then, have two public class methods, e.g., createByFoo and createByBar with only the necessary parameters, and that invoke this constructor with the appropriate arguments so as to create the object populated in the desired way.

Weedpacket

laserlight wrote:
Then, have two public class methods, e.g., createByFoo and createByBar with only the necessary parameters, and that invoke this constructor with the appropriate arguments so as to create the object populated in the desired way.

So you're giving the class factory methods. That way leads the abstract factory: our class here has one constructor with one fixed list of parameters; one of those parameters takes a factory object implementing an interface our class can use; different sets of "populate by" arguments would be implemented by passing instances of different classes of factory object - one constructed by ID, one constructed by these two args, etc.

laserlight wrote:
...keyword/named arguments, which I believe PHP still does not allow.

Maybe in 5.7 or so (I think it missed out on being in 5.6). That RFC mentions a current-version approximation that I sometimes use (and why it's not ideal).

NogDog

laserlight;11040395 wrote:
...Therefore, one approach could be to have this single constructor, but make it protected. Then, have two public class methods, e.g., createByFoo and createByBar with only the necessary parameters, and that invoke this constructor with the appropriate arguments so as to create the object populated in the desired way.

Hmm...this sounds interesting. So similar to the Singleton pattern, except we're not making it a singleton, and the createBy*() methods would be static, returning the new object, right? Definite food for thought.

Thanks!

laserlight

Weedpacket wrote:
So you're giving the class factory methods.

Yes, simple factory, perhaps in its simplest form because only one concrete class is involved with no (abstract) base class. In C++, we would call this the named constructor idiom.

Weedpacket wrote:
That way leads the abstract factory: our class here has one constructor with one fixed list of parameters; one of those parameters takes a factory object implementing an interface our class can use; different sets of "populate by" arguments would be implemented by passing instances of different classes of factory object - one constructed by ID, one constructed by these two args, etc.

Possible over-engineering :p

NogDog wrote:
the createBy*() methods would be static, returning the new object, right?

Yes.

Bonesnap

I don't mind your first example as long as there's a reasonable number of arguments. Once the number of arguments becomes unreasonable, then I would break it into two different classes probably. Not sure about a common parent class; I guess it would depend on the situation and how similar the child classes are at that point.

NogDog

Bonesnap;11040421 wrote:
I don't mind your first example as long as there's a reasonable number of arguments. Once the number of arguments becomes unreasonable, then I would break it into two different classes probably. Not sure about a common parent class; I guess it would depend on the situation and how similar the child classes are at that point.

That would actually be the only difference: everything about the class would be the same, it's just two different contexts in which it might be used (whether the client code is aware of the unique ID of the (D😎 object in question, or if it knows the other distinct criteria that define that object.

Funny thing is, though, that as I think about this more, I'm not sure the latter case would ever actually be needed -- or at least not to the point where it limits it to just one of these "things" -- so now I'm wondering if I really even need to worry about this. Either way it's a win for me, though: either I have a workable solution, or I have determined it's a solution without a problem. 🙂

Weedpacket

laserlight wrote:
Possible over-engineering

Quite possible, yes 🙂 Now if there were three or four ways of defining the thing with the chance of more to come... (Hmm.... if the different possible instantiations could be derived from a description of candidate keys... Hey, that would be an abstract factory factory and we might as well be working in Java.)