Sometimes i think I spend my time on this blog just trying to explain the thinking of people much smarter than me.  This is definitely one of those cases.  I've probably learned more about programming from reading the Retlang source code than any other.  It's both remarkably free of compromises and easy to read.  Sometimes you learn not from any individual snapshot, but from the evolution of the code base.  For instance, here was the process context factory in Retlang 0.3: public interface IProcessContextFactory : IThreadController, IObjectPublisher { ...

I have to admit, when I read Uncle Bob’s post about dependency injection, I really didn’t expect the response it would get since it struck me as being relatively uncontroversial.  So Davy’s reaction rather surprised me.  Davy had two major objections to the original article: The contention that IoC containers aren’t always appropriate. The advocating of the use of abstract factories. Now, when I teach constructor injection to developers around my company, I always teach it in the manner Uncle Bob describes: just pass things into the constructor.  Sooner...

I wanted to write something about the concept of a "configuration class", which Emanuele touched on in a discussion about the singleton pattern.  Let me start by explaining what I mean by a configuration class.  It's a relatively common "pattern", although you'll never find it in any books.  I'm going to argue that this is because, like Singleton, it's the wrong solution to the problem. The Problem .NET has an incredibly flexible XML-based configuration API.  However, for the purposes of this discussion, we can concentrate on the bit that most developers use: AppSettings.  This is basically just a string hashtable with delusions...

When we looked at the Open / Closed principle, we saw that certain practices produced fragile code. Static Methods Non-virtual methods Creating objects Too-specific variable declarations Hard-coded values Using the wrong object (the Law of Demeter) Of these, the first three are all things you can't override.  If you can't override things, they're inflexible and, inevitably, will cause problems.  In the cases we've seen, the Law of Demeter problem could be solved just by using the right object in the first place.  Equally, a non-virtual method is easy to fix, you just make it...

Okay, we're onto the first of what I described as the "stone cold brilliant patterns".  This particular one looks obvious, but its benefits are actually quite subtle.  There are basically only two ways of creating an object in .NET: Call new Call a function that calls new The factory pattern is basically just using the latter.  Now, this might strike you as an unnecessary level of indirection, and you might be right.  You'd be right if: The class is a pure data transfer object. The class doesn't have a complex data structure. The class has...

Mauricio Scheffer asked how AutoGen differs from the TypedFactory Facility already in Castle.  (An equally valid question is why the code is five times the size.)  The answer is that it doesn't in essence, but it does in detail.  However, the details matter, in that AutoGen addresses common use cases, whereas the TypedFactoryFacility is only going to save you 6 lines of code.  The principal differences are: Configuration Constructor Arguments Handling Keys Disposal Handling Multiple Methods How TypedFactoryFacility is used Let's take...

I recently published a tool called AutoGen for Castle.  You can check it out at Google Code.  In essence, it auto-generates factory objects for you and adds them to your container.  This is an extremely useful thing to be able to do.  I do, however, find it a bit hard to explain, so bear with me. A relatively good rule of thumb these days is that a class should instantiate objects or do something with objects but never both.  Miško Hevery has written a lot of good stuff on this subject, and I don't propose to mangle his thinking here. ...

I can't be the only one glad that the Google Testing Blog has become active again (and I don't mean "we're having a conference on another continent" style posts, much as I eagerly await those missives.  But this post has actually crystallized my understanding of one aspect of designing for testability.  There are probably some who will regard this one as old news.  It is, however, pretty fundamental.  To summarize, it says that any given class should either create objects or use them.  So, let's assume most of your objects are constructed using auto-wiring of dependencies.  We can ignore cases...