gregoryyoung is the Page Editor for the C# and DotNET topic areas. This article continues his series on design patterns. To read more, see his blog.

Nearly every programmer learns the singleton as their very first design pattern partially due its simplicity and partially to it being the first one listed in nearly every basic pattern book. It is a good introduction to the concept of design patterns and immediately people will have places within their own code to experiment with their new knowledge.

//Singleton implementation in C#

//Singleton implementation in VB.NET

Looking at the singleton from a life cycle perspective, the first method to be called is guarenteed by the CLR to be the static constructor for the type which sets the internal instance to be an instance of the singleton class. It is important to note that the constructor for the object is marked private; this ensures that the object cannot be created externally to the singleton itself. A client seeking to access the object is forced to use the static Instance property which will always return the same instance to the caller. Thus the singleton has insured that only a single instance of the object can exist. There are two major design flaws that come up with the singleton and if not carefully implemented they can become a nightmare of a change.

1) The item which was deemed to have a maximum count of 1 and now it has a maximum count of N. Imagine a simple application that talks to a 68040 embedded system. At the time of production there is only a need for a single serial port interface so it is implemented as a singleton, but later the requirements change and multiple serial ports are needed. This problem is further made worse by the fact that when we change to having multiple objects we will likely also want to change to having multiple CONCRETE objects -- in other words we would no longer want to deal with our singleton as a concrete type but as an abstract type. An example would be if we wanted to support serial communications and IR communications with similar but functionally different protocols. Since the singleton is bound to the concrete type the move to an abstract type will cause futher issues.

2) The application changes to require multiple application domains. I see this one on a regular basis with people using the singleton pattern in ASP.NET. They develop their application in a single ASP.NET instance and then run into problems with their singleton when they move to production. The way IIS works with ASP.NET is that it starts 1..N processes running your application, and the more processes you have, the more concurrent requests you can handle. If you remember the singleton is scoped to the application domain so it is not shared between these processes. In order to share the singleton you must use a singleton that is housed in another process that the processes share -- for instance using a networked singleton through remoting.

The major problem with both of these problems is that depending on how your singleton is being used you may have MANY places that will require a change to simply make it support either multiple objects in the first case or a networked object in the second case. The reason for this is the fact that the singleton's instance method is bound to the type ex: Singleton.Instance. This will force us to change any code that is directly accessing the instance in such a manner. This is extremely important when dealing with libraries, since a simple change such as making a singleton a networked object could feasibly bubble out to every application using the library as well as the library itself.

One can help alleviate the number of places that need to be changed by passing the singleton into methods as opposed to having the methods call the singleton directly.

vs.

But alas, this causes many problems as well. For example you are nine levels deep into method calls when you realize that you need an instance of the singleton to perform a task. At this point you are left with two choices: you can either pass the singleton through those nine levels of methods (changing their method signatures and breaking countless other areas of code) or you can call the instance property on the singleton type directly which will lead to future problems as discussed above.

For a reasonable answer as to how to avoid these design nightmares in our future we need to analyze exactly what a singleton does for us and how it does it.

1) The singleton guarentees that only a single instance of an object will be created by encapsulating the creation of the object in a private scope.
2) The singleton pattern includes a static factory method which allows us access to the internal instance.

Given that the singleton is actually a specialized factory method, what would happen to our system if we were to add a level of indirection by putting a factory method in front of our class?

It is important to note that another method of obtaining a similar result is to make the singleton a normal object with an internal constructor and make the factory method actually construct it and maintain the instance. The only difference in functionality between having a true singleton and a factory which acts as a singleton is the private constructor on the object, which completely prevents any other instances from being created. If the class is internal to a library and a level of discipline can be maintained by the development team, this is often a much better approach. Also, the contextual variable is not always necesary or available but if required and identifiable should be created at the time the factory is created.

This will give us substantially more flexibility and isolate us from sweeping changes in our code base. The best part is that there is no functional difference between this and the singleton implementation we looked at earlier, yet we have removed the coupling between the singleton and the singleton type. We can now call the singleton factory wherever we want and not have to worry about passing the singleton through large amounts of code in order to use it (although in many cases it is a good practice to do so if contextual boundaries are not being crossed, as the future factory method has an unknown overhead associated with it).

