Default Instances...

(I just seem to be full of controversy lately…)

If you aren’t familiar with what Default Instances are, let me show you an example prior to explaining it.

Sub Button1_Click(Byval sender As Object, Byval e As EventArgs)
  Dim dialog As New Form2()
  dialog.Show()
End Sub

In order to show a form in VB.NET (2003/2004), you have to create a variable that houses a reference to a newly created instance of the form. Depending on the scope of that variable, the reference may be local, module or global. To me, I see this as somewhat dropping the ball on the Rapid Application Development behavior that made VB (versions 1.0 to 6.0) so popular/successful.

Think about it from this perspective. I create a new project, open the form, drop some controls on it, name the controls, double click on the controls and write code associated with the events associated with those controls. At no point did I have to create a new instance of Form1 in order to have Form1 be displayed. Why should I have to do this for other forms that I create? Most of the time, those forms will be single instanced. Sure there are exceptions, but for the most part, this is the case. The reality is that each of these forms are either visible or not depending on the applications state.

What happened to the RAD mentality? We were doing so good up to the point of showing a secondary form.

Enter in Default Instances:

Sub Button1_Click(Byval sender As Object, Byval e As EventArgs)
  Form2.Show()
End Sub

Default Instances help to alleviate this problem. I don’t see it as being placed into Windows Forms for the sake of backward compatibility, although has a lot of similarities with VB 1.0-6.0, since they’ve been designed around the behavior of the .NET Framework (and Windows Forms). It’s there to solve a legitimate problem. It makes developing Windows Forms applications a whole lot easier and, in my opinion, is more logical and easier to read.

Now, I hear some people complaining that this isn’t OOP in concept, thus a bad idea. This is not to say that there might not be some gotchas, especially if you mix the two concepts. I’ve heard some people complain that they want a way to turn it off because it’s “bad programming”. I’m not sure how they classify it as “bad programming”, but as for turning it off, I have to disagree. I have to tell you, until I actually started playing with them, I was indifferent. Now that I have (and, yes, I tried to break them), I’m definitely in favor of them existing. It just makes sense from a RAD perspective. I shouldn’t have to worry about creating an instance, that extra work is taken care of for me. And… the model has been significantly improved over the classic VB style, so I don’t really understand how this could be a problem.

Even the potential problems that have been raised are very weak in my opinion and weigh far less than the benefits that Default Instances provide. Rather than take my word for it (or the word of the naysayers), give them an honest look-see for yourself. I might just come to the same conclusion that I have. If not, at least you’ve made the decision based on your own experience and not those of others.

As a side note, if you really, really don’t like them and want to “disable” them, I found a trick that’ll do it (by accident of course). I wouldn’t change your coding practice too much, but does definitely stop the feature.

Public Class Form2
  Public Sub New(Byval value As Boolean)
  End Sub
End Class

Sub Button1_Click(Byval sender As Object, Byval e As EventArgs)
  Dim dialog As New Form2(True)
  dialog.Show()
End Sub

By creating a parameterized constructor (without defining a parameterless one), this “breaks” the Default Instance feature for that form. You don’t really care anything about the value, so you can see I don’t do anything with it.