While reading Jon Skeet's article on singletons in C# I started wondering why we need lazy initialization in a first place. It seems like the fourth approach from the article should be sufficient, here it is for reference purposes:
public sealed class Singleton
{
static readonly Singleton instance=new Singleton();
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{
}
Singleton()
{
}
public static Singleton Instance
{
get
{
return instance;
}
}
}
In the rare circumstances, where you have other static methods on a singleton, lazy initialization may have benefits, but this is not a good design.
So can people enlighten me why lazy initialization is such a hot thing?
In those scenarios where whatever it is you are initializing might not be needed at all, and is expensive to initialize, (in terms of CPU cycles or resources), then implementing a lazy initializor saves that cost in those cases where the object is not required.
If the object will always be required, or is relatively cheap to initialize, then there is no added benefit from a lazy initializer.
In any event, implementing a lazy initializer improperly can make a singleton non-thread-safe, so if you need this pattern, be careful to do it correctly. Jon's article has a pattern, (I think it's the last one), that addresses this issue.
You don't need lazy initialization on a singleton, if the only reason you're going to use that type is to reference the instance.
If, however, you reference any other property or method on the type, or the type itself, you will initialize the singleton.
Granted, good design would leave one task for one type, so this shouldn't be a problem. If you make your singleton class to "complex", however, lazy initialization can help keep you from having consequences due to initializing too soon.
I'm not sure that this applies to C# as well, but I'll answer for C++:
One of the ideas behind Singletons is that the order of initialization of static objects is undefined. So if you have a static class that tries to use another static class, you might be in trouble.
A concrete example: Let's say I have a Log class, which I decided to implement as a Singleton. Let's also assume I have a method called LoadDB, which for whatever reason, is a static called at the start of the program. Assuming LoadDB decides it needs to log something, it will call the Singleton. But since the order of static initialization is undefined, it might be doing something that's an error.
A Singleton fixes this, since once you call GetInstance(), no matter where you are in the initialization process, the object is guaranteed to exist.
Again, I don't know if this is relevant, but at least that's the history of it (as far as I remember).
From Java DI perspective, lazy initialization is good, there are always (say, spring) beans in another API that you might not want to use, for example, an eagerly loaded singleton cache (something that is shared with everyone using the cache) might not be needed for you although it may be referred as a dependency in your same code. Whats the point in loading the singleton wasting resources?
The lazy initialization implementation choice is tricky, in spring, would you choose lazy-init="true" (spring eagerly instantiates singletons), an init-method/destroy-method, #PostConstruct, InitializingBean - afterPropertiesSet() method or return same spring instance in a getInstance() method?
The choice is a tradeoff of testability over reusability outside the spring container.
Related
I know that the performance and speed of SimpleInjector is very good but anyway I need to figure out how big is the overhead of calling the Container.GetInstance() method.
For example if I have the following class:
public class ServiceManager
{
private static Container _services;
public static void Initialize()
{
_services = new Container();
}
public static ICacheClient Cache
{
get
{
return _services.GetInstance<ICacheClient>();
}
}
}
what will be the performance impact if the Cache property is heavily used or I
should remove it and leave the consumers to explicitly get instance of the ICacheClient using the Container directly?
Nobody can answer that question for you. The performance impact depends on lots of variables such as your hardware, your application, and how often that property is being called.
So the real question is, is it fast enough for your situation. You are the only one who can find out by benchmarking this.
The framework is highly optimized in that it will:
Minimize the number of method calls in the happy path of the framework (which means the minimum number of method calls when calling GetInstance<T> and GetInstance(Type)).
Minimize the number of locks in the happy path of the application (the happy path is currently lock-free).
Minimize the number of callbacks into the container when resolving an object graph (which means that the container itself will not call GetInstance<T> to resolve an object's dependencies, but will inline the creation of those dependencies in the registration's internally constructed Func<object> delegate).
But although Simple Injector is highly optimized, there is a constant cost in calling GetInstance<T>. On each call, the container will always have to:
Do a dictionary lookup (using a Dictionary<Type, InstanceProducer> in the current implementation) for the given typeof(T).
Call the GetInstance() method on the found InstanceProducer instance.
Call a Func<object> delegate for the creation the given instance (inside the InstanceProducer.GetInstance method).
Do a cast from object to T before returning from GetInstance<T>.
From this constant cost, doing the dictionary lookup takes about 80% the time. The percentage of the constant overhead however goes down rather quickly when you start resolving anything else than a singleton, especially when resolving big object graphs.
Still, if you're doing lots of calls to the Cache property in a performance critical path of the application, you might want to optimize that (but again, you have to determine whether it is too slow: don't do premature optimizations). One easy way to do this is by injecting the ICacheClient into the constructor of consumers. This prevents the instance from being resolved from the container over and over again, and allows consumers to just use the locally cached ICacheClient instance without a problem.
As a matter of fact, this is a general pattern called Constructor Injection and is an adviced practive. Prefer letting the container build up a complete object graph for you (by using constructor injection) by making one single call to GetInstance<T> at the start of a 'request', instead of calling back constantly to the container during that request.
Recently I was having some issues with a singelton class that was lazy initializing a dictionary where a second thread would try to use it before it had actually been populated. So I implemented the variable initialization through the Lazy<T> class.
Here is my code:
private static Dictionary<string, string> GroupDefaults
{
get { return mGroupDefaults.Value; }
}
private static Lazy<Dictionary<string, string>> mGroupDefaults =
new Lazy<Dictionary<string,string>>(delegate
{
Dictionary<string, string> defaults = new Dictionary<string, string>();
foreach (KeyValuePair<string, UnitGroup> groupDef in Groups)
defaults.Add(groupDef.Key, groupDef.Value.First().Key);
return defaults;
});
This fixed the problem and now I am considering making this a regular practice of mine to use the Lazy<T> class anywhere I do lazy initialization to avoid any possible threading issues. So basically I would like to know if this is good/common practice? Or will it be detremental to performance or something?
It's pretty hard to say without knowing what type of performance constraints you have, but in my experience, one-time initialization is rarely a bottleneck (since by definition it only occurs once.) Lazy<T> was written to provide you with this exact service, so I would recommend using it.
From the documentation, I find the following:
If no delegate is passed in the Lazy constructor,
the wrapped type is created by using Activator.CreateInstance when the value property is first accessed.
If the type does not have a default constructor, a run-time exception is thrown.
Activator.CreateInstance is a method that is notoriously bad for performance. However, that doesn't seem to be a problem in your case, and at any rate, as dlev said, invoking the method once wouldn't be a problem. I haven't seen Lazy<T> used very often, but I do not see any reason not to use it in your case.
If this is for a singleton, a static constructor might be what you want. Something like:
class MySingleton
{
static MySingleton()
{
Instance().InitDict();
}
}
I think you may be using Lazy for not it's intended use. Lazy is to be used for situations where something has a large initialization cost, but there is a probable chance that it may not be used during the lifetime of the object.
If you always call GroupDefaults at least once per it's lifetime a better method would be to initialize GroupDefaults in a background thread at the start of the container's lifetime and hope that it is done before it is done initializing (I know there is a class for this but I need to dig in to the MSDN to find it)
I'm using dependency injection in my C# projects and generally everything is ok.
Nevertheless, I often hear the rule "constructor must only consist of trivial operations - assign dependencies and do nothing more" I.e:
//dependencies
interface IMyFooDependency
{
string GetBuzz();
int DoOtherStuff();
}
interface IMyBarDependency
{
void CrunchMe();
}
//consumer
class MyNiceConsumer
{
private readonly IMyFooDependency foo;
private readonly IMyBarDependency bar;
private /*readonly*/ string buzz;//<---question here
MyNiceConsumer(IMyFooDependency foo, IMyBarDependency bar)
{
//omitting null checks
this.foo = foo;
this.bar = bar;
//OR
this.buzz = foo.GetBuzz();//is this a bad thing to do?
}
}
UPD: assume IMyFooDependency can't be replaced with the GetBuzz(), as in that case the answer is obvious: "do not depend on foo".
UPD2: Please, understand that this question is not about eliminating dependency from foo in a hypothetic code, but about understanding a principle of good constructor design.
So, my questions is following: is this really a bad pattern to include non-trivial logic in constructor(i.e. obtaining buzz value, making some calculations based on dependencies.)
Personally I, unless lazy load is necessary, would include foo.GetBuzz() in constructor, as object need to be initialized after call to its constructor.
The only drawback I see: by including non-trivial logic you increase the number of places where something might go wrong, and you'll get an obfuscated error message from your IoC container(but same things happen in case of invalid parameter, so the drawback is rather minor)
Any other considerations for eliding non-trivial constructors?
If you need IMyFooDependency only for buzz creation, then you actually need buzz:
class MyNiceConsumer
{
private readonly IMyBarDependency bar;
private readonly string buzz;
MyNiceConsumer(string buzz, IMyBarDependency bar)
{
this.buzz = buzz;
this.bar = bar;
}
}
And create instance of nice consumer this way:
new MyNiceConsumer(foo.GetBuzz(), bar);
I don't see any difference between obtaining buzz before passing parameters to constructor, or obtaining it inside constructor. Same value will be returned from repository. So, you don't need to depend on repository.
UPDATE: Technically there is nothing wrong with complex initialization logic in constructor. Take a look on winforms InitializeComponent method, where all controls are created, initialized and added to form.
But it violates SRP (creation and initialization) and its hard to test. You can read more about this flaw on writing testable code guide. Main idea:
Do not create collaborators in your constructor, but pass them in.
(Don’t look for things! Ask for things!)
The rationale for not doing any work in the constructor comes from looking at the execution of the program in two phases. The first phase is to wire up your object graph. The second phase is to do the "real work".
There is a tension between this ideal and efficiently maintaining a class's invariants and internal state. The less setup you can do in your constructor, the more difficult all of your methods will be to implement because they must take into account the varying possible internal state of the object. Remember, the constructor is the only code you can be sure is called for an object.
The way out of this conundrum is to realize that an object's "real work" is defined by it's interface and behavior in relation to other objects. That is, the dependencies provided to the constructor and objects provided as arguments to methods later down the road.
Feel free to do any kind of setup you like in your constructor that does not have a noticeable effect on other objects in your system. Likewise, be very sensitive to timing issues in your object's construction.
If you determine that a File object can't exist without a filename provided by the user: don't call keyboard.filename_from_keyboard() in the constructor. Instead you design your system such that the object is created by a factory (provider) during execution with the filename provided to the constructor or you allow the File object to exist without a filename. Maybe it can get it's own filename during execution? This is part of managing your object's lifetime and it's the hardest part IMO. This gets very subtle because "real work" involves creating objects too. But I digress...
In your example you would have to decide if foo.GetBuzz() breaks that condition. If GetBuzz() is a referentially transparent function, you're almost always in the clear to call it in the constructor. If GetBuzz() involves any I/O, user interaction or changes any noticeable internal state of any other object, then it is probably does not need to be called from a constructor.
As lazyberezovsky rightly mentioned, don't look for things! Ask for things!
If the creating code (let's say, MyNiceCreator) treats foo as an opaque value and news up MyNiceConsumer, then most likely creation should not be the responsibility of MyNiceCreator. The code that creates the MyNiceConsumer instance must be able to give the required values to the constructor.
A better pattern:
MyNiceCreator should "ask" for a MyNiceConsumer instance. This way the creation of MyNiceConsumer instance will be the responsibility of the appropriate class.
the page at http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html?page=5 says that code like this:
public final static Singleton INSTANCE = new Singleton();
automatically employs lazy instantiation.
I want to verify if
1) all compilers do this, or is it that the compiler is free to do whatever it wishes to
2) and since c# does not have the "final" keyword, what's the best way to translate this into c# (and at the same time it should automatically employ lazy instantiation too)
Yes. The static initializer is guaranteed to run before you are able to access that INSTANCE. There are two negatives with this approach:
If an error occurs within the Singleton's construction, then the error is a little harder to debug ("Error in initializer").
On first use of the class, that object will be instantiated. If you did the locking approach, then it would not be instantiated until it was needed. However, being that the example is a singleton, then this is not a problem at all, but it could be a drag on an unused, yet lazily instantiated piece of code elsewhere that is not a singleton.
The translation for C# is readonly instead of final.
In my opinion, this is still vastly preferable to the secondary approach (synchronized/locked, checked instantiation within the a static getter) because it does not require any synchronization code, which is faster, easier to read and just as easy to use.
I recently made a recommendation to one of my colleagues stating that on our current project (C#) "services should be stateless and therefore static".
My colleague agreed and indicated that in our project the services are (and should be) indeed stateless. However my colleague disagreed that static implies no state and that stateless should mean static.
My questions is “does a method marked as static imply that it requires no state and that in a majority of cases should stateless methods be made static”.
Static nearly means global. There is still an instance, and there is still state in that instance, but it is the static instance, which means there is only one and all callers always refer to that one.
does a method marked as static imply
that it requires no state
1) No. You cannot say static methods imply that it requires no state because static methods can access static/singleton resources.
a majority of cases should stateless
methods be made static
2) Yes. Methods that require no state, therefore require no instance, should be generally made static.
A static method, in C#, can access the static variables of its containing class, and if it does, it's not stateless. I've seen some painful instances of non-reentrant "stateless" static methods triggering fun race conditions.
A truly stateless method can indeed be made static, and generally should.
I find it rather scary to say that stateless is the same as static as these are two different worlds. Stateless means that there is no state kept, i.e., a perfect example is an HTTP connection (once data is send, the connection is closed and there's no memory kept), where we are actually trying to do our best to maintain state regardless (login state for one).
Static on the other hand is a term used to describe a way that a method is invoked. In C# that means that a method can be invoked without a class instance, but an instance of a class is not the same as state. There's still the static instance and that's perfectly capable of maintaining state: any static member variable, field or property can maintain state. A static method or class is also perfectly capable of maintaining state by using memory mapped files, a database or whatever. Static is a calling convention, nothing more and is not related to being stateless or not.
I think his statement makes about as much sense as "Democracies should use yellow paper ballots".
He is mixing a high level design concepts "stateless services" with a low level technical implementation detail "using static classes".
Stateless services can (and have been) implemented in languages which supports only static variables (e.g. COBOL, RPG) and languages which dont even allow static variables (Erlang etc.).
I could easily imagine a case where stateless service was implemented largly using static classes, becuase they were there and already implemented the correct business logic, although its generally considered good Java programing practice not to use static classes unless you really need to.
He also serioulsy misunderstands what "static" is all about -- a static variable is a way of storing state between invocations -- and would therefore seem a better match with a "stateful" service.
static is a language keyword and state is a design concept. There's an obvious relationship between these two things, but it is a relationship of the concrete to the metaphysical, not a relationship of cause and effect. It is possible for static methods to refernce some kinds of state information.
Regarding stateless methods, here we are talking about method that don't reference a class instance, i.e. a this pointer. Marking these methods as static improves the clarity of the code and is consistent with best practices. Note that in this case we are talking a specific kind of "statelessness" and not making a general commentary about the use of stateful contexts.
static can be stateful. you just have to define static containers for said state. and the containers are shared among all calls to your static methods.
The short answer to your question is "no", static does not imply "no state".
In reference to your other comments, static can be used to help you implement a stateless service, but static alone is not sufficient. Another tool/technique to help make something stateless is to use immutable data structures. This (currently) isn't one of C#'s fortes, especially when compared to F#.
Beyond rehashing all the definitions of "static" that one can run through, the answer is "yes." Static methods may happily modify the state of the Class itself (represented through static variables), and even modify the state of instances of the class (notably, when they get passed an instance or set of instances). However, most of the time, you will use static methods in cases where no state is changed. The most important example is to find or create an instance (factory methods).
That said, the real answer is "no." In real life (Web Services over HTTP, for instance, or interaction with any kind of Orb), services never expose their service methods using actual static methods. You usually call static methods to get an instance of the service (or an instance of the service factory, from which you get an instance!), and then work with that. This is because your service proxy, internally, needs to keep track of where it's at. So while your methods seem stateless to you, they are really not.
Hope this wasn't too confusing :)
A Static class is not stateless. It can still have variables which, although static, have a state.
A Static class without any class-level variables is stateless. It holds no data.
Every class has a class definition structure, where static fields are represented and stored. Every "instance" of the class has access to the static fields stored in the class definition (a data structure caleld CORINFO_CLASS_STRUCT). Even when NO instances have been created, code anywhere in your assembly can access these static class-level fields by using the syntax classname.StaticFieldName, without any instance at all.
Since the values stored in these static class-level fields are persisted, they are definitely state. In fact, they are state shared by not only any instances of the class that might exist, they are shared throughout the assembly, whether any instances have been created or not.
Even more significant, since once a CORINFO_CLASS_STRUCT class definition has been loaded, unlike a true instance of the class, it is never unloaded until the assembly (or the AppDomain) is unloaded, so it is arguably more stateful than any instance field defined in a class, because an instance field dissapears when the instance gets garbage collected.
For more information check out CORINFO_CLASS_STRUCT link to Don Boxes' great book, Essential .Net
That is generally correct. However you can have static variables, which allow your static methods to have state. For instance, take this FooBarFactory class:
class FooBarFactory
{
private static _id = 0;
public FooBar MakeAFooBar()
{
FooBar foo = new FooBar();
foo.ID = _id;
_id++;
}
}
class FooBar
{
public int ID {get;set;}
}
In that case your static method has a minimum of state, but it's (probably) neccessary.
If you want a single instance with state, use a singleton pattern; it makes the intent clear that you're working with a single-occurrence object.
From that, I would then treat all static classes and methods as stateless. It just helps keep sanity.