Strategies for controling attribute assignment

Steve Holden sholden at holdenweb.com
Tue Oct 2 10:46:34 EDT 2001


"Dale Strickland-Clark" <dale at riverhall.NOSPAMco.uk> wrote in message
news:l1gjrtsru6nual0ress6vqp70s044u38ij at 4ax.com...
> "Steve Holden" <sholden at holdenweb.com> wrote:
>
> >"Dale Strickland-Clark" <dale at riverhall.NOSPAMco.uk> wrote in message
> >news:9lajrtcqsojv72nr88c7j6kmdapjo44vc0 at 4ax.com...
> >> A 'properly' encapsulated business class tends to involve methods and
> >> attributes. However, managing attribute assignment gets very messy
> >> with __setattr__ as you need to devise a scheme to distinguish class
> >> attributes and working instance variables.
> >>
> >> Often, externally visible class attributes need to be validated and
> >> instance variables don't. Or they may get stored elsewhere.
> >>
> >> What strategies have people come up with to manage this distinction
> >> without bogging the code down in excessive checks.
> >>
> >> I would really like a way to distinguish between these two without
> >> having to check dictionaries.
> >>
> >Dale:
> >
> >I'm not quite sure what problem you are trying to solve here. Are you
> >suggesting that your code will change some class attributes and some
> >instance attributes to parameterize the operation of all instances for a
> >particular context. Maybe I need another cup of coffee ...
> >
> >Well, the coffee was a good idea. Your problem is that when you *use*
> >__setattr__ you need to know whether you are setting a class or an
instance
> >variable, right? And you want to set class attributes from inside
methods?
> >
> >Perhaps you'd explain what you mean by "proper" encapsulation is a
problem
> >in your particular context. I'm presuming that you are working in a COM
> >environment, but of course I've been wrong before...
> >
> >regards
> > Steve
> >
> >PS: See recent thread on not hiding your email address from spam!
>
> I thought this might be difficult to convey. This is typical of the
> approach I'm currently using:
>
> def __setattr__(self, field, value):
> if self._dbTable.has_key(field):
> self._dbTable[field].validate(value)
> self._fields[field] = value
> self._saved = 0
> else:
> self.__dict__[field] = value
>
> I have to distinguish between assignments to 'public' attributes
> (which will go in my database) and instance variables which are used
> throughout the class. I need to validate assignments to the database
> but just let everything else through.
>
> But it means that EVERY internal assignment to instance attributes
> needs to go through this code.
>
> I guess what I'm after is a distinction between private and public
> attrbutes.
>
> Does that make it any clearer?

I think so. For a start it appears to mean that we can forget all about
class attributes ...

I'm not sure why using a dictionary appears so evil to you, given that you
seem to need the dictionary for field validation anyway. Two possible
simplistic alternatives suggest themselves immediately, which might be
enough to loosen your thinking and give you a better solution for your
needs.

1. Use names with a special prefix for the database fields, then you can
just test the attribute name using beginswith() or similar to determine
whether it's a database filed.

2. Have objects store database fields inside another object (such as a
DatabaseTuple), so instead of assigning

    object.dbfield = value

you assign

    object.db.field = value

This localises the database fields and means you don't need __setattr__ on
the object itself.

Of course there may well be valid reasons why neither of these approaches is
satisfactory. Explain why not, and others might well have better
suggestions.

regards
 Steve
--
http://www.holdenweb.com/








More information about the Python-list mailing list