How not to do Dependency Injection

Dependency Injection (DI) is not a new concept and has been discussed, blogged, and published many times.  There are a huge number of books out there on the subject.  I've seen many usages and implementations of it used by various clients I've consulted for. 

Like the author of the blog post I refer to below, one of the most common and mis-used, abuses of, and antipatterns I've seen is the wrapping of the DI model in a static container.








I recently found an excellent article that explains in great detail why this is a bad idea and a big anti-pattern - http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container.

Hopefully, this will help improve your understanding of what DI is and how it should not be used.

Don't implement GetHashCode() on mutable fields/properties

CodeProject You shouldn't ever implement GetHashCode on mutable properties (properties that could be changed by someone) - i.e. non-private setters.   I've seen this done in several places and it results in very difficult to find bugs.

Here's why - imagine this scenario:

1. You put an instance of your object in a collection which uses GetHashCode() "under the covers" or directly (Hashtable).
2. Then someone changes the value of the field/property that you've used in your GetHashCode() implementation.

Guess what...your object is permanently lost in the collection since the collection uses GetHashCode() to find it! You've effectively changed the hashcode value from what was originally placed in the collection. Probably not what you wanted.