This is a common case where thought ahead of time can help reduce the impact of change later. As we all know change is often times a project (or even a department) killer, the best way to keep it from killing you is to plan ahead for possible changes and isolate the scope of their effect.

Greg Young

A recent study by Booz Allen Hamilton says that most organizations are unhealthy with respect to how they adapt to a changing environment. The study is based on responses from about 50,000 people, most of them respondents to a brief online survey.

A while back, gregoryyoung wrote a column for this newsletter that talked about what he called "anti-patterns" -- "...well-documented and commonly-made mistake[s] for which there are known solutions." Greg's article dealt primarily with larger organizations, but what is apparently the case is that the same issues that afflict larger organizations also show up in smaller ones.

The hypothesis behind the study is old news; Max Weber, the German sociologist, wrote in the 1920s that organizations become both oligarchical and conservative, both of which are impediments to fundamental (or even incidental) change. What makes the Booz Allen Hamilton study interesting is that first, it statistically demonstrates its thesis (as opposed to using anecdotal data), and second, it suggests that the anti-change behavior of organizations is detrimental to their self-interest.

But what makes one really sit up and take notice is this: "The ability to execute, like health, is not something you can hire or mandate. It is inherent, embedded in the organization's "genes," and expressed in the thousands of individual decisions and actions that collectively constitute and define firm performance. The first step in resolving execution breakdowns is to understand how these inherent traits of an organization influence and, in some ways, even determine how each individual thinks and acts on the job. That behavior is what drives results."

In other words, it's not enough to simply prepare a mission statement, or require adherence to a set of processes or standards; from top to bottom, the relationship of the individual to others in the organization and to the whole of the organization matters. More to the point, the perception of how the individual views his relationship with others and the organization can determine not only how well the individual will function within the organization, but indeed, whether the organization will become, to use Booz Allen Hamilton's term, "marginalized."

Some of the points made along the way are priceless; for example, "...our most salient finding is a very simple and sobering one: Most organizations, by their own employees' admission, are sick." It's hardly surprising to find that a good percentage of the sample universe would think that there are things that need fixing; what's remarkable is that half of the people who took the survey feel that way. More remarkable is the implied opinion that they're powerless (or think they're powerless) to do anything about it.

So what makes an organization unhealthy?

First, individuals aren't clear on what their decision rights are. In other words, they don't know if something is their responsibility or not, and rather than take the chance that they're wrong by making a decision, they'll leave it for someone whose responsibility they're certain it is. Organizations without clear decision rights are also characterized by a lot of second-guessing.

Second, unhealthy organizations are characterized by a lack of free-flowing information required for making good decisions. In other words, "I'm scared to death that I'm making a decision without knowing all of the relevent information." Just as importantly, individuals don't understand the context of their decisions; the reason behind telling a customer that he can't have his sausage with breakfast could be that the sausage didn't get ordered (which means the bacon is fine) or that the walk-in refrigerator broke down (which means one should consider eating toast). It might not be the server's job to tell the customer the details, but it certainly should be someone's job to tell the server.

Third, the bigger an organization is, the more likely it is to be unhealthy. This one is almost self-evident; there's a good reason that Windows Vista has taken so long to develop, and will take another year before it actually gets sold to anyone. It's also the same reason that a good number of people don't see any compelling reason to purchase Microsoft's new operating systems -- which just marginalizes Microsoft even more than its slow decision-making processes with respect to the development of a new operating system. It's a lot easier to turn a canoe than it is to turn a yacht, but compare either to a battleship.

Finally, upper management is clueless as to an organization's health. Okay, that's a bit of an exaggeration, but what is true is that upper managers generally seem to think their organziations are more healthy than they really are. "... it becomes clear," the study says, "that not only is senior management out of touch with the rest of the organization, but they don't know what they don't know." Part of that, one suspects, is that upper managers are frequently insulated from the rank and file; but another part is that upper managers only pay lip service to the first two issues raised.

Take the survey and let us know if you think it's actually accurate.

<Off topic>: Peter Drucker, whose writings on the management -- and mismanagement -- of companies around the world are one of the standards by which such work is measured, died November 11. He will be missed.

AnnieMod is the Moderator responsible for managing the process of cleaning up abandoned questions at Experts Exchange.

