Singleton vs. Shared class vs. Global object declaration.
These are so similar that I wanted to get some feedback on which might be better for my project. I am making a custom tracing framework that does NOT inherit from Microsoft's because I don't like much of it's functionality.
Well, the main issue is, I want my trace source class to be available to all components that reference my trace source, and I don't want each component declaring their own instance of a trace source.
If a program is a collection of 10 components, I don't want each of them writing to a different file for example.
So I need a class that's available everywhere in an assembly of multiple components.
It appears there are 3 ways to do it...
1. A global variable
2. A singleton
3. A shared class.
Do you have an opinion on what should be a deciding factor on which of these 3 to go with?
Thanks
Hi,
It seems in your scenario that a shared class (static class in c#) is your solution, but sometimes depends on your objective, here are some tips:
1) a global variable: In order to keep your variable alive you will need at least an instance, this instance needs to be shared accross all the applications, not only is considered bad practice but also breaks the OO objective. You need to create an instanceable object only if you need to allow individual access from different objects, in other words, if you need to keep an individual state of each object.
2) The singleton will work but you are adding more complexity to the component, you don't need it for your example and is also less efficient that a shared class.
3) Shared classes (static) should follow a stateless pattern, this means that every call is indipendent from the other one. Remember that you must handle the thread safetyness of your class (keep in mind that you will need to lock the whole type - not the instance as you don't have one - ) MS has created all their static class as thread safe, I recommend you to do the same.
In conclusion, global variable not recommended (bad practice), singleton (I think you are adding too much complexity), Static (the way forward 
)
Hope this brief explanation helps,
write me back if you need more detail on each of these points.
Regards
I do have one question now that you mention it. I don't think I have yet worked in my career with a variable with this intention in mind, it's kinda subtle, but here it is...
I need a component to have a class that can be used by many other individual components (call it SupportComponent), and when this SupportComponent is added to a Project that also contains 3 components that each also use the class in SupportComponent, that this single instance class in SupportComponent is not only now available in the main project that it's currently being included in, but it's also able to work with the other components that it was added to in previous component development without their being any compile problems. I know there won't be a namespace issue, but I guess my question boils down to these elements...
1. If you have a component that is referenced by 3 other components and you build a project with those 3 other components, what does the compile do? Does it only put 1 copy of each referenced item in the assembly no matter how many individual components reference it?
2. How public is Public? In other words, is a public member declared in a component that references a component that references another component really visible throughout the whole assembly?
1. with copy local set to true (default for project and file reference, not for gac'ed reference), vs copies the output assembly of the referenced project to the dependent project's output path.
2. very public, even the external assemblies.
btw: log4net is good if that fits your need for tracing tool.
You say the golden rule is that every call is independent. Is that really true? If that were so it would never be necessary to implement thread synchronization because the class would be completely stateless. As I understand it, thread synchonization is only required to protect durable data (i.e. state) not method variables or program logic.
A static class can retain state but it does so at type level (which equates to global variables within an application domain) rather than at instance level. In that case successive calls are dependent and that is why state must be synchronized in multi-threaded scenarios.
I always get a bit confused by static classes and methods. Please correct me if I am wrong.
