Prev: JUST TAKE 1 MIN ADD .AND GET 10 $ PER ADD $ 50 % OF THE REF.....ITS FREE
Next: cPickle error when caching data
From: wheres pythonmonks on 3 Aug 2010 08:46
Hi!

I have a class (supposed to be an abstract base class):
In python (as opposed to static languages like C++) I don't seed to
subclass the base class, but instead I can simply override the
behavior of stub methods and values.
Is there a preference between between subclassing (C++ approach) and
overriding methods/data in an instance? From a design perspective?
I think I prefer the override/redefine approach because it result in a
thinner class hierarchy.

It seems like inheriting an ABC is needed only when I must share
instances (between multiple parts of the code, or if the subclass is
instantiated in different places...)

Thoughts?

W
From: Roald de Vries on 3 Aug 2010 10:06
On Aug 3, 2010, at 2:46 PM, wheres pythonmonks wrote:
> Hi!
>
> I have a class (supposed to be an abstract base class):
> In python (as opposed to static languages like C++) I don't seed to
> subclass the base class, but instead I can simply override the
> behavior of stub methods and values.
> Is there a preference between between subclassing (C++ approach) and
> overriding methods/data in an instance? From a design perspective?
> I think I prefer the override/redefine approach because it result in a
> thinner class hierarchy.
>
> It seems like inheriting an ABC is needed only when I must share
> instances (between multiple parts of the code, or if the subclass is
> instantiated in different places...)
>
> Thoughts?

1) some things are just not possible in instances, like overriding
operators
2) abstract base classes are not supposed to be instantiable, so if
you are able to do it anyway, that is a hack
3) adding stuff to instances is less reusable that adding stuff to
(sub)classes
4) if I'm reading your code and want to know what an object is like, I
look at the class, not through your whole program to collect all bits
and pieces of information spread out over it
5) why would you want a thinner class hierarchy?

So I would go for inheritance.

Cheers, Roald

From: wheres pythonmonks on 3 Aug 2010 10:38
Roald:

First, I must admit, I didn't know I could create an ABC in python.
Now I see (http://docs.python.org/library/abc.html). Thank you.

I think that the crux of the matter is in points #3, #4, and #5 that
you raised:

3) adding stuff to instances is less reusable that adding stuff to (sub)classes
4) if I'm reading your code and want to know what an object is like, I look
at the class, not through your whole program to collect all bits and
pieces of information spread out over it

On #3: Not clear that all possible specializations warrant
factorization into a class. Indeed, this may result in "premature
abstraction" -- and make the code less clear. Also, it will freeze in
the base classes, making future refactoring a headache.

On #4: Unless I misunderstood something, there is nothing in python
that ensures that a class definition is localized. So, putting
definitions in classes, does not guarantee that the definition is at a
single location in the code.

5) why would you want a thinner class hierarchy?

The yo-yo anti-patten:
http://en.wikipedia.org/wiki/Yo-yo_problem

I have a pretty strong preference for using a small number of useful
objects, instead of having code littered with objects strewn across
the namespace.

Maybe there is a Python ABC tutorial out there that can enlighten me?

W

On Tue, Aug 3, 2010 at 10:06 AM, Roald de Vries <downaold(a)gmail.com> wrote:
> On Aug 3, 2010, at 2:46 PM, wheres pythonmonks wrote:
>>
>> Hi!
>>
>> I have a class (supposed to be an abstract base class):
>> In python (as opposed to static languages like C++) I don't seed to
>> subclass the base class, but instead I can simply override the
>> behavior of stub methods and values.
>> Is there a preference between between subclassing (C++ approach) and
>> overriding methods/data in an instance?  From a design perspective?
>> I think I prefer the override/redefine approach because it result in a
>> thinner class hierarchy.
>>
>> It seems like inheriting an ABC is needed only when I must share
>> instances (between multiple parts of the code, or if the subclass is
>> instantiated in different places...)
>>
>> Thoughts?
>
> 1) some things are just not possible in instances, like overriding operators
> 2) abstract base classes are not supposed to be instantiable, so if you are
> able to do it anyway, that is a hack
> 3) adding stuff to instances is less reusable that adding stuff to
> (sub)classes
> 4) if I'm reading your code and want to know what an object is like, I look
> at the class, not through your whole program to collect all bits and pieces
> of information spread out over it
> 5) why would you want a thinner class hierarchy?
>
> So I would go for inheritance.
>
> Cheers, Roald
>
>
From: Roald de Vries on 3 Aug 2010 11:31
Hi W,

On Aug 3, 2010, at 4:38 PM, wheres pythonmonks wrote:
> I think that the crux of the matter is in points #3, #4, and #5 that
> you raised:

I think #2 is important too: a program is supposed to do what you
expect, and I don't expect instantiation of an ABC.

> On #3: Not clear that all possible specializations warrant
> factorization into a class. Indeed, this may result in "premature
> abstraction" -- and make the code less clear. Also, it will freeze in
> the base classes, making future refactoring a headache.

I agree (for small specializations only).

> On #4: Unless I misunderstood something, there is nothing in python
> that ensures that a class definition is localized. So, putting
> definitions in classes, does not guarantee that the definition is at a
> single location in the code.

That's right, but with classes it is possible (and encouraged) to keep
things in a single location. The other option necessarily puts things
where I don't expect them.

> 5) why would you want a thinner class hierarchy?
>
> The yo-yo anti-patten:
> http://en.wikipedia.org/wiki/Yo-yo_problem
>
> I have a pretty strong preference for using a small number of useful
> objects, instead of having code littered with objects strewn across
> the namespace.

I see the point, but I would like to remark that if a program does
what you expect, you won't need to understand the whole inheritance
graph.

> Maybe there is a Python ABC tutorial out there that can enlighten me?

http://docs.python.org/library/abc.html
http://www.doughellmann.com/PyMOTW/abc/

Cheers, Roald

PS: most people in this list prefer not top posting

 | 
Pages: 1
Prev: JUST TAKE 1 MIN ADD .AND GET 10 $ PER ADD $ 50 % OF THE REF.....ITS FREE
Next: cPickle error when caching data