I've been thinking about writing this for a few months, and I always decide that it is not needed. But it is.

Very often I see askers and experts mad at the Cleanup Volunteers. That is why I'm writing this -- they deserve "thanks" and not yelling and insults.

A few years ago no one was taking care of the questions which were left unclosed by the Askers. The Moderators decided to start closing these and now, a few years later we have a process. Cleanup has its good and bad moments but it works; Experts get the points they've earned.

The process:

Every Cleanup Volunteer receives a range of questions in a given area. Their responsibility is to:

• identify the abandoned question in the range (a question is considered abandoned if it has no comments in the past 21 days)
• if appropriate, 'ping' the question. He leaves an official message to the participants that the question is in Cleanup and a recommendation will follow in four to seven days (This depends on the CV. He can even give two weeks -- it depends on the area, the CV, and the circumstances of the question).
• post a recommendation in abandoned questions. This is an official message that the question will be closed in four days in a certian way and this is the time when any Expert, including the Asker, is welcome to comment and disagree. If the question is pinged, we would expect that you will voice your opinion before realising you lose the points

Once this is done, the CV posts the list of his range for the Moderators and four days later, the questions are closed.

The problems:

When we begin the process, there is a common range of problems:

The Asker needs the question to stay open for a while longer.

This is okay. Just make sure you post some new information every two weeks. But if someone posts "hello" every few weeks so we do not close the question, we will close it.

"You cannot delete the question because we posted here - just split the points"

Sorry, but it does not work like this. If the question is not worth saving to the PAQ, and there is no answer, it will be deleted, even if there are fifty Experts commenting. If there is no answer but we feel that there is good information, we will save the question but NO points will be awarded. The points in EE are awarded for answers -- but not for posts.

"Why do you clean here at the 22nd day but wait six months in another TA?"

CVs are volunteers and sometimes, in some areas, we simply don't have someone who has volunteered to clean up the topic areas. Other TAs just aren't that busy; the CVs go where to the busier TAs first, because that's where the most Experts and most abandoned questions are.

"I didn't get an answer and you did not return my points."

This happens most often because the Asker did not respond to the Experts. EE is based on collaboration. If the Asker fails to participate, we do not give the points back. It is not that hard to say "Thanks but this does not work because..."

How can you help?

If you are an Asker, please make sure you close your questions in a timely manner:

• If someone had helped - give them the points (or do a split if needed)
• If you had found the answer yourself, ask Community Support to close the question after you post the solution
• If no one had helped, ask Community Support to delete the question after you respond to all the Experts
• If you are not sure what to do, ask the Page Editor (you can write to them at <username>@experts-exchange.com) for the area or ask Community Support

If you are an expert, make sure you pay attention to the pings and recommendations. And we will be very thankful if you educate the users when you see that they want to close the questions but have no idea how.

If you want to help as a CV, mail me at annieMod@experts-exchange.com and give me a few days to answer. (If I don't respond in a day or so, mail me again -- sometimes some mails go in the Trash and I just miss them although I check it regularly).

Thanks to all the Askers who close their questions promptly, thanks to all the Experts who help the users, and thanks to the unsung heroes of EE -- the CVs. You make this great site better.

AnnieMod
Cleanup Admin

I have a dream... in which the guys who write viruses that cause my inbox to get filled up with garbage are ... never mind. I really do try to be a lady most of the time.

But this latest strain of the Sober worm has done pretty much what it was expected to do -- make me dread clicking on the icon that opens my email. It's not that I'm really THAT worried, because most of my email goes through at least three levels of protection (one at EE, one at my ISP, and one at my computer). But the problem is just the sheer volume of it all.

The Moderators have it much worse, from what I gather. Someone out there has the Mods' group address at EE in their address book, and they're getting hundreds of spam emails every day. Maybe it will finally get bad enough that someone will invent a program that automatically floods an IP address with email if the person behinds it sends out spam; it would certainly make me sit up and take notice if I got a million emails saying "Clean the virus off your computer, you idiot!!"

Oh, and lest you think this latest strain of Sober is just another passing fancy, Symantec says that the worm will try to download a file on January 5, 2006, if you computer isn't protected. I used to have a hard time believing anyone would surf the Internet or get email without being protected, but the last couple of weeks have shattered that illusion.

C'mon, people.