ThoughtShapes Shaping Ideas With Thought

What do you call a Singleton that does not prevent more than one instance from being created? I call it confused. That is precisely what I was upon discovering the default effect of WellKnownObjectMode.Singleton in .NET Remoting. As I worked around this default behavior I realized my discovery and solution would be useful to others. This post discusses the differences between Singleton and Monostate, proves why a Remoting Singleton is Monostate by default, and shows how to design a true Singleton for .NET Remoting. It also includes several unit-testing tricks along the way!

I am happy to announce forthcoming improvements to the ThoughtShapes site. The most significant change is that we are migrating from WordPress to Drupal.

Rjae, Rob, and I will be featured guests at an upcoming TDD event. The details are here.

Rjae and I are up to 2025 tests on the project we're working on together. As you can see in the image of VStudio below, they run in 25 seconds.

Adherents to Domain Driven Design (DDD) often struggle with how to structure the “layers” of their application with respect to where object repositories should be placed. As usual in software development the answer to this quandary is “It depends”. In this posting I’ll discuss several things that should be taken into consideration when making this decision.

Repeat after me: Interfaces and OO are my friends.

In the interest of releasing early and often I list the most helpful timesavers I know. Almost every day brings a new timesaver, so subscribe to this post - it will be updated as new tricks are discovered.

Static methods are like the song of a siren--enchanting but dangerous. I remember flirting with this danger in days of yore, but I've since learned to resist their temptation. Why do I no longer fall for their lure?

This is a TDD technique in which those "TODO:" comments you sprinkle in your code begin to dissolve away. Here is how it works:

If I had to list one of the more important rules of software development to follow, I would list "Don't Repeat Yourself" near the top. A developer should strive with all her might to avoid duplicate code because:

• Duplicate code weakens the system because its existence gives birth to multiple points of error in regards to the same functionality.
• Duplicate code is wasteful code; other things can be done instead of writing the same functionality again and again.