[Edu-sig] Re: Design Pattern question

[Kirby Urner]

> In the situation you describe I've taken several tactics.  One is to
> have a *single* global object to store preferences or other shared
> state.  Another is to pass the shared state around in one object that
> various parts of the system all have access to.
>

I've sort of gone with the single global object, but it's not really global,
it's an object in the base class which only the object's children
(subclasses) share and communicate through.

> And the Extreme Programming folks would preach YAGNI (You Ain't Gonna
> Need It).  There is a perception that globals are evil and should never
> be used, but a) python's namespaces already help protect from the worst
> aspects of globals (most 'globals' are really module-local), and b) if
> a program is small or one-off it doesn't make sense to overdesign it
> just to remove globals that won't effect anything.

Yes, globals and side effects are supposedly evil.  But then class methods
and variables are supposedly *not* evil.  So by making my "globals" live in
the mind of the parent class, I'm really just exploiting the power of
inheritance.

> My first drafts of programs are often littered with globals.  When I
> have a working version and want to add more utility, or reuse bits in
> another program, or find it growing to the point that the globals are
> getting in the way, I refactor them into a single object and use it as
> above.  But only after I find myself returning to the program again and
> again, so that I know the effort will be worth it.
> 
> --Dethe

A good strategy.  Don't waste a lot of time polishing one-off code (or even
infrequently needed code) to make it text book perfect.  Life is short.

Kirby