Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Interviewer asked me this question:
You have implemented the singleton Pattern and it is used by 3
classes, one class disposed the object. Does other two classes still
able to access?
how does that work?
could you please explain?
If it's a Singleton, then that means there is only one instance of it - everyone who references it gets the same instance. If you were to dispose the instance - though that seems pretty odd as a concept for a Singleton - then the classes that then try to reference it would likely get an ObjectDisposedException
Singleton Pattern and it is used by 3 classes
I am assuming they meant 3 variables/references, not classes.
Example:
var a = MyClass.Instance;
var b = MyClass.Instance;
var c = MyClass.Instance;
one class disposed the object - does other two classes still able to
access?
No
how it will work? could you please explain?
The purpose of the singelton pattern is to only have one instance of the class. So, whenever it is referenced i.e., (a, b, c) above, it is the same instance (it's pointing to the same address in memory).
So, if one of the classes disposed of the instance, this will mean that all references that currently point to the singleton will also have the disposed object as well (since all references were pointing to the same address location where the object lived).
Example:
a.Dispose(); // will dispose MyClass.Instance, making all references to it also have the disposed object
// a will now be disposed
// b will now be disposed
// c will now be disposed
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have had trouble wrapping my head around this and it seems to have lack luster documentation.
For example, this code:
private static readonly Object obj = new Object();
Can someone parse through this code and explain what is happening here. What exactly are the properties of this new object that was created? Why create an object this way?
You create a new oject with the type of Object. In most cases a statement like this is used for locking purpuse, see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/lock-statement for more information.
It simply creates an object of a type Object, which is the base type for all of C# reference types.
I has 4 methods:
ToString()
GetHashCode()
GetType()
Equals()
Every class derives form Object, so it has all of the methods above.
Moreover, 3 of these methods are virtual (so you can override them):
ToString()
GetHashCode()
Equals()
It's sometimes used for locking as Isitar mentioned in his answer.
Object obj
that declares a variable of type Object
= new Object();
the equals sign is assignment, the new operator creates a reference to a new instance of class Object and the portion of Object() default initializes it.
it will have the default properties of an object.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have an IDisposable class A. I need to use an object of A inside another method M of class B. Method M is called multiple times (million times a day). Should I use local object of A inside M and dispose once done or should I declare class level static member inside B and dispose once application ends.
Let me know if I am not clear.
One object for the life of the application is a Singleton; while they are useful under specific circumstance, they are not generally a good idea. See this question for a detailed explanation of why.
Classes that implement IDisposable are best used within the confines of a using statement that will take care of disposing it for you.
The clear exception to this is when multiple calls to the disposable class will be needed in the context of a single business action -- and that action is too spread out to be wrapped in a using statement. In this case, wrapping all the calls into a second disposable class that has the first as a private member. when the second class is disposed it should dispose of any private members that are disposable.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
First case:
If I have a set/get method for a value inside the class A, I can
set that value from the class B and use it inside A.
Second case:
I can just pass the value in a traditional way like Method(value);
Please, explain me which way is better.
I appreciate your answers.
Properties (what you call the set/get method) are essentially a "syntax sugar" on top of regular C# methods. There will be no performance difference between using properties and using regular methods.
Generally, though, you should prefer properties to methods for readability, i.e. when they present an appropriate semantics to the readers of your class.
Setters and Getters should be used for general properties of classes, used across several methods.
A parameter to a method call is appropriate for a variable tied to that one method (though possibly stored and used elsewhere, for instance if it is part of initialisation).
As always, do what looks best and works well in your context. If the using code feels awkward, look for another way. If it feels right, it's probably OK.
The goal of Object oriented programming is to have your data and operations together.
The goal is to reduce coupling between different kinds of objects so that we can re use the classes.
Never expose the data inside the class to the outside world but provide interfaces to do so
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Just being curious.
If I create 2 objects of a particular class, then 2 instances of the instance methods and the instance variables are present in the memory for that particular class?
EDIT: I tried with static and for sure, only one instance of the members were there but not sure with instance variables though.
If I create 2 objects of a particular class, then 2 instances of the instance methods and the instance variables are present in the memory for that particular class?
Instance fields - yes. Instance methods (including property accessors), no. Code (both instance and static) is shared among all instances.
Note that static classes will create an additional type for each generic parameter used, and each of those types will share one set of static variables, so for example:
// for example only, not intended to be a perfect singleton implementation
public class Singleton<T> where t : new()
{
private static T _Instance;
public T Instance()
{
return _Instance ?? (_Instance = new T());
}
}
Singleton<Class1> and Singleton<Class2> will each have a different object in memory for _Instance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
i do not want to know the difference between singleton and static class first of all.
i like to know when people should use singleton class and when static class.
in my apps i use static class for helper or utility method and use singleton for db connection and error logger class. but with the help of static class can be used to return sql db connection object and as well as error logging system.
i really like to know about other senior developer where they use singleton class and where they use static class.
it will very helpful if some one discuss this matter with sample situation and sample code. thanks
If you are creating loosely coupled system, then there is no way you can use static classes (because they cannot implement abstraction and cannot be injected). Static classes also very hard to mock, so it's not your choice if you are doing TDD or simple unit-testing. So, I use them only for dependencies which are not related to business requirements and should not be mocked. E.g. infrastructure logic like logging or mapping.
I also use static classes for extension methods if I cannot extend existing class, but want handy member-like API. Usually this is a also infrastructure-related extensions, like mapping, or serialization, which do not contain business logic.
A very broad question but will give you the first reason that popped into my head for use of a Singleton.
A Singleton is more appropriate than a dedicated static class when you need to manage the lifetime of some cached objects. Singletons are perfect when you want to refresh state without having to worry about thread safety, for example if you have a class that is being used as a singleton and it has many cached properties or lists that incoming requests may want access to.
The Refresh() method can simply be setting the current instance to a new instance and not having to refresh individual properties of the class:
private static YourClass instance = new YourClass(); // first instance
public static void Refresh(){
instance = new YourClass(); // creates a new, refreshed instance while not needing to worry about thread safety
}
public static YourClass Instance{
get{
return instance;
}
}
I usually use singleton classes when I am creating a database access object. Where I can have the instance of the object anywhere inside an application.
I usually stay away from static classes, which the exception of an occasional loader class when loading particular assets.