We Keep Coding

Prevent a Class from being instantiated

Hi i want to have a class that cannot be instantiated but can be added as a static field to another class but i could not achieve it;
Here is what i've done;
public class ValueListManager
{
public static Operations myOps { get { return new Ops(); } }
}
public interface Operations
{
void Call();
}
public class Ops : Operations
{
public void Call()
{
}
}
I dont' want the Ops class to be instantiated anywhere else. Basically I want to be able to;
ValueListManager.Operations.Call();
But i dont want to be able to use the ops class like;
var ops = new Ops();
Is there a way to achieve this?

You can achieve that by declaring the Ops class as a private class within the ValueListManager class where you want to use it:
public class ValueListManager
{
private class Ops : Operations
{
public Ops()
{
}
public void Call()
{
}
}
public static Operations myOps { get { return new Ops(); } }
}
Note, that in this example based on your code, a new instance of the Ops class is created every time you access the myOps property. If you don't want that, you need to store the Ops instance in a static field once it is created and use that in the Getter of the property.

As I understand you want to instantiate this class only once and later use it.
You can use Singletone pattern, you can also use inheritance with this pattern.
public class Ops: Operations
{
private static Ops instance;
private Ops() {}
public static Ops Instance
{
get
{
if (instance == null)
{
instance = new Ops();
}
return instance;
}
}
public void Call()
{
// do something
}
}
and where you want to use it you can call its method:
Ops.Instance.Call()

If you don't want to nest your classes for some reason, and don't want to basically change anything except the Ops class itself, you could put your code into a different assembly (add a class library to your solution), and make the constructor internal:
public class ValueListManager
{
public static Operations myOps { get { return new Ops(); } }
}
public class Ops : Operations
{
internal Ops() {}
public void Call()
{
}
}
Then you'd only need to add a reference to that assembly from the one you want to use that, you'd not need to change any other code.
The constructor (thus new Ops()) can only be accessed from that assembly, code in other assemblies won't be able to new.

This is very similar to the design pattern singleton, but it is unclear from your code if you want only one instance or if you don't want to instantiate it from elsewhere?
If it is a single instance you're after the most recommended way to implement a singleton in c# is using the static constructor:
public class Single
{
private static Single instance;
private Single() { }
static Single()
{
instance = new Single();
}
public static Single Instance
{
get { return instance; }
}
}
Most other ways have (at least a theoretical) risk of threading issues.
However it should be noted that the singleton pattern (and typically extensive use of static methods) is in some contexts an indication of a bad design.

how to use interface with singleton class

As I go through the differences between Singleton Vs Static class, I came across one point that we can inherit an interface in singleton class and can call singleton through interface for multiple implementation.
I would like some code demonstration with good example, how object orientation can achieve through singleton and not through static.
Thanks,

Although it's hard to tell what exactly you are referring to, one pattern you might be referring to is the Multiton pattern, where you manage a map of named instances as key-value pairs.
That's basically a factory, but each instance is only created once:
I've modified the Wikipedia example a bit to show that you can even derive from a singleton class, as long as your concrete implementations are private and within the original class:
class FooMultiton
{
private static readonly Dictionary<object, FooMultiton> _instances =
new Dictionary<object, FooMultiton>();
// this is the classic good old singleton trick (prevent direct instantiation)
private FooMultiton()
{ }
// you can also have private concrete implementations,
// invisible to the outside world
private class ConcreteFooMultitonOne : FooMultiton
{ }
public static FooMultiton GetInstance(object key)
{
lock (_instances)
{
FooMultiton instance;
// if it doesn't exist, create it and store it
if (!_instances.TryGetValue(key, out instance))
{
// at this point, you can create a derived class instance
instance = new ConcreteFooMultitonOne();
_instances.Add(key, instance);
}
// always return the same ("singleton") instance for this key
return instance;
}
}
}
Also, generally, if a singleton is not a static class, it can implement any interface you want. The only thing that a singleton pattern prevents is instantiation of multiple instances of a singleton class, but that doesn't mean you cannot completely replace the implementation with something else.
For example, if you have a singleton which is not a static class:
interface ICanTalk
{
string Talk();
}
class Singleton : ICanTalk
{
private Singleton() { }
private static readonly Singleton _instance = new Singleton();
public static Singleton Instance
{ get { return _instance; } }
public string Talk()
{ return "this is a singleton"; }
}
You can also have a number of different implementations:
class OtherInstance : ICanTalk
{
public string Talk()
{ return "this is something else"; }
}
Then you are free to choose any implementation you want, but get only a single instance of the Singleton class:
ICanTalk item;
item = Singleton.Instance;
item = new OtherInstance();
item = new YetAnotherInstance();

