OO conventions

[Nicola Musatti]

I V wrote:
> Nicola Musatti wrote:
[...]
> > 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?

I didn't express my intent clearly. I agree that in general your second
example is to be preferred to the first one. In fact the only reason I
could think of using the first scheme is when the second would lead to
Klass's __init__ method having a large number of parameters.

What is important to me is to keep your get_initial_data() function
outside Klass if it's task is non trivial, e.g. it has to interact with
the OS or a DB.

Cheers,
Nicola Musatti