[ZODB-Dev] SecureServerStorage and SecureClientStorage

[Toby Dickenson]

On Saturday 05 Oct 2002 8:55 am, Guido van Rossum wrote:
> > > Hm, maybe we should adopt as general principle that whenever a clas=
s
> > > instantiates another class (and we think it might be useful to
> > > subclass that class to provide additional functionality), it doesn'=
t
> > > use that other class directly, but uses a reference to that class
> > > stored on the current class.
> >
> > Over the last few months I have been refactoring one of our internal
> > projects that used to use this idiom. One problem is that you often
> > have to create more derived classes than you might think is
> > necessary; the purpose of the extra classes is solely to change the
> > type of the classes it creates.
>
> That's true.  Does this mean you no longer like this idiom?  Do you
> have an alternative? =20

Suppose instances of class X have instances of class Y as an attribute. X=
=20
creates an instance of class Z to do some work on Y. Your suggested idiom=
=20
(and the one we have recently abandonned) is that X holds the concrete ty=
pe=20
of Z because X creates Z. The right answer might be as simple as choosing=
 the=20
concrete type in Y rather than X

> Passing all the classes (better: factories) in
> to the constructor isn't a great solution either,

Or, in some cases, some other method

> But this
> depends on how many classes you want to replace, and whether those
> classes are conveniently available at the abstraction level where the
> constructor is called.

Yes, Im not sure how this all fits in to ZEO.