We Keep Coding

C# Initialize Disposable in inherited constructor

Hey so I have a base class coming from a 3rd party dll, which is dependent on a disposable. Context: IDisposable
public class BaseValidator
{
public BaseValidator(Context context) {}
}
We're trying to move away from tying our classes to these dependencies. So we started relying on providers instead
public interface IContextProvider
{
Context Create();
}
I have a new validator that I'm writing which inherits from the BaseValidator, but I would like it to be dependent on the IContextProvider instead. So I'd like to create the context in the inherited constructor, but I would like to dispose of it in the destructor to prevent memory leaks, However I'm not sure if this is possible.
public class EntityValidator: BaseValidator
{
public EntityValidator(IContextProvider provider) : base(provider.Create())
{
}
~EntityValidator()
{
//I'm not how I can dispose the entity I've passed into it.
}
}
My question is, is there a trick I can use to Capture the variable passed into the base?
Note: I know I can make a work around with an external helper class, but I'm interested if anyone knows how to do this in a more savvy way.

If the BaseValidator class does not expose Context in a public manner, your current design would require you use reflection and knowledge of the internal implementation of BaseValidator to dispose of it, which is of course fragile.
I would instead capture the context using an intermediate constructor:
Context _context;
private EntityValidator(Context context) : base(context)
{
_context = context;
}
public EntityValidator(IContextProvider provider) : this(provider.Create())
{
}
Note, disposing via a finalizer (a.k.a. destructor) is not ideal due to constraints it places on the garbage collector. I'd instead have EntityValidator implement IDisposable

Before, in other language like C++, developpers used to rely on destructors to do a lot of cleaning. It was guaranteed by compiler so it was a strong behavior.
Smart pointer was a good pattern that used this behavior (to implement something like very basic but automatic garbage collection system).
Code was elegant but people used it for a lot of other need. With time a lot of code used to happen in destructor making the debug and readability hard.
IDisposable has been made to force developpers to write explicitely the call to Dispose... This is also useful when you want to Dispose internal resource without your object being destructed. For example in some "Close" method of Stream, where the stream is definitively closed but you can still have reference on steam... and use IsOpen property...
So for me you should not try to hide it. If you depends on code that needs to be Disposed, embrace this dependency... or chose another third party library.
You can simply make the class that need to manipulate Disposable object (BaseValidator) IDisposable too and delegate the need to call to the user.
Usually people that write class implementing IDisposable, in open source project, also write destructor (just in case someone forgot to call Dispose) This is true for a lot of class of .Net framework too (for example Pen() { where nobody thinks to call Dispose on it in some Control drawing events...)
So I would recommend :
Go get the information about if they did it with their classes, if yes they are strong probability they will keep this behavior/code forever. So you can just make your class to inherit IDisposable too, call context.Dispose in your own Dispose implement and that's enough... no need to worry because if your user forgot to call Dispose, the third party do the cleaning. Add a destructor/finalizer on your class only if you have other unmanaged resource to clean too...
Now if they did not, you can just wrap third party "Context" class in your own Context class. Your Context class will have to implement destructor that call Dispose on the instance of third party Context class. And that's it. You can even make your Context class sealed. Your Context class is here to make the behavior of your app as close as if 1) was true and implemented by third party. So this class will be easy to remove later because third party will probably implement finalizer one day (if they are serious). Doing just a sealed wrapper around just one class will avoid some complexity/issue related to how destructors (finallizers) works in .Net : They are all called in any order. Because of this underterministic behavior it makes your code hard to maintain later. For example if third party Context class's finalizer is called before your wrapping class => exception can occured and at a bad time (when gc is doing its stuff) which can make your app crash. Because of all these problems, you better go back to 1)

Reasoning behind implementing Dispose but not implement IDisposable?

