Prevent Class Instantiation directly

Apr 3, 2014 at 3:46 AM
I am using Unity for class resolution on a large project. We are using interception to apply certain functionality that we want across numerous classes. The problem I am encountering is that new developers are coming along and creating instances of classes directly and not by resolving them through the unity container. As a result they are not getting the functionality that occurs in the interception.

I thought about making my classes abstract but that doesn't work as unity doesn't support that.

Does anyone have any advice or suggestions on how I can prevent users from creating classes directly and force them to use the unity container.

Any helpful suggestions welcomed, apologies in advance if I've not been clear about my problem, I'll endeavor to clarify as necessary.
Apr 3, 2014 at 5:52 AM
Your question is clear however I don't think there is a good technical solution to your concerns. I guess you could create private constructors and have the container use a factory with reflection to create the objects. This would prevent newing up the objects directly but is horrible on so many levels.

Here are some things that I would do in your situation:
  • Documentation/Standards giving examples of good and bad approaches
  • Education -- some verbal followup on the standards while discussing application design/walk-through etc. (it can be overwhelming for new developers sometimes so a reminder couldn't hurt)
  • Code Reviews
  • Custom code analysis rules (e.g. FXCOP) that helps notify of any potential issues
  • Try to code to interfaces to minimize the temptation to pass in concrete types
You might think about doing some checking to make sure types are properly intercepted in methods (base types, marker interface added by Unity) where you expect them to be but that strikes me as bad design.

Randy Levy
Enterprise Library support engineer
Support How-to
Apr 4, 2014 at 4:18 AM
Thanks for your helpful response, I'm not sure I quite followed your factory / reflection suggestion but it sounds like it would be rather unpleasant.

One element I had omitted was that we are retrofitting unity to a large existing solution, I was hoping to find a solution that would essentially prevent the code from compiling until I had fixed all direct references to classes that I only wanted to resolve using unity.

I guess I'll just have to do it manually, possibly there is something I could do in reflection as a kind of report.........
Apr 4, 2014 at 5:27 AM
I think that a custom code analysis (or FXCOP) rule could cause compilation to fail based on the custom conditions. A quick search online doesn't show a lot of resources so I'm not sure how much time you want to spend on that.

In general, you could probably use an internal (or protected internal) constructor and add the InternalsVisibleTo attribute to the assembly indicating who (outside of the assembly) is allowed to invoke the constructor. However, I don't think this will work with Unity since Unity will not be able to create the object.

I'm not sure about the design but if you go with a composition root where the entire object graph is injected then there should be no need to create any objects (at least ones you want to intercept) that are not injected. I know you mentioned you are retrofitting so there are probably a lot of things that would be nice to change but are already implemented in an inconvenient way.

Randy Levy
Enterprise Library support engineer
Support How-to