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: 472

Filed under:
|
|

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:

  1. Doers can be created without its preconditions being satisfied
  2. The code isn't easily testable because ConnPool can't be directly mocked out.
  3. 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.
  4. In the event of threads, the above becomes more complicated by adding locking
  5. Globals aren't being used to communicate state (which isn't strictly bad, but a code smell)

On the other hand, some pros:

  1. its very convenient to call Init(5, "user/pass", 2, "user/pass")
  2. 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

Related posts about design

Related posts about design-patterns