title: Refactoring Singleton Overuse
body: <p>Today I had an epiphany, and it was that I was doing everything wrong. Some history: I inherited a C# application, which was really just a collection of static methods, a completely procedural mess of C# code. I refactored this the best I knew at the time, bringing in lots of post-college OOP knowledge. To make a long story short, many of the entities in code have turned out to be Singletons.</p>
  
  <p>Today I realized I needed 3 new classes, which would each follow the same Singleton pattern to match the rest of the software. If I keep tumbling down this slippery slope, eventually every class in my application will be Singleton, which will really be no logically different from the original group of static methods.</p>
  
  <p>I need help on rethinking this. I know about Dependency Injection, and that would generally be the strategy to use in breaking the Singleton curse. However, I have a few specific questions related to this refactoring, and all about best practices for doing so.</p>
  
  <ol>
  <li><p>How acceptable is the use of static variables to encapsulate configuration information? I have a brain block on using static, and I think it is due to an early OO class in college where the professor said static was bad. But, should I have to reconfigure the class every time I access it? When accessing hardware, is it ok to leave a static pointer to the addresses and variables needed, or should I continually perform <code>Open()</code> and <code>Close()</code> operations?</p></li>
  <li><p>Right now I have a single method acting as the controller. Specifically, I continually poll several external instruments (via hardware drivers) for data. Should this type of controller be the way to go, or should I spawn separate threads for each instrument at the program's startup? If the latter, how do I make this object oriented? Should I create classes called <code>InstrumentAListener</code> and <code>InstrumentBListener</code>? Or is there some standard way to approach this?</p></li>
  <li><p>Is there a better way to do global configuration? Right now I simply have <code>Configuration.Instance.Foo</code> sprinkled liberally throughout the code. Almost every class uses it, so perhaps keeping it as a Singleton makes sense. Any thoughts?</p></li>
  <li><p>A lot of my classes are things like <code>SerialPortWriter</code> or <code>DataFileWriter</code>, which must sit around waiting for this data to stream in. Since they are active the entire time, how should I arrange these in order to listen for the events generated when data comes in?</p></li>
  </ol>
  
  <p>Any other resources, books, or comments about how to get away from Singletons and other pattern overuse would be helpful.</p>