Click here to Skip to main content
Click here to Skip to main content

My Personal and Also Another Approach to Handling the Singleton Design Pattern

, 14 Sep 2007
Rate this:
Please Sign up or sign in to vote.
Quick and simple use of the singleton design pattern

Introduction

I wanted to have my own and simple handling for the singleton design pattern without implementing it many times. Singleton is an object-based creation pattern. You should implement it to ensure that only one instance of a class exists to have a global access point.

I often used the singleton design pattern to hold the settings of a configuration file. However, I had to implement the pattern every time and sometimes I had to write a method for initializing some variables of the instance, as well as implement a check to watch for instance initialization. I needed a quick and simple way to use the singleton design pattern... And here comes my approach to solving this.

Using the Code

I delegated creation and initialization of the singleton class instance to a generic builder class called UZi.Singleton.SingletonBuilder<T>. See more details in my source code. You can (and should) check the arguments for the constructor of your singleton class with the delegate UZi.Singleton.SingletonClassConstructorArgsChecker. Now you can write code like this, if x is a defined class:

x singletonInstanceOfX = UZi.Singleton.Singleton<x>, 
    UZi.Singleton.SingletonBuilder<x>.GetInstance(
    UZi.Singleton.SingletonClassConstructorArgsChecker
    )someMethodToCheckArgsForTheSingletonClassCtor, 
    new object[] { 1, "string_value" });

You can now use singletonInstanceOfX everywhere in your application and you only ever have this one instance of x. Don't forget to make the constructor of your class, which should be a singleton class, private or protected!

Points of Interest

With my approach, you can simply use the singleton design pattern. You'll never have to implement it for a class serving as a singleton instance. We also never have to implement a builder class to build an initialized instance of our singleton class. Use the generic code and save time.

History

  • 2007-09-12: First version
  • 2007-09-12: Tried to fix some formatting mistakes

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

SaxoniaCoder
Web Developer
Germany Germany
.NET Professional: 'specialist for application development' (a german job title)
 
I normally develop applications in C# with the .net-framework 2.0+/3.0 and currently databases for MS Sql Server 2005 and MS Access 2003+.
 
I'm an employee of an office which is working for insurances and which is watching investigations of damages for incorrect items, plausibility and so on and my job is to develop software to automate these processes. I developed for example an application which can extract values from ocr-texts using regular expressions and save these values into a database for later calculations or other processes.

Comments and Discussions

 
GeneralFurther reading PinmemberPeter Ritchie17-Sep-07 9:59 
GeneralThanks for your contribution Pinmemberjonnii12-Sep-07 6:31 
AnswerRe: Thanks for your contribution PinmemberSaxoniaCoder12-Sep-07 18:47 
GeneralRe: Thanks for your contribution Pinmemberjonnii12-Sep-07 22:48 
GeneralRe: Thanks for your contribution PinmemberPeter Ritchie17-Sep-07 9:53 
GeneralRe: Thanks for your contribution PinmemberPhil_N12-Sep-07 23:03 
GeneralRe: Thanks for your contribution PinmemberUrs Enzler17-Sep-07 22:39 
I just have to give my opinion, too:
 

SaxoniaCoder wrote:
I think singletons are the only way to get sure that there is only one instance of a class

 
Not really. Take the Service Locater pattern for instance, or a sort of Factory or Provider that returns always the same instance for a specific query.
 
In my projects, I never use the singleton pattern anymore, because the patterns mentioned above are much more flexible because they allow configuration (which class to instantiate for a requested interface for example), better testing (replacement of real instances with mocks (with the use of the configuration)).
 
And as mentioned in another post the use of singletons leads to tightly coupled code, whereas a service locater pattern leads to loosely coupled systems which are better testable, maintainable and most important more fun Wink | ;)
 

But if you really want to use the singleton pattern, then this is a nice use of generics for it.

 
-^-^-^-^-^-
no risk no funk ................... please vote ------>

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140709.1 | Last Updated 14 Sep 2007
Article Copyright 2007 by SaxoniaCoder
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid