Archive

Posts Tagged ‘classes’

Interfaces vs. Abstract Classes

February 6, 2011 Leave a comment

There must be a million blogs on this topic, yet when the question is asked in an interview so many get it wrong or just get it partially right, or barely right at all. I have seen some good explanations and some overly complicated explanations so I want to try and get what we have summarized with enough detail so it is not overly complicated.

I think once we are aware of the fundamental differences between Interfaces and Abstract classes we will be better able to make the decision on when to use each one. Theoretically there are 5 basic differences between Interfaces and Abstract Classes:

An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.

An interface, by contrast, is a totally abstract set of members that can be thought of as defining a contract for conduct. The implementation of an interface is left completely to the developer.

Both interfaces and abstract classes are useful for component interaction. If a method requires an interface as an argument, then any object that implements that interface can be used in the argument.

public void Spin (IWidget widget)
{

}

 

Read more…

Advertisements
Categories: Architecture Tags: ,

Singleton Pattern Implementation in C#

February 6, 2011 Leave a comment

Essentially, a singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance. Most commonly, singletons don’t allow any parameters to be specified when creating the instance – as otherwise a second request for an instance but with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter, the factory pattern is more appropriate.) This article deals only with the situation where no parameters are required. Typically a requirement of singletons is that they are created lazily – i.e. that the instance isn’t created until it is first needed.

There are various different ways of implementing the singleton pattern in C#. I shall present them here in reverse order of elegance, starting with the most commonly seen, which is not thread-safe, and working up to a fully lazily-loaded, thread-safe, simple and highly performant version.

This implementation has four common characteristics:

1. A single constructor, which is private and parameterless. This prevents other classes from instantiating it (which would be a violation of the pattern). Note that it also prevents subclassing – if a singleton can be subclassed once, it can be subclassed twice, and if each of those subclasses can create an instance, the pattern is violated. The factory pattern can be used if you need a single instance of a base type, but the exact type isn’t known until runtime.
2. The class is sealed. This is unnecessary, strictly speaking, due to the above point, but may help the JIT to optimise things more.
3. A static variable which holds a reference to the single created instance, if any.
4. A public static means of getting the reference to the single created instance, creating one if necessary.

Note that in the two implementation below we use a public static property Instance as the means of accessing the instance. The property could easily be converted to a method, with no impact on thread-safety or performance.

 

Read more…

Categories: Architecture Tags: ,
%d bloggers like this: