Design Problems with Singletons

Following is a design guideline for implementing the Singleton design pattern. This guideline is composed using some key computer science principles such as the Single Responsibility Principle, Liskov Substitution Principle, Dependency Inversion Principle, and KISS.

1. There must be one and only one instance of this class. For example, there is one and only one instance of an application. Even in this case, Singleton pattern is not recommended. If there are two modes of this applications, polymorphism will be hard to use when using an Application Singleton. In this case, it is a mere coincidence that we need one instance of this object, but not a design requirement.
2. This instance must never die. This means that this particular class needs to stay alive until the end of application life cycle.
3. Creation of this object has to be done in a lazy way. This means that the application doesn’t care about when this object is created.
4. This object must be responsible for creating itself. There are risks associated with coupling creation and business implementation of an object. This has to be judged carefully.
5. This class will dispose of any unmanaged resources in a manual way. Since an instance of this class will be created lazily, but it will stay alive until the end of application life cycle, it has to dispose of unmanaged resources such as WCF channels, file and memory streams, etc. right after it is done using them.
6. There will never be a need to create Mock and Dummy objects of this type. Singletons make testing difficult, and sometimes impossible. For example, Logger.Instance singleton cannot be substituted with a mock object because it creates itself.
7. It is understood that this class will implement some thread safety since it could be accessed by a number of threads in the application.

There are ways of implementing the Singleton pattern with less code duplication and without violating the principles state above. The Dependency Injection pattern can be used to do this. Create a Dependency Injector (there are some open source options such as Unity, Ninject for .NET) to enforce the Singleton pattern. This way, the Singleton creation is defined only once in one place rather than in all classes via copy/paste.

Concepts of Continuous Integration

Thanks to advances in Test Driven Development, software testing has become an important subject of discussion. Test Driven Development (TDD) is incorporated in the software engineering process of many organizations. Discussions about using specific open source, free and commercial products to accomplish testing can be found all over the web. I think that test driven development can and should be a part of any product/project development life cycle from start to end. Speficically, I want to discuss my experiences with testing and how it has helped me weave quality directly into the sofware development process.

Sad reality is that waterfall software development process still dominates the industry. Activities are seen as tasks being performed by disconnected teams. I was a software developer for 2 years until I was introduced to Test Driven Development. Testing is regarded as an activity that happens in short intervals during the software development process. Following diagram demonstrates what software development and quality control activities look like in a waterfall software development process.

Figure above demonstrates how the development process starts and how it degrades over time. First development activity has the highest number of lines of code checked in. All the initial plumbing of integrating logging, validation, user interface design abstractions, etc. are checked in. This build has very minimal business logic, but it has an architecture that will support the business logic in the later builds. As you can see, the development group hands over the software to the testing group. Testing activity is significantly smaller and smoother at this stage. There are very few business rules to test, if any at all. However, as new builds are made, the testing activity gets longer and longer. In this world of no unit tests, there is no guarantee that new code will not break any existing code. It becomes testing teams responsibility to ensure that all rules are being obeyed. This model is clearly unstable. Software that was originally being designed becomes a mirage of some sort. The harder the software development team tries to accomplish their goals, it creates more problems. Sometimes, these problems are simple and easy bug fixes, sometimes they are so hard to duplicate that they are regarded as 'low risk known bugs'. It looks something like this..

The red graph above shows a project without any tests. The green graph shows a project with test driven development and continuous integration. As you can see, the red graph is doing very well, it was able to introduce a lot more features than the green graph in a shorter period of time in the beginning of the project. However, as the project rolled along, finding and fixing bugs overtook the development activity. The project without test driven planning became overwhelmed with bug fixing that new features were put on hold, delayed or cancelled due to lack of time and budget. The green graph here kept going at a continuous velocity and was able to meet the end result even though it seemed like it had a slow start.

In the next few posts, I would like to demonstrate how testing can be integrated in software development. I would like to discuss different types of testing techniques such as:

• Integration testing
• System testing
• System integration testing
• Regression testing
• Acceptance testing
• Functional testing
• Non-functional testing