According to nkr1pr
Every class can implement an interface, and a Singleton is just a "normal" class that makes sure that only one instance of it exists at any point in time apart from the other business logic it may implement. This also means that a Singleton has at least 2 responsibities and this is not good OO design as classes should only have 1 responsibility and make sure they are good at that responsibility, but that is another discussion.
Something like:
public interface MyInterface
{
}
And
public class MySingleton:MyInterface
{
private static MyInterface instance = new MySingleton();
private MySingleton()
{
}
public static MyInterface getInstance()
{
return instance;
}
}

I'm not sure what you are asking, but singleton classes can implement interfaces.
singleton class does not mean static class, one of the method to create a singleton instance is
to make use of static members.
public class MyInterfaceImplementation : IMyInterface
{
private static MyInterfaceImplementation instance;
private static readonly object lockObj = new object();
private MyInterfaceImplementation() { } //private .ctor
public static MyInterfaceImplementation Instance
{
get
{
if (instance == null)
{
lock (lockObj)
{
instance = new MyInterfaceImplementation();
}
}
return instance;
}
}
public void MyInterfaceMethod()
{
//Implement here
}
}

what's the difference between static property and singleton?

Singleton implemented with C# could be like:
public class Singleton
{
private static Singleton instance;
private Singleton() {}
public static Singleton Instance
{
get
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
}
If I use static to implement it like:
public static class Globals{
public static Singleton Instance = new Singleton();
}
in this way, app should also only get the one instance for the entire app.
So what's the difference between these 2 approaches? Why not use static member directly(more simple and straight forward)?

If you use the second approach:
public static class Globals{
public static Singleton Instance = new Singleton();
}
There's nothing preventing somebody from doing:
Singleton anotherInstance = new Singleton(); // Violates singleton rules
You also don't get the same lazy initialization your first version (attempts to) achieve, plus you're using a public field, which doesn't allow you the same flexibility in the future if you need to change what happens when a value is fetched.
Note that .NET 4 provides a potentially better approach to making a singleton:
public class Singleton
{
private static readonly Lazy<Singleton> instance = new Lazy<Singleton>( ()=> new Singleton());
private Singleton() {}
public static Singleton Instance
{
get
{
return instance.Value;
}
}
}
This is nice because it's fully lazy and fully thread safe, but also simple.

Below are some differences between static and Singleton :
Singleton is a pattern while static is a keyword.
Singleton class can have static and non static method, but static class can have only static members and methods.
We can implement interface in a Singleton class but in static class we cannot implement interface.
We can extend the Singleton class while we static class we can’t, i.e. Singleton class can be derived from any type of class.
for more static vs Singleton

How to make Singleton a Lazy instantiated class?

I have a class which is lazy instantiated by another library. I don't have control over that library code but still need to be sure it cannot create more than one instance of my class.
Is it possible ? how ?

Some simple solutions to this question hides some problems, for a full understanding of this matter I recommend the reading of the following article
http://www.yoda.arachsys.com/csharp/singleton.html
Which concludes with an optimal solution
public sealed class Singleton
{
Singleton()
{
}
public static Singleton Instance
{
get
{
return Nested.instance;
}
}
class Nested
{
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Nested()
{
}
internal static readonly Singleton instance = new Singleton();
}
}

If it's calling your class's constructor, the only thing you can do is throw an exception in the constructor if you determine that an instance was previously created. Since you don't have control over the other library, you wouldn't be able to use a factory method or static property which would normally be the way you control access to a singleton.
Depending on your situation, you may also look into using a lightweight proxy that wraps a singleton instance. In this example, any number of MyObjectProxy can be created but they all defer their implementation to a single instance of MyObject.
public class MyObject {
internal MyObject() {
}
private int _counter;
public int Increment() {
return Interlocked.Increment(ref _counter);
}
}
public class MyObjectProxy {
private static readonly MyObject _singleton = new MyObject();
public MyObjectProxy() {
}
public int Increment() {
return _singleton.Increment();
}
}

Circular reference problem Singleton

I'm trying to creating a Singleton class like below where MyRepository lies in separate DAL project. It's causing me a circular reference problem because GetMySingleTon() method returns MySingleTon class and needs its access. Same way I need MyRepository access in constructor of MySingleTon class.
public class MySingleTon
{
static MySingleTon()
{
if (Instance == null)
{
MyRepository rep = new MyRepository();
Instance = rep.GetMySingleTon();
}
}
public static MySingleTon Instance { get; private set; }
public string prop1 { get; set; }
public string prop2 { get; set; }
}
UPDATE: I was doing it very wrongly.
I think didn't needed any singleton. Now I've created a class with static properties in a third project and I'm setting it once and accessing it everywhere. And it has solved my problem for now.
Thanks everyone for your answers.

The repository should not return a singleton object, a repository is used to access data and not returning singleton objects. Your repository could by itself be a singleton, but I don't recommend it, and I don't recommend using a singleton for the class using the repository either. In the code you have it seems like the repository needs to be aware of the "business layer" which is all messed up, the relationships should go only one way. I would re-write it as:
public class MySingleTon
{
private MySingleTon()
{
// You constructor logic, maybe create a reference
// to your repository if you need it
}
private static MySingleTon _instance;
public static MySingleTon Instance {
get
{
if(_instance == null)
_instance = new MySingleTon();
return _instance;
}
}
public string prop1 { get; set; }
public string prop2 { get; set; }
}
I don't recommend my solution, but it should solve you problem. What I do recommend is looking into dependency injection and inversion of control since your design seems sort of wrong. Have a look at NInject.
EDIT: One other thing, why does your singleton have several properties that are public? A singleton shouldn't expose properties it should only expose functions, and should mainly be used when you have a utility class like Math or a true singleton like a logger.

Although , it is not good to create such a class intraction and i don't know what is the reason behind this.
but you can do similar to the below code
Create a project called Public Interface and define an interface IMyRepository with the public functions which you want to expose from MyRepository class.
Create a public property in the singleton class which returns IMyRepository and can be set outside the assembly also.
Now , you need to explicitly set this property from the assemblies which reference your singelton assembly and i assume you can create the object of MyRepository class from other assemblies.
Please note : Above solution is only a trick to break the circular reference not the optimal solution.

While having the singleton accessor property within the class itself is a generally used shortcut, in more complicated situations when you need to deal with instances of multiple related classes it may prove the wrong way. The problem is mixing concerns within a single class.
Your MySingleton class shall be rather some MyClass which is implemented in way generally not dependent on the number of instances that will exist on run-time. Likewise MyRepository shall be able to manage and provide any number of MyClass instances. The fact you will be dealing with only a singleton instance of MyClass can be encapsulated into a separate factory (or accessor or whatever you call it) class that will bind MyClass and MyRepository together.
So try to rethink your design in the following way (schematic):
public class MyClass { ... }
public class MyRepository
{
public MyClass GetMyClassInstance(...);
}
public static class MyClassFactory
{
public static MyClass SingletonInstance
{
get
{
if (singletonInstance == null)
singletonInstance = myRepository.GetMyClassInstance(...);
return singletonInstance;
}
}
}
The remaining question is where does myRepository come from. For example, it can be created on program start-up and provisioned into MyclassFactory as a member field.
At the end of the day, a lot can be made easier if you consider using an inversion of control container. The next step is also shift towards interface-based design. That gives you another layer of abstraction and provides more flexibility in terms of interchangeability of implementations.

in addition to the code from Saurabh, you will change the Singleton class by :
public class MySingleTon
{
static MySingleTon()
{
if (Instance == null)
{
Instance = new MySingleTon();
}
}
private MySingleTon(){}
public static MySingleTon Instance { get; private set; }
public IMyRepository MyRepository{ get; set ;}
}