Steven D'Aprano a écrit :
On Mon, 22 Sep 2008 10:11:58 +0200, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
I have a class which is not intended to be instantiated. Instead of
using the class to creating an instance and then operate on it, I use
the class directly, with classmethods. Essentially, the class is used
as a function that keeps state from one call to the next.
The problem is that I don't know what to call such a thing! "Abstract
class" isn't right, because that implies that you should subclass the
class and then instantiate the subclasses.
What do you call such a class?
<nitpick>
Err... A possible design smell ?-)
</nitpick>
More seriously: this looks quite like a singleton, which in Python is
usually implemented way more simply using a module and plain functions.
I really don't know why everyone thinks I want a Singleton.
May I quote you ?
"""
Instead of using the class to creating an instance and then operate on
it, I use the class directly, with classmethods. Essentially, the class
is used as a function that keeps state from one call to the next.
"""
I want to
uncouple objects, not increase the coupling.
Consider a factory function:
def factory(x): # a toy example
alist = [x]
def foo():
return alist
return foo
Now suppose we "instantiate" the factory (for lack of a better term):
f1 = factory(0)
f2 = factory(0)
Even though f1 and f2 have the same behaviour, they are obviously not the
same object. And although both return a list [0], it is not the same list:
f1() == f2() == [0]
True
f1() is f2()
False
>
They have a (very little) amount of state, which is *not* shared:
L = f1()
L.append(1)
f1()
[0, 1]
f2()
[0]
But there's only a limited amount of state that functions carry around. I
can give them more state like this:
f1.attr = 'x'
but it isn't good enough if the function needs to refer to it's own
state, because functions can only refer to themselves by name and the
factory can't know what name the function will be bound to.
Then define your own callable type.
As far as I know, the only objects that know how to refer to themselves
no matter what name they have are classes and instances. And instances
share at least some state, by virtue of having the same class.
Is that a problem in your use case, and if so, why ???
(Pedants will argue that classes also share state, by virtue of having
the same metaclass. Maybe so, but that's at a deep enough level that I
don't care.)
I'm now leaning towards just having factory() instantiate the class and
return the instance, instead of having to do metaclass chicanery. Because
the class is built anew each time by the factory, two such instances
aren't actually sharing the same class. I think that will reduce
confusion all round (including mine!).
Hopefully now that I've explained what I want in more detail, it won't
seem so bizarre. Factory functions do it all the time. Is there a name
for this pattern?
Thanks to everyone who commented, your comments helped me reason out a
better alternative to what I first suggested.
Glad to know you found something helpful in all these answers, but as
far as I'm concerned, I'm afraid I still fail to understand what exactly
you're after...
--
http://mail.python.org/mailman/listinfo/python-list
