CuriOddities (part 2) [Kit George]

This week’s Curioddity is a result of the way some things in the framework work. I think many of you are going to know the underlying issue here, so I’m going to make it a bit more obscure (not give too much help) to try to keep it interesting.

I would assert that the developer of the following code has a certain expectation about the code, but they’ve made an assumption about what happens when this code compiles (which will be wrong). The questions I have are 1) what is the expectation I’m alluding to (that’s the game part!), and 2) do you think what the framework is doing ‘behind the scenes’ is the right behavior?

Reminder: If you’re wondering what I’m getting at, I have made it slightly obscure, but the nature of the members is the key.

[Visual Basic]

Public Class KTC1

     Public Shared Sub Foo()

     End Sub

     Public Shared Sub Bar()

     End Sub

     Public Shared Sub Zod()

     End Sub

End Class

Comments (5)

  1. Anonymous says:

    My assumption is that the deveoper is assuming they have created, essentially, a singleton class as all the members are Shared (static). The framework behind the scenes (should that be compiler?) has created a public constructor so even though the members are all Shared there can be multiple instances of the class itself.

  2. Anonymous says:


    Well, I am certainly confused. Give us more of a clue.



  3. Anonymous says:

    Richard is right on track with his observations. Try out what he’s asserting, by making a client which would instantiate the class.

  4. Anonymous says:

    Of course, if you’d been using FxCop, it would have whacked you upside the head and told you to add a private constructor.

    And once you’d done that, it would’ve whacked you upside the head and told you to make this a sealed class.

  5. Anonymous says:

    So yes indeed, fxcop would whack you around on this item, highlighting the usefulness of fxcop. But the very fact that this compiles highlights that we can make better diecisions with regards to making more intelligent decisions and get better help, when desiging classes. A reason that you can now make static classes in C#.

    To put it in better persepctive, consider the reverse fo the above:

    Class Bob

    private Sub New()

    End Sub

    public Sub Foo()

    End Sub

    End Class

    How are you going to instantiate an instance of Bob, such that you can use the Foo method? Believe it or not, we actually shipped an API in V1 with this mistake in it (to our shame).

    I would argue that relying on tools, even VS integrated tools, is not sufficient for these scenarios, the compilers need to point out the mistakes to you. The earlier you spot the problem, the better.