I have a singleton object in C#.
This singleton object works based on some state assigned to it.
I dont have any method to switch state of singleton object at run time. Also I dont need it as application always start in one state and remains in same state.
Problem is while writing the test cases. I have written the test cases for each state. But I cant run it because the for all test cases I have single object with one state.
How to run the tests for other state. How to re-create the object for each test?
I dont want to change the singleton object code for test cases.
Any thought or idea will be much appreciated.
This is one of the reasons why it is handy not to manage the lifetime of a class yourself, but to have an Inversion of Control (IoC) container such as Autofac or Unity do it for you. You then simply create a class, that looks like any other class, and tell your IoC container to instantiate it as a singleton.
See also An Autofac Lifetime Primer.
In the case when you cannot use an IoC container (can't think of any, but let's be flexible), you can create an internal class that contains your "singleton"'s logic -- and this internal class is just that, an internal class, not a singleton...
internal class MyLogic
{
...
}
And then you wrap it in a public class, and make that a singleton. If you put both these classes together in a single Project, then the internal class (the implementation of your business logic) is not accessible to your application, only the public singleton version is accessible.
public sealed class MySingleton
{
private MySingleton() { Implementation = new MyLogic(); }
public static MySingleton Instance { ... }
private MyLogic Implementation { get; set; }
...
}
But then you can point out in your AssemblyInfo that your unit-test project does have access to the internal class by using
[assembly: InternalsVisibleTo("MySolution.UnitTests")]
This way, you can unit test your logic class while your application(s) can only use it as a Singleton.
Frankly I prefer the IoC way but if that's new to you, it's probably faster to implement the above solution instead.
Good luck!
I dont want to change the singleton object code for test cases.
Maybe it's the time to think about changing it for your whole program. Is there a reason you need this to be singleton? Singleton is a great pattern if you need it, but it's often misused by people who want to use global variables but have heard that they are evil. Now they program singletons, because they work the same while being one of those "patterns" that are cool OOP.
But a singleton is nothing but a global. And it has the same problems as a global. If you use that pattern, make sure you actually need it, because it comes with problems attached and you need to weight the benefits against the drawbacks. If you don't use the benefits, you only have drawbacks.
I would suggest you to avoid singletons when possible, see this talk by Misko Hevery: The Clean Code Talks
Related
Generally speaking, my dependencies are abstracted to interfaces, but I will only be using one concrete implementation during non-testing use. For example, were I to write a FooService:
public class FooService : IFooService
{
private readonly IBarDependency _barDependency;
public FooService(IBarDependency barDependency)
{
this._barDependency = barDependency;
}
public FooService() : this (new BarDependency())
{
// nothing to do here
}
. . . // code goes here
}
Now purists tend to gasp in horror, because I instantiated a concrete class in the parameterless constructor. I have, in the past, shrugged this off, because I know the only time I will not be using the concrete class is when I am unit testing and mocking dependencies.
While it does couple the FooService class to the BarDependency class, it's not a tight coupling; these classes and interfaces also exist in the same assembly, so it doesn't seem to me like I'm losing a whole lot here, or painting myself into a corner. I can still easily test the FooService class without getting unmanageable code, just by using the constructor that allows me to pass in mocked interfaces.
So the question is: what is actually at risk here? What am I losing with this sort of pattern that is worth adding an IoC container?
Lifetime management, for example. Maybe you use BarDependency throughout your code and only want one instance to be alive. You can't do this if every user creates their own instances.
You also have to find all usages of new BarDependency() if you ever want to replace it with new NewBarDependency().
A container fixes both problems for you, as then you configure the instantiation and lifecycle of objects in one method, namely where you set up your container.
It depends, but if the FooService needs to be accessed by some other developer, the dependency to BarDependency will be basically hidden. In my opinion not only mocking and testing is the reason for using dependency injection, but also a clear indication what is used by certaing classes, and what they are need to work properly.
And maybe I'm to much purist, but when such pattern is ok, then it's easily to go further and end up with a totally tightly coupled and hard maintanable code.
What you lose without dependency injection is the ability to centralize all aspects of the dependency management. Visualizing the dependency graph and managing the lifecycles of your objects is easier when you have all the information in one place, instead of scattered all over the code.
A concrete example would be if you wanted to replace the default implementation of IBarDependency used in some, but not all of the classes. Reasoning about which ones to replace is much easier if the dependencies are all wired in the same file or group of files.
I'm writing a PCL in .NET and I have a wrapper class around HttpClient that loads an HtmlAgilityPack.HtmlDocument from a URI in multiple different methods. It is stateless, so I would really like to make it static, since in my opinion instantiating something with new gives the impression that it contains state. However, I have a couple of interfaces that I want it to inherit from, so it can't be static. This is where I thought of making it a singleton. Here are a few snippets from the code:
public class ConcurrentClient : IAsyncClient<HtmlDocument>
{
private static readonly ConcurrentClient _Instance = new ConcurrentClient();
private ConcurrentClient() { }
public static ConcurrentClient Instance
{
get { return _Instance; }
}
public HtmlDocument LoadUri(string uri)
{
return LoadUriAsync(uri).Result;
}
// ...
public async Task<HtmlDocument> LoadUriAsync(string uri,
Encoding e, NetworkCredential creds, Action<HtmlDocument> prehandler)
{
// ...
}
}
I'm wondering, though, if I should change the beginning parts to this:
private static readonly ConcurrentClient _SharedInstance = new ConcurrentClient();
public static ConcurrentClient SharedInstance
{
get { return _SharedInstance; }
}
The reason for this is I'm not that sure about using the Singleton pattern, mainly because I've rarely seen it in use in other libraries (maybe WinRT's Application.Current?), and I think it would encourage users of my PCL to write coupled code, since it's much easier to just call ConcurrentClient.Instance everywhere than it is to pass it in as a parameter.
However, I do want to encourage the use of a shared instance because excluding the reasons above, there's very little point in calling new ConcurrentClient() because all it does is create more memory overhead. Also, I can't think of a better way to implement inheritance with methods that don't really rely on state.
Your Singleton already implements 2 interfaces. The question really is, where are the dependencies to this Singleton and why are they there ?
If the answer is that these dependencies are there because they need to get to the implementation of those interfaces then I would say that this is wrong.
The whole point of doing a SOLID design is to have dependencies towards interfaces and not towards any concrete implementation. So anyone who needs any of these 2 interfaces should be given those interfaces via dependency injection. So that means that the interfaces would be passed by their constructor or via an extra parameter in a method call, a strategy pattern, ...
Also see this : http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
There can be a reason to make a singleton, but based on your explanation this is not that clear.
Investigate more of your time in using dependency injection. If you have that under control move one step further and investigate on how you can use an inversion of control container.
Also, it's easy to forget DI and passing around the object as a parameter when you can just access it by Singleton.Instance.
You are forgetting about unit testing. If you pass interfaces to your class constructors you can easily mock those interfaces and test your class functionality. With your singleton in place, your classes really need that singleton. Unit testing will be harder.
Of course Instance is easy to access, it's a global and since people revert back to old habits of programming towards objects all the time, that is why it is so popular.
There seems to be a stigma on SO regarding use of Singletons. I've never personally bought into it but for the sake of open mindedness I'm attempting to give IoC concepts a try as an alternative because I'm frankly bored with my everyday work and would like to try something different. Forgive me if my interpretation of IoC concepts are incorrect or misguided.
Here's the situation: I'm building a simple HttpListener based web server in a windows service that utilizes a plug-in model to determine how a request should be handled based on the URL requested (just like everyone else that asks about HttpListener). My approach to discovering the plug-ins is to query a configured directory for assemblies decorated with a HttpModuleAssemblyAttribute. These assemblies can contain 0 or more IHttpModule children who in addition are decorated with a HttpModuleAttribute used to specify the module's name, version, human readable description and various other information. Something like:
[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : IHttpModule
{
public void Execute(HttpListenerContext context)
{
/* Do Something Special */
}
}
When an HttpModule is discovered I would typically add it to a Dictionary<string, Type> object who's sole purpose is to keep track of which modules we know about. This dictionary would typically live in my variety of a Singleton which takes on the persona of an ACE style Singleton (a legacy from my C++ days where I learned about Singletons).
Now what I am trying to implement is something similar using (my understanding of) general IoC concepts. Basically what I have is an AppService collection where IAppService is defined as:
public interface IAppService : IDisposable
{
void Initialize();
}
And my plug-in AppService would look something like:
[AppService("Plugins")]
internal class PluginAppService : IAppService, IDictionary<string, Type>
{
/* Common IDictionary Implementation consisting of something like: */
internal Type Item(string modName)
{
Type modType;
if (!this.TryGetValue(modName, out modType)
return null;
return modType;
}
internal void Initialize()
{
// Find internal and external plug-ins and add them to myself
}
// IDisposable clean up method that attempts to dispose all known plug-ins
}
Then during service OnStart I instantiate an instance of AppServices which is locally known but passed to the constructor of all instantiated plug-ins:
public class AppServices : IDisposable, IDictionary<string, IAppService>
{
/* Simple implementation of IDictionary */
public void Initialization()
{
// Find internal IAppService implementations, instantiate them (passing this as a constructor parameter), initialize them and add them to this.
// Somewhere in there would be something like
Add(appSvcName, appSvc);
}
}
Our once single method implementation becomes an abstract implementation + a constructor on the child:
[HttpModule(/*Some property values that matter */)]
public abstract class HttpModule : IHttpModule
{
protected AppServices appServices = null;
public HttpModule(AppServices services)
{
appServices = services;
}
public abstract void Execute(HttpListenerContext context);
}
[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : HttpModule
{
public SimpleHttpModule(AppServices services) : base(services) { }
public override void Execute(HttpListenerContext context)
{
/* Do Something Special */
}
}
And any access to commonly used application services becomes:
var plugType = appServices["Plugins"][plugName];
rather than:
var plugType = PluginManager.Instance[plugName];
Am I missing some basic IoC concept here that would simplify this all or is there really a benefit to all of this additional code? In my world, Singletons are simple creatures that allow code throughout a program to access needed (relatively static) information (in this case types).
To pose the questions more explicitly:
Is this a valid implementation of a Factory Singleton translated to IoC/DI concepts?
If it is, where is the payback/benefit for the additional code required and imposition of a seemingly more clunky API?
IoC is a generic term. Dependency Injection is the more preferred term these days.
Dependency Injection really shines in several circumstances. First, it defines a more testable architecture than solutions that have hard-coded instantiations of dependencies. Singletons are difficult to unit test because they are static, and static data cannot be "unloaded".
Second, Dependency Injection not only instantiates the type you want, but all dependant types. Thus, if class A needs class B, and class B needs class C and D, then a good DI framework will automatically create all dependencies, and control their lifetimes (for instance, making them live for the lifetime of a single web request).
DI Containers can be though of as generic factories that can instantiate any kind of object (so long as it's properly configured and meets the requirments of the DI framework). So you don't have to write a custom factory.
Like with any generic solution, it's designed to give 90% of the use cases what they need. Sure, you could create a hand crafted custom linked list data structure every time you need a collection, but 90=% of the time a generic one will work just fine. The same is true of DI and Custom Factories.
IoC becomes more interesting when you get round to writing unit tests. Sorry to answer a question with more questions, but... What would the unit tests look like for both of your implementations? Would you be able to unit test classes that used the PluginManager without looking up assemblies from disk?
EDIT
Just because you can achieve the same functionality with singletons doesn't mean it's as easy to maintain. By using IoC (at least this style with constructors) you're explicitly stating the dependencies an object has. By using singletons that information is hidden within the class. It also makes it harder to replace those dependencies with alternate implementations.
So, with a singleton PluginManager it would difficult to test your HTTP server with mock plugins, rather it looking them up from some location on disk. With the IoC version, you could pass around an alternate version of the IAppService that just looks the plugins up from a pre-populated Dictionary.
While I'm still not really convinced that IoC/DI is better in this situation, I definitely have seen benefit as the project's scope crept. For things like logging and configurability it most certainly is the right approach.
I look forward to experimenting with it more in future projects.
I've been experimenting with the SimpleServiceLocator, and I like it quite a bit, but there's one thing that I'm really frustrated by--you can't use automatic constructor injection for singletons. To make matters worse, you can't even use automatic constructor injection for its dependencies. You have to create the singleton object, all it's dependencies, all its dependencies dependencies, etc. manually.
Why is SimpleServiceLocator designed this way?
Aren't singletons supposed to be just like regular instances except that, upon the first request for an instance, that instance is stored and reused instead of a new one being created each time? Why does SimpleServiceLocator require an instance to be provided during the registration process rather than just allow the instance to be created and stored on first request?
I get that the point of SimpleServiceLocator is to not have a lot of bells and whistles and be really easy for beginners to use, but it seems like it's just designed incorrectly, and that the method for registering a singleton should be identical to the method for registering a regular instance except that the method name should be RegisterSingle<T>() instead of Register<T>(). Is there a reason for the more complicated (and seemingly less convenient) design I'm just not getting?
Meanwhile, is there another (preferably free) IOC container I can use that let's me register objects in code similarly to the SimpleServiceLocator but does allow automatic contructor injection for singletons (or at least allows automatic constructor injection for the dependencies of the singleton)?
The RegisterSingle<T> method is just a fancy helper method just to make life easier. What you can do with RegisterSingle<T> can also be done with the Register<T> method. The web site gives examples of this. You can register a single instance using the Register<T> method as follows (it uses a closure):
var weapon = new Katana();
container.Register<IWeapon>(() => weapon);
When you look at the lifestyle management examples on the web site, you can see the following example for creating a thread static instance:
[ThreadStatic]
private static IWeapon weapon;
container.Register<IWeapon>(
() => return weapon ?? (weapon = new Katana()));
I think this is the power of simplify, because there is almost nothing you can't do with this pattern. What you are trying to achieve is a bit harder, I must admit this, but nothing really advanced IMO. Here is the code you need to solve your problem:
private static IWeapon weapon;
container.Register<IWeapon>(
() => weapon ?? (weapon = container.GetInstance<Katana>()));
The trick is here to store the instance in a static variable (just as with the thread static), but now you should not create the instance yourself by newing it up, but you delegate the creation to the Simple Service Locator. This works, because –as you know- the SimpleServiceLocator will do automatic constructor injection when a concrete type is requested.
I must admit that it is a shame that we need to do this trickery. It would be nice if the library could actually do this for us. For instance, I can imagine a RegisterSingle<T> overload being added that allows us to do the following:
container.RegisterSingle<IWeapon>(
() => container.GetInstance<Katana>());
Please let me know what you think of such an overload. I'm always interested in feedback to make the library better. This would certainly be a nice feature for the next release.
Update:
Since release 0.14 we can do the following:
container.RegisterSingle<IWeapon, Katana>();
It won't get any easier than this.
Cheers
A typical singleton implementation has a private constructor, so the container cannot "see" it, call it, or detect dependencies.
Perhaps you are referring to the lifetime management features of some IoC containers, where you can configure the container to always return the same single instance of a class.
This is not what singleton means. Although the container returns the same instance, nothing prevents you from instantiating an instance in code using new.
A singleton, on the other hand, can only ever be instantiated once from any source (once per thread in some implementations). It does not expose a public constructor, rather a static method such as:
public class MySingleton
{
// note: not a thread-safe implementation
static MySingleton instance;
static DependencyThing thing;
private MySingleton(DependencyThing thing)
{
MySingleton.thing = thing;
}
public static MySingleton GetMySingleton(DependencyThing thing)
{
if(instance == null) instance = new MySingleton(thing);
return instance;
}
}
As you can see, you can't call new MySingleton() from outside the class itself. To "instantiate" the a MySingleton, you have to call MySingleton.GetMySingleton(thing). This call returns the sole instance or creates and then returns it.
SimpleServiceLocator has no way of knowing how to create this object, or from where to detect its dependencies.
This ability could be added if the API exposed something like
public void Register<T>(Expression<Func<T>> staticFactoryMethod)…
…in which case you could call Register(() => MySingleton.GetMySingleton());, but this would only work without parameters. There would have to be more overloads:
public void Register<T, TParam1>(Expression<Func<TParam1, T>> staticFactoryMethod)…
public void Register<T, TParam1, TParam2>(Expression<Func<TParam1, TParam2, T>> staticFactoryMethod)…
…so that the container would know what dependencies to instantiate and pass to the specified factory method.
All that said, it doesn't really make sense to have dependency injection with a singleton. Each subsequent call to GetMySingleton would have to ignore the arguments or alter the state of the singleton, which is almost certainly a very bad idea.
Using a Singleton class guarantees one instance of a class to give control to the programmer. Really useful.
I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?
Would be handy to decalre:
public sealed class MySingleton : ISingleton //or a different class
{ ... }
And then expect the class to only ever be instantiated once.
Is this a good idea, or am I thinking a bit off the mark? :)
I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?
It doesn't and can't exist. A singleton basically requires a static Singleton getInstance() method, but because it's static, it cannot be definied as an abstract (interface) method. It also makes sense, there can be only one singleton implementation, not multiple. Abstracting it is pointless.
You'll need to boilerplate complete singletons yourself. I however highly question how that's useful. It's certainly not its sole purpose to prevent stackoverflow or memory errors. Writing good code prevents that. Singletons are only useful if you want to have the enduser to deal with the same instance all the time. Which can be done as good without the singleton pattern by the way. Either just declare it static or make use of the "application scope" concept the average framework can provide you.
Instead of singletons, rather look for inversion of control (dependeny injection). That's by the way also exactly what Spring is doing. They do not use "pure" singletons. It was a poor word choice they made.
See also:
Singletons are evil
Patterns I hate #1: Singleton
Inversion of Control and Dependency Injection pattern
A Spring Singleton is not a Singleton
Singleton does not prevent stack overflow, not sure what you are getting at with that.
For Java, what came to mind is Spring. By default, every Spring bean you write is a singleton. You can use it in 100 places, and they will all be set automagically via injection, and all 100 references will go to the same object (i.e. a singleton). When you set up a project in Spring, you can make any class you want a singleton just by following the conventions.
Google Guice is a dependency-injection framework that supports a #Singleton annotation.
Note that classes annotated with #Singleton aren't "true" singletons - there's nothing stopping client code from creating many instances of such a class. However, Guice-managed dependencies will all share the same instance.
See http://code.google.com/p/google-guice/wiki/Scopes
Maybe not what you're looking for, but here's my favorite version of the singleton pattern in C#. It's thread-safe, uses lazy instantiation, and doesn't require any locks. It's also pretty painless to write... no frameworks needed. ;)
class MyClass
{
// ...
#region Singleton pattern
private MyClass() { }
public static MyClass Instance { get { return Singleton.instance; } }
class Singleton
{
static Singleton() { }
internal static readonly MyClass instance = new MyClass();
}
#endregion
// ...
}
To get the object instance:
MyClass m = MyClass.Instance;
In Java you can do this simply with an enumerated type. You specify the number of instances so that there can be none (also called a utility class), one (also called a singleton) or more as you choose.
public enum MySingleton {
INSTANCE;
}
.NET 4.0 has the Lazy(T) Class, which will lazily-initialize a value on first access, in a thread-safe manner. There are lots of examples at the Lazy Initialization topic.
Also, if you are using Unity, there is a lifetime manager which you can configure with the ContainerControlledLifetimeManager to ensure a single instance.
Ruby has a module called singleton that makes the class which includes it a singleton. This module is built into the standard library.
The intention behind the singleton pattern is "Configure once. Use multiple times". This is typically used to share any kind of data or resources as mentioned in one of the answers above. But it is also useful to enable any kind of "management" application. (think JMX if it is Java)
You have one instance of a certain class that you can use multiple times. Since there is only one instance, by configuring that instance appropriately, you can reflect the configuration changes across the app. Hence the singleton pattern gives the ability to enable a "management dashboard" to your app.
Spring or Spring.NET (the .NET implementation of Spring) are useful for configuring and injecting singletons. The same arguments apply for any kind of dependency injection framework. You should read about dependency injection in general to harness the full power. A true singleton, across multiple JVMs or clusters, is usually harder to create and manage. and might require tool support. In practice, it is not necessary to create and maintain that.
Don't confuse singletons with statics! The construct looks similar but it can be pretty different. Now to drum my own trumpet! Here is a link to an article that I had written about static methods.
public class Singleton<T> where T : class, new()
{
static class SingletonCreator
{
internal static readonly T instance = new T();
}
public static T Instance
{
get
{
return SingletonCreator.instance;
}
}
}
It is lazy and versatile. Define constructors on demand.