in reply to Constructor/Factory Orthodoxy

Is there any particular reason why having a constructor serve a dual role as a factory is a bad idea?

It's largely a matter of convention and expectation. When I write 

   my $frob = new Frob();

[download]
I expect to get a Frob, and future readers of the code might reasonably expect that $frob will hold an instance of Frob. But if I write 
    my $frob = Frob::makeFrob();

[download]
there is no such assumption. Nobody is misled. At most, the assumption is that $frob will get a Frob or a subclass of Frob.

Having new work consistently 99% of the time is a bad thing. It lulls people into traps.

Replies are listed 'Best First'.
Re: Re: Constructor/Factory Orthodoxy
by mojotoad (Monsignor) on Feb 26, 2003 at 00:22 UTC
    I'm not here to defend the name "new()" as a factory (I'm not really here to defend anything -- I'm here to learn).

    Symantically, of course, what you say makes sense -- so let's say I call the factory "Bubba::makeBubba". What then of my example? What do you call it, etc? (we can assume that there's also a new() which boostraps from makeBubba() )

    My main question, which I fear was obscured by my reference to a dual-function constructor, concerned this notion of returning subclasses based on parameters vs instantiating the subclasses directly (programmer's choice). In so doing, I was happy to utilize an inheritable constructor as well. (regardless of where the factory method might reside)

    Thanks,
    Matt

[reply]
      Let's say I call the factory "Bubba::makeBubba". What then of my example? What do you call it, etc?

      I'd pick a name that expresses the intent of the operation. "makeBubba" might be fine. "makeBubbaMeal" might be better. It depends on what your example would look like fully fleshed out.

[reply]
(Re:)+ Constructor/Factory Orthodoxy
by rir (Vicar) on Feb 26, 2003 at 22:38 UTC
    When I write my $frob = new Frob (); I expect to get a Frob,

    So do I! What I am more confused about is: Why I should reject a member of Sub_class_of_Frob as not a Frob?

    Too much Perl. Not enough theory or practice with another language to broaden my mind.

[reply]
[d/l]
[select]
      Why I should reject a member of Sub_class_of_Frob as not a Frob?

      Because it violated the expectation I had that 

          my $from = new Frob();

      [download]
      would give me a Frob, not something that is a specialization of a Frob. One can argue about whether new warrants that expectation, but precendent across programming lanaguages does lean strongly that way.

[reply]
[d/l]
[select]
        You are right that common usage in popular OO languages leans that way. As I stated I tend have that expectation myself. However:

        Can an abstract class not have a constructor?

        Should a subtype be able to be substituted for a supertype in any situation?

        Should I be concerning myself with my object's concrete type on the typical constructor call?

        When I consider these questions I wonder about the validity of my initial expectation.

        It depends on what the meaning of the word 'isa' is.

        Regarding: 

        my $frob = new Frob();

        [download]
        I have a greater expectation, in Perl, that Frob() is a routine call returning something here. That bothers me. This seems a very queer, obstrusive, distracting use of extraneous parentheses.

[reply]
[d/l]
[select]

In Section Meditations