I am refactoring a program right now. Trying to prevent memory leaks I was looking for objects to enclose in using blocks when I found a TaskDefinition object (class found in Microsoft.Win32.TaskScheduler) that Dispose was not called on. When I tried to enclose it VisualStudio told me that this class does not implement IDisosable. Looking at the class this is certainly true:
namespace Microsoft.Win32.TaskScheduler
{
// Summary:
// Defines all the components of a task, such as the task settings, triggers,
// actions, and registration information.
public sealed class TaskDefinition
{
...
// Summary:
// Releases all resources used by this class.
public void Dispose();
}
}
So why would you implement a Dispose method but not implement the IDisposable interface? Are there any drawbacks from implementing the interface?
Thank you for helping me to understand this.

From the comments:
According to this page, this is a bug that's fixed in newer versions of the assembly.
An additional note, however: the documentation for IDisposable.Dispose explicitly requires implementations to support calling Dispose multiple times, so a valid reason in other cases could be that the class does not support that. In that case, pretending to implement IDisposable but not meeting its requirements would be worse than not implementing it.

Benefit of IoC over my Factory Singleton

There seems to be a stigma on SO regarding use of Singletons. I've never personally bought into it but for the sake of open mindedness I'm attempting to give IoC concepts a try as an alternative because I'm frankly bored with my everyday work and would like to try something different. Forgive me if my interpretation of IoC concepts are incorrect or misguided.
Here's the situation: I'm building a simple HttpListener based web server in a windows service that utilizes a plug-in model to determine how a request should be handled based on the URL requested (just like everyone else that asks about HttpListener). My approach to discovering the plug-ins is to query a configured directory for assemblies decorated with a HttpModuleAssemblyAttribute. These assemblies can contain 0 or more IHttpModule children who in addition are decorated with a HttpModuleAttribute used to specify the module's name, version, human readable description and various other information. Something like:
[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : IHttpModule
{
public void Execute(HttpListenerContext context)
{
/* Do Something Special */
}
}
When an HttpModule is discovered I would typically add it to a Dictionary<string, Type> object who's sole purpose is to keep track of which modules we know about. This dictionary would typically live in my variety of a Singleton which takes on the persona of an ACE style Singleton (a legacy from my C++ days where I learned about Singletons).
Now what I am trying to implement is something similar using (my understanding of) general IoC concepts. Basically what I have is an AppService collection where IAppService is defined as:
public interface IAppService : IDisposable
{
void Initialize();
}
And my plug-in AppService would look something like:
[AppService("Plugins")]
internal class PluginAppService : IAppService, IDictionary<string, Type>
{
/* Common IDictionary Implementation consisting of something like: */
internal Type Item(string modName)
{
Type modType;
if (!this.TryGetValue(modName, out modType)
return null;
return modType;
}
internal void Initialize()
{
// Find internal and external plug-ins and add them to myself
}
// IDisposable clean up method that attempts to dispose all known plug-ins
}
Then during service OnStart I instantiate an instance of AppServices which is locally known but passed to the constructor of all instantiated plug-ins:
public class AppServices : IDisposable, IDictionary<string, IAppService>
{
/* Simple implementation of IDictionary */
public void Initialization()
{
// Find internal IAppService implementations, instantiate them (passing this as a constructor parameter), initialize them and add them to this.
// Somewhere in there would be something like
Add(appSvcName, appSvc);
}
}
Our once single method implementation becomes an abstract implementation + a constructor on the child:
[HttpModule(/*Some property values that matter */)]
public abstract class HttpModule : IHttpModule
{
protected AppServices appServices = null;
public HttpModule(AppServices services)
{
appServices = services;
}
public abstract void Execute(HttpListenerContext context);
}
[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : HttpModule
{
public SimpleHttpModule(AppServices services) : base(services) { }
public override void Execute(HttpListenerContext context)
{
/* Do Something Special */
}
}
And any access to commonly used application services becomes:
var plugType = appServices["Plugins"][plugName];
rather than:
var plugType = PluginManager.Instance[plugName];
Am I missing some basic IoC concept here that would simplify this all or is there really a benefit to all of this additional code? In my world, Singletons are simple creatures that allow code throughout a program to access needed (relatively static) information (in this case types).
To pose the questions more explicitly:
Is this a valid implementation of a Factory Singleton translated to IoC/DI concepts?
If it is, where is the payback/benefit for the additional code required and imposition of a seemingly more clunky API?

IoC is a generic term. Dependency Injection is the more preferred term these days.
Dependency Injection really shines in several circumstances. First, it defines a more testable architecture than solutions that have hard-coded instantiations of dependencies. Singletons are difficult to unit test because they are static, and static data cannot be "unloaded".
Second, Dependency Injection not only instantiates the type you want, but all dependant types. Thus, if class A needs class B, and class B needs class C and D, then a good DI framework will automatically create all dependencies, and control their lifetimes (for instance, making them live for the lifetime of a single web request).
DI Containers can be though of as generic factories that can instantiate any kind of object (so long as it's properly configured and meets the requirments of the DI framework). So you don't have to write a custom factory.
Like with any generic solution, it's designed to give 90% of the use cases what they need. Sure, you could create a hand crafted custom linked list data structure every time you need a collection, but 90=% of the time a generic one will work just fine. The same is true of DI and Custom Factories.

IoC becomes more interesting when you get round to writing unit tests. Sorry to answer a question with more questions, but... What would the unit tests look like for both of your implementations? Would you be able to unit test classes that used the PluginManager without looking up assemblies from disk?
EDIT
Just because you can achieve the same functionality with singletons doesn't mean it's as easy to maintain. By using IoC (at least this style with constructors) you're explicitly stating the dependencies an object has. By using singletons that information is hidden within the class. It also makes it harder to replace those dependencies with alternate implementations.
So, with a singleton PluginManager it would difficult to test your HTTP server with mock plugins, rather it looking them up from some location on disk. With the IoC version, you could pass around an alternate version of the IAppService that just looks the plugins up from a pre-populated Dictionary.

While I'm still not really convinced that IoC/DI is better in this situation, I definitely have seen benefit as the project's scope crept. For things like logging and configurability it most certainly is the right approach.
I look forward to experimenting with it more in future projects.

Is the Singleton design pattern built into any frameworks?

Using a Singleton class guarantees one instance of a class to give control to the programmer. Really useful.
I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?
Would be handy to decalre:
public sealed class MySingleton : ISingleton //or a different class
{ ... }
And then expect the class to only ever be instantiated once.
Is this a good idea, or am I thinking a bit off the mark? :)

I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?
It doesn't and can't exist. A singleton basically requires a static Singleton getInstance() method, but because it's static, it cannot be definied as an abstract (interface) method. It also makes sense, there can be only one singleton implementation, not multiple. Abstracting it is pointless.
You'll need to boilerplate complete singletons yourself. I however highly question how that's useful. It's certainly not its sole purpose to prevent stackoverflow or memory errors. Writing good code prevents that. Singletons are only useful if you want to have the enduser to deal with the same instance all the time. Which can be done as good without the singleton pattern by the way. Either just declare it static or make use of the "application scope" concept the average framework can provide you.
Instead of singletons, rather look for inversion of control (dependeny injection). That's by the way also exactly what Spring is doing. They do not use "pure" singletons. It was a poor word choice they made.
See also:
Singletons are evil
Patterns I hate #1: Singleton
Inversion of Control and Dependency Injection pattern
A Spring Singleton is not a Singleton

Singleton does not prevent stack overflow, not sure what you are getting at with that.
For Java, what came to mind is Spring. By default, every Spring bean you write is a singleton. You can use it in 100 places, and they will all be set automagically via injection, and all 100 references will go to the same object (i.e. a singleton). When you set up a project in Spring, you can make any class you want a singleton just by following the conventions.

Google Guice is a dependency-injection framework that supports a #Singleton annotation.
Note that classes annotated with #Singleton aren't "true" singletons - there's nothing stopping client code from creating many instances of such a class. However, Guice-managed dependencies will all share the same instance.
See http://code.google.com/p/google-guice/wiki/Scopes

Maybe not what you're looking for, but here's my favorite version of the singleton pattern in C#. It's thread-safe, uses lazy instantiation, and doesn't require any locks. It's also pretty painless to write... no frameworks needed. ;)
class MyClass
{
// ...
#region Singleton pattern
private MyClass() { }
public static MyClass Instance { get { return Singleton.instance; } }
class Singleton
{
static Singleton() { }
internal static readonly MyClass instance = new MyClass();
}
#endregion
// ...
}
To get the object instance:
MyClass m = MyClass.Instance;

In Java you can do this simply with an enumerated type. You specify the number of instances so that there can be none (also called a utility class), one (also called a singleton) or more as you choose.
public enum MySingleton {
INSTANCE;
}

.NET 4.0 has the Lazy(T) Class, which will lazily-initialize a value on first access, in a thread-safe manner. There are lots of examples at the Lazy Initialization topic.
Also, if you are using Unity, there is a lifetime manager which you can configure with the ContainerControlledLifetimeManager to ensure a single instance.

Ruby has a module called singleton that makes the class which includes it a singleton. This module is built into the standard library.

The intention behind the singleton pattern is "Configure once. Use multiple times". This is typically used to share any kind of data or resources as mentioned in one of the answers above. But it is also useful to enable any kind of "management" application. (think JMX if it is Java)
You have one instance of a certain class that you can use multiple times. Since there is only one instance, by configuring that instance appropriately, you can reflect the configuration changes across the app. Hence the singleton pattern gives the ability to enable a "management dashboard" to your app.
Spring or Spring.NET (the .NET implementation of Spring) are useful for configuring and injecting singletons. The same arguments apply for any kind of dependency injection framework. You should read about dependency injection in general to harness the full power. A true singleton, across multiple JVMs or clusters, is usually harder to create and manage. and might require tool support. In practice, it is not necessary to create and maintain that.
Don't confuse singletons with statics! The construct looks similar but it can be pretty different. Now to drum my own trumpet! Here is a link to an article that I had written about static methods.

public class Singleton<T> where T : class, new()
{
static class SingletonCreator
{
internal static readonly T instance = new T();
}
public static T Instance
{
get
{
return SingletonCreator.instance;
}
}
}
It is lazy and versatile. Define constructors on demand.

How to mark .NET objects exposed to COM-interop as single threaded?

When defining a COM-visible class in C++ I can define the supported threading model in the header file (the threading(single) line):
[
coclass,
default(IComInterface),
threading(single),
vi_progid("Example.ComClass"),
progid("Example.ComClass.1"),
version(1.0),
uuid("72861DF5-4C77-43ec-A4DC-ED04396F0CCD")
]
Is there a comparable way of setting the threading model in .NET (for example an attribute)? I currently define my COM-class as such:
[Guid("67155A91-2948-43f5-B07F-5C55CDD240E5")]
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IComInterface
{
...
}
[Guid("DC5E6955-BB29-44c8-9FC0-6AADEEB2AFFB")]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Example.ComClass")]
public class ComClass : IComInterface
{
...
}
--edit:
The comments on the marked answer are the really important thing. It seems like the only way to tell RegAsm to set a different ThreadingModel is to write a custom registration method marked with the [ComRegisterFunction]attribute.

That's really obscure, I've never seen the "threading" attribute in MIDL. Nor have the MSDN Library authors.
A COM coclass publishes its threading requirements in the registry, using the HKCR\CLSID\{guid}\InProcServer32 key. The ThreadingModel value declares the apartment it needs. If it is missing or is set to "Apartment" then is announces that is not thread-safe and requires help from an STA thread. CoCreateInstance() uses this value when it creates the object. If necessary it will start an STA thread and create a proxy if the current thread is not STA, ensuring it is always used in a thread-safe way.
A [ComVisible] .NET class will be registered as "Both", indicating that it is okay to be used on a thread in the MTA. Pretty optimistic, but follows the .NET philosophy that everything is thread-unsafe but can be made safe by putting the lock keyword in the right places. A promise that is not often tested btw, risky. Overriding the ThreadingModel value (or omitting it) requires writing code to register the coclass yourself, decorated with the [ComRegisterFunction] attribute. RegistrationServices.RegisterTypeForComClients() can be useful to get the basic keys into place.