OO conventions

I V wrongbad at gmail.com
Fri Feb 3 14:09:28 EST 2006


Nicola Musatti wrote:
> I don't think this is all there is to it. Even though a class such as
> Image might not have a sensible default, initial state it still might
> not be reasonable to burden it with the ability to collect the
> information needed to reach such an initial state. To put it it another
> way: a car is a car, it isn't a car factory.

What's the "burden", though? Surely the only burden is that the class
needs to take the relevant parameters to its __init__ method, which is
no more of a burden than providing some other initialization method
that takes the relevant parameters.

> Factory functions (or classes) are there to solve this problem and
> still allow a clean separation of concerns. Although instances of Klass
> are created uninitialized, they only live in this state within their
> factory and only reach trhe outside world only when they are in a
> usable state.

This may be my limited imagination, but I can't think of a situation
when you would prefer something like:

def factory(info):
    k = Klass()
    data = get_initial_data(info)
    k.set_data(data)
    return k

to:

def factory(info):
    data = get_initial_data(info)
    return Klass(data)

What would be the value of doing the initialization in a separate
method, rather than the constructor?




More information about the Python-list mailing list