ThoughtShapes - DotNet - Comments

It's coming.

Anonymous — Sat, 22 Nov 2008 21:16:14 -0500

It's coming.

Sweet! Thanks!

jay — Wed, 31 Oct 2007 14:34:09 -0400

Sweet! Thanks!

You sure do get it Jay. But

Rjae Easton — Wed, 31 Oct 2007 14:26:52 -0400

You sure do get it Jay. But I kinda already knew that.

I am thrilled that the post was so timely and helped.

I hope you don't mind, but I

Rjae Easton — Wed, 31 Oct 2007 14:25:35 -0400

I hope you don't mind, but I replaced <code> with <pre class="code cs"> to retain your formatting.

sorry for the formatting of

jay — Wed, 31 Oct 2007 13:16:00 -0400

sorry for the formatting of the code.
There were spaces there when I hit post :P

I get it! So I must admit

jay — Wed, 31 Oct 2007 13:14:00 -0400

I get it!
So I must admit that the terms Closure and lexical context threw me off at first. But when I replaced them with Scope and Stack (and happened to be using something like this in a unit test I was writing) it coalesced for me.

My example was this:

[Test]
public SomeWorkRelatedUnitTestIWasWorkingOnThatTestsThreadSafetyOfACertainCall()
{
      // Some Mocking initialization goes here
      //....

      List autos = new List();
      for (int i = 0; i < 1; i++)
      {
          autos.Add(new AutoResetEvent(false));                
            ThreadPool.QueueUserWorkItem(
                delegate
                    {
                        myWorker.InitializeProcessors(true, mySettings);
                        autos[i].Set();
                    });
       }
       WaitHandle.WaitAll(autos.ToArray());
       myMocks.VerifyAllExpectationsHaveBeenMet();
}

When I ran my test I was getting an exception at the autos[i].Set() call. at this point i was 1, when I expected it to be 0. I remember reading this post this morning and hopped on back to see what I was missing.

Rjae's words (once I understood them) were exactly what was happening to me. i was continuing to increment while the work was being done, because the delegate has a view into the scope that i lives at.
When I switched to something like:

[Test]
public SomeWorkRelatedUnitTestIWasWorkingOnThatTestsThreadSafetyOfACertainCall()
{
     List autos = new List();
     for (int i = 0; i < 1; i++)
     {
         int anotherI = i;
         autos.Add(new AutoResetEvent(false));                
           ThreadPool.QueueUserWorkItem(
              delegate
                    {
                        myWorker.InitializeProcessors(true, mySettings);
                        autos[anotherI].Set();
                    });
      }
      WaitHandle.WaitAll(autos.ToArray());
}

It really became clear to me what Rjae was saying. It's almost like a delegate gets it's own "local(ish)" storage.

Thanks Rjae for the timely post!

The Monostate design pattern

Rjae Easton — Mon, 30 Apr 2007 10:37:26 -0400

The Monostate design pattern takes the general form:

public class ClassName
{
    private static int theStaticState = 0;

    public virtual int StaticState
    {
        get { return theStaticState; }
        set { theStaticState = value; }
    }
}

The type itself is not limited to a single instance but its state is. In this way the benefits of polymorphism are protected (no pun intended ;-).

I should add that there is

Rjae Easton — Mon, 30 Apr 2007 10:19:52 -0400

I should add that there is another way for a MarshalByRefObject to indicate infinite lifetime. Return null from InitializeLifetimeService as in:

public override object InitializeLifetimeService()
{
    return null;
}

Unless your object needs control over sponsor and renewal lifetime it is best to use this approach.

I'd like to point something

Steve Seymour — Fri, 27 Apr 2007 10:15:13 -0400

I'd like to point something out that might not be obvious to all readers. In Rjae's post you'll notice that he doesn't provide the code for the types he mentions (Message and MessageRepository) but instead provides the test fixtures that test these types. This is a very important, conscious (and I believe totally correct) decision he must have made and it emphasizes what we practice: The tests are the most important thing in the code. I say "must have made" in the previous sentence because I normally don't like making assumptions about another's thoughts, but I do know the way Rjae thinks in regards to this area and I also know his thoughts totally jibe with mine.

One perspective in particular to try to grab hold of is to look at the test fixture method names. When I read the test method names I gain an instant understanding of what the behavior of the CUT (Class Under Test) is. I therefore gain a much quicker understanding of the class than I would if I was looking at the actual code for the class. I'm not sure how obvious this is to readers, so I think it's worth mentioning. Even if you're only developing a class library for a client, it's a good idea to ship all the tests with the code. I know that if I hire someone to create a library for me I'd be giddy if they give me all the tests. (This is really not true, but only because I'd expect all the tests in advance--since that would be part of the contract with the library writer. If I didn't have such a contract, then I'd be giddy.)

And, as I've said before and will say again, this is why the tests serve as the documentation.