What makes static initialization functions good, bad, or otherwise?
Posted
by Richard Levasseur
on Stack Overflow
See other posts from Stack Overflow
or by Richard Levasseur
Published on 2010-04-07T01:57:18Z
Indexed on
2010/04/07
2:03 UTC
Read the original article
Hit count: 506
Suppose you had code like this:
_READERS = None
_WRITERS = None
def Init(num_readers, reader_params, num_writers, writer_params, ...args...):
...logic...
_READERS = new ReaderPool(num_readers, reader_params)
_WRITERS = new WriterPool(num_writers, writer_params)
...more logic...
class Doer:
def __init__(...args...):
...
def Read(self, ...args...):
c = _READERS.get()
try:
...work with conn
finally:
_READERS.put(c)
def Writer(...):
...similar to Read()...
To me, this is a bad pattern to follow, some cons:
Doer
s can be created without its preconditions being satisfied- The code isn't easily testable because ConnPool can't be directly mocked out.
Init
has to be called right the first time. If its changed so it can be called multiple times, extra logic has to be added to check if variables are already defined, and lots of NULL values have to be passed around to skip re-initializing.- In the event of threads, the above becomes more complicated by adding locking
- Globals aren't being used to communicate state (which isn't strictly bad, but a code smell)
On the other hand, some pros:
- its very convenient to call
Init(5, "user/pass", 2, "user/pass")
- It simple and "clean"
Personally, I think the cons outweigh the pros, that is, testability and assured preconditions outweigh simplicity and convenience.
© Stack Overflow or respective owner