The constructor signature for AuthorizationChecker now looks like this:

public AuthorizationChecker(
    ISettingsStorageProviderV30 settingsProvider, 
    IAuthTools authTools, 
    IAclEvaluator aclEvaluator) { ... }

We can clearly see that AuthorizationChecker depends on implementations of ISettingsStorageProviderV30, IAuthTools, and IAclEvalator, but we are not concerned with the actual implementations. This is the dependency inversion principle at work.

"High-level modules should not depend on low-level modules. Both should depend on abstractions." – Robert C. Martin (http://objectmentor.com/resources/articles/dip.pdf)

In this case, AuthorizationChecker and AuthTools don’t depend on each other, but depend on the abstraction provided by IAuthTools. The same is true for AuthorizationChecker’s other two dependencies, ISettingsStorageProviderV30 and IAclEvaluator.

We have decoupled AuthorizationChecker from its dependencies. The question remains that AuthorizationChecker still needs these dependencies supplied at run-time to actually be able to execute. The simplest way to supply these dependences as default implementations via AuthorizationChecker's parameterless constructor:

public AuthorizationChecker() : 
    this(Settings.Instance.Provider, 
        new AuthTools(), new AclEvaluator()) {
}

Of Containers and Castles

A more flexible way to supply dependencies is to use an Inversion of Control container, such as Castle Windsor. Castle Windsor is a set of assemblies that we reference from our code. We simply register all of our dependencies in the container and then ask the container for an implementation. The container walks the dependency chain, creates objects in the correct order, supplying dependencies as it creates objects further up the dependency chain until it can finally return us a fully constructed object. Consider the following code:

var authorizationServices = IoC.Resolve<IAuthorizationServices>();

The IoC is a static gateway class that provides an abstraction so that your code is not dependent on a particular IoC container for retrieving dependencies. It is similar in interface and approach to Microsoft’s Common Service Locator available on CodePlex. You can read more about the IoC static gateway in “Loosen Up: Tame Your Software Dependencies for More Flexible Apps”.

In order for Castle Windsor to satisfy this request for an implementation of IAuthorizationServices, we’ll need to register the dependencies:

var ssp = ProviderLoader.LoadSettingsStorageProvider(
    WebConfigurationManager.AppSettings["SettingsStorageProvider"]);
container.Register(
    AllTypes.FromAssembly(Assembly.GetExecutingAssembly())
        .Where(x => x.Namespace.StartsWith("ScrewTurn.Wiki.Services"))
        .WithService.FirstInterface(),
    Component.For<IAclEvaluator>().ImplementedBy<AclEvaluator>(),
    Component.For<ISettingsStorageProviderV30>().Instance(ssp)
);

This code is located in the ScrewTurn.Wiki.Core assembly. Rather than manually configuring each dependency individually, we use a convention-based approach whereby any types in the ScrewTurn.Wiki.Services namespace are registered via their first interface. This means that AuthorizationServices is registered as IAuthorizationServices, AuthTools is registered as IAuthTools, and similarly for other types in this namespace. This has the advantage that by placing services in the ScrewTurn.Wiki.Services namespace, they will automatically be registered in the container without requiring explicit configuration. Other classes can then take dependencies on these services simply by adding the appropriate interface to their own constructor.

AclEvaluator is located in the ScrewTurn.Wiki.AclEngine assembly. Since it is the only dependency in this assembly, we register it explicitly. There isn’t a great deal of value from having a separate assembly for ScrewTurn.Wiki.AclEngine and I would consider merging the AclEngine project into Core. AclEvaluator could then be placed in the ScrewTurn.Wiki.Services namespace and auto-registered like the other dependencies. For the moment, AclEvaluator serves as an example of how to explicitly configure dependencies in Castle Windsor.

ScrewTurn Wiki has code that dynamically loads a particular ISettingsStorageProviderV30 implementation specified by a fully qualified class name in a configuration file. Although we could use Castle Windsor’s configuration facilities to configure and load the appropriate assembly and implementation, that is not the current focus. We can leverage the existing loading mechanism by supplying Castle Windsor with a fully constructed instance via the Component.For<T>().Instance(obj) syntax.

Windsor provides many more configuration options, including overrides, parameters, XML configuration, and more. You can find a lot more information on configuration options in Castle Windsor in my article, Bricks and Mortar: Building a Castle.

Now that AuthorizationServices and all of its dependencies have been registered with the container, we can successfully resolve it from the container:

var authorizationServices = IoC.Resolve<IAuthorizationServices>();

To service this request, Windsor will look for an implementer of IAuthorizationServices, which is AuthorizationServices. Windsor will then examine AuthorizationServices constructor, specifically the constructor parameters:

public AuthorizationServices(IAuthorizationChecker authorizationChecker) {
    this.authorizationChecker = authorizationChecker;
}

Windsor will look to see if it has an implementation registered for IAuthorizationChecker, which it does in the form of AuthorizationChecker. Looking at AuthorizationChecker’s constructors:

public AuthorizationChecker() : this(Settings.Instance.Provider, 
    new AuthTools(), new AclEvaluator()) {
}

public AuthorizationChecker(ISettingsStorageProviderV30 settingsProvider, 
    IAuthTools authTools, IAclEvaluator aclEvaluator) {
    ...
}

Windsor has two constructors to choose from. It starts from the constructor with the most overloads. It will see if it has implementations for all of the constructor parameters. (If it can’t find implementations for all constructor parameters, Windsor will attempt the next most overloaded constructor.) In this case, it will see that it needs to find an implementation for ISettingsStorageProviderV30, IAuthTools, and IAclEvaluator. Windsor has an instance of ISettingsStorageProviderV30 that we supplied to it earlier. It can also create instances of AuthTools and AclEvaluator because they have no further dependencies. Windsor passes the newly created AuthTools and AclEvaluator, as well as the pre-built ISettingsStorageProviderV30 to AuthorizationChecker’s constructor. Windsor then passes the newly created AuthorizationChecker to AuthorizationServices’ constructor. Finally, Windsor is able to pass back AuthorizationServices to satisfy the call to IoC.Resolve<IAuthorizationServices>.

Note that Windsor is responsible for managing the lifetime of objects registered in the container. Windsor’s default lifetime strategy is singleton. That means that multiple classes depending on IAuthorizationServices will all receive the same instance of AuthorizationServices. This instancing policy is easily changed on a per-service basis and includes options such as per-thread, per-Web-request, transient, and pooled. You can even create your own instancing policies if none of the built-in ones are appropriate.

With the container responsible for wiring dependencies between objects, we can remove the parameterless constructors as they are no longer required:

public AuthorizationChecker(ISettingsStorageProviderV30 settingsProvider, 
    IAuthTools authTools, IAclEvaluator aclEvaluator) { 
    ...
}

If AuthorizationChecker required another dependency, we would simply declare that fact by adding another constructor parameter with a type of the required service interface. We would then create a concrete class in the ScrewTurn.Wiki.Services namespace that implements that service interface.

Managing the Container

I have seen many projects place all container configuration into a single XML or C# file. This is especially unwieldy if explicitly configuring dependencies individually, which is why I prefer the convention-over-configuration approach discussed above. By placing dependencies in certain assemblies and namespaces, they are automatically registered. (Note that the convention-over-configuration approach is not available with XML files, although XML files are useful for specifying deployment-time overrides if necessary. For more information about this technique, see Bricks and Mortar: Building a Castle.) Placing all of our conventions in a single C# file can quickly become cumbersome as we have unrelated conventions bundled together.

Let’s take a look at an approach that allows us to separate our conventions into smaller, simpler classes. It all starts with the ApplicationBootstrapper, which is called during application startup:

public void Configure() {
    container = new WindsorContainer();
    IoC.Initialize(new WindsorDependencyResolver(container));

    RegisterFacilityStartupTasks();
    ExecuteFacilityStartupTasks();
    RegisterContainerStartupTasks();
    ExecuteContainerStartupTasks();
    RegisterStartupTasks();
    ExecuteStartupTasks();
}

We start by creating a new WindsorContainer and using it to initialize the IoC static gateway. We then alternately register and execute FacilityStartup, ContainerStartup, and Startup tasks, as shown in Figure 2.

Figure 2 Execute FacilityStartup, ContainerStartup, and Startup Tasks

private void RegisterFacilityStartupTasks() {
    RegisterAllTypesBasedOn<IFacilityStartupTask>();
}

private void RegisterContainerStartupTasks() {
    RegisterAllTypesBasedOn<IContainerStartupTask>();
}

private void RegisterStartupTasks() {
   RegisterAllTypesBasedOn<IStartupTask>();
}

private void RegisterAllTypesBasedOn<T>() {
    assembliesToScan.ForEach(assembly => 
        container.Register(
            AllTypes.FromAssembly(assembly)
                    .BasedOn<T>()
                    .WithService.FirstInterface())
    );
}

The list of assemblies to scan for startup tasks is provided via AssemblyBootstrapper’s constructor and defaults to Assembly.GetExecutingAssembly if left unspecified. We look through each assembly for types implementing IFacilityStartupTask, IContainerStartupTask, and IStartupTask and register them against the appropriate interface. (Facilities are Windsor’s primary extension mechanism. You can use facilities to implement everything from automatic transaction management to logging to array parameter resolution and more.) Next, we need to execute each of the startup tasks:

private void ExecuteFacilityStartupTasks() {
    var tasks = container.ResolveAll<IFacilityStartupTask>();
    tasks.ForEach(task => task.Execute(container));
}

private void ExecuteContainerStartupTasks() {
    var tasks = container.ResolveAll<IContainerStartupTask>();
    tasks.ForEach(task => task.Execute(container));
}

private void ExecuteStartupTasks() {
    var tasks = container.ResolveAll<IStartupTask>();
    tasks.ForEach(task => task.Execute());
}

Note that IFacilityStartupTask|IContainerStartupTask.Execute both take an IWindsorContainer, as their purpose is to configure the container. IStartupTask.Execute is to perform other types of initialization once the container is ready to be used and therefore doesn’t accept an IWindsorContainer.

The individual startup tasks are small and self-contained. For example, take a look at the ServiceRegistration class, which is responsible for registering application-related services:

public class ServicesRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            AllTypes.FromAssembly(Assembly.GetExecutingAssembly())
                .Where(x => x.Namespace.StartsWith("ScrewTurn.Wiki.Services"))
                .WithService.FirstInterface(),
            Component.For<IAclEvaluator>().ImplementedBy<AclEvaluator>()
        );
    }
}

You can see the convention responsible for registering all services in the ScrewTurn.Wiki.Services namespace. There is also the extra configuration for the AclEvaluator. If we choose to combine the AclEngine project into Core, we could eliminate the extra configuration step for AclEvaluator.

We have a completely separate and independent IContainerStartupTask for Host and Provider registration:

public class HostAndProviderRegistration : IContainerStartupTask {
    public void Execute(IWindsorContainer container) {
        container.Register(
            Component.For<IHostV30>().ImplementedBy<Host>());

        var ssp = ProviderLoader.LoadSettingsStorageProvider(
            WebConfigurationManager.AppSettings["SettingsStorageProvider"]);
        container.Register(
            Component.For<ISettingsStorageProviderV30>().Instance(ssp));
    }
}

As we break apart the “God object” that is the Host, we can modify its container registration in one place without affecting the registration of the services. If we need to perform additional unrelated container configuration, we create another class that implements the IFacilityStartupTask or IContainerStartupTask without affecting other configuration that is already taking place.

To wrap up, let’s refactor StartupTools.Startup() into a IStartupTask where it belongs:

Conclusion

Although it is not initially obvious, the ScrewTurn Wiki codebase suffers from dependency problems. Tight coupling of implementation classes caused by singletons and static classes result in a morass of objects, which is difficult to refactor. Dependency cycles between objects result in sensitive constructor and method orderings, which can result in unexpected NullReferenceExceptions after apparently innocuous changes to the code.

In this article, we have made dependencies obvious by changing them into constructor parameters and using an IoC container to wire together the dependencies. Using convention-over-configuration approaches eases the introduction of new functionality, without requiring explicit configuration. We have introduced a reusable ApplicationBootstrapper, whereby new startup tasks can be added as the application grows without modifying existing code. The resulting codebase should be more flexible and maintainable over time.

Other videos from this article

• Overview
• Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee424155.aspx

The Tangled Web we Weave

Let’s take a closer look at AuthorizationServices. AuthorizationServices depends on IAuthorizationChecker, which is implemented by AuthorizationChecker. In turn, AuthorizationChecker depends on Settings to retrieve the configured ISettingsStorageProviderV30, which can be a SettingsStorageProvider, SqlSettingsStorageProvider, or other implementation. Now, SettingsStorageProvider depends on IHostV30 and its default implementation by Host. Host is a “God object” in ScrewTurn Wiki. According to Wikipedia, “a God object is an object that knows too much or  does too much.” A God object is a software anti-pattern.

Host is a coordinator of a wide variety of unrelated activities in ScrewTurn. It handles everything from retrieving settings values to sending emails to handling backups to finding users, Wiki pages, namespaces, categories, and more.

Many of these responsibilities are delegated to sub-objects, and Host only acts as the coordinator of these services. This is better than having all that functionality actually coded in Host itself. Host does still present a problem in that its delicate coordination of all the other objects in the system, especially during application startup, means that it is difficult to refactor the overall system. Moving startup code from one class to another causes breakages as the ordering of construction is slightly changed and previously working code throws NullReferenceExceptions as dependencies are unexpectedly null due to construction orderings.

Let’s take a look at Host’s constructor:

public Host() {
    customSpecialTags = new Dictionary<string, CustomToolbarItem>(5);
}

In its constructor, Host creates a single Dictionary. There is no indication that Host has a dependency problem. Host’s tangled web of dependencies is hidden due to its overuse of Singletons and static helper classes. For example, let’s take a look at a few Host methods:

public UserInfo[] GetUsers() { 
    return Users.Instance.GetUsers().ToArray();
}

public PageContent GetPageContent(PageInfo page) {
    return Content.GetPageContent(page, true);
}

public string Format(string raw) {
    return Formatter.Format(raw, FormattingContext.Unknown, null);
}

Note the use of the Users singleton and the static Content an Formatter classes in the above code. Without actually looking at Host’s implementation code, there is no way to tell that it depends on these other classes. To make matters even more complicated, Users (and other dependent classes) depend on Host! If constructors aren’t run in the correct order and before certain methods are called, NullReferenceExceptions will be your reward. All of the construction logic is carefully orchestrated by StartupTools, which is responsible for constructing and initializing all singletons within the application in the correct order.

Seeking Salvation

God objects lead us down a road unto madness. Host’s dependencies are so tangled and interdependent that the result is only somewhat better than a single, monolithic object. So how do we chart a course back to sanity?

Dependencies in software are not fundamentally the problem here. Without dependencies, we wouldn’t be able to write much more than “Hello, World!”-style applications. (Even a simple application like Hello, World!  requires dependencies on System.Console and System.String, as well as the CLR.) The problem is unchecked and unfettered dependencies between objects that do not need to know about each other. Before we can solve the problem of unnecessary dependencies, we need to make those dependencies obvious. How can we construct our classes/objects so that their dependencies are obvious? Make dependencies apparent by declaring them in the classes constructor. For example, let’s look at AuthorizationServices’ constructor:

public AuthorizationServices(IAuthorizationChecker authorizationChecker) {
    this.authorizationChecker = authorizationChecker;
}

Simply by looking at the constructor’s signature, we can tell that AuthorizationServices requires an IAuthorizationChecker to perform its work. (You probably already knew that because we implemented it in part 7.) The concrete implementation of IAuthorizationChecker is AuthorizationChecker:

public AuthorizationChecker() {
    settingsProvider = Settings.Instance.Provider;
}

Notice that you don’t know that AuthorizationChecker depends on the static Settings class. You have to read AuthorizationChecker’s constructor implementation to figure this out. While not hard, it is not immediately obvious that AuthorizationChecker depends on ISettingsStorageProviderV30, which is the type return by the Provider property. How can we make this more obvious? By declaring our intent in the constructor parameters, like so:

public AuthorizationChecker() : this(Settings.Instance.Provider) {
}

public AuthorizationChecker(ISettingsStorageProviderV30 settingsProvider) {
    if(settingsProvider == null)
        throw new ArgumentNullException("settingsProvider");

    this.settingsProvider = settingsProvider;
}

Our other code depends on the parameterless constructor. We will leave it in place for now and chain to an overloaded constructor that takes a ISettingsStorageProviderV30. Our dependency on ISettingsStorageProviderV30 has now been made obvious.

We are not out of the proverbial woods yet. Other dependencies are lurking within AuthorizationChecker, namely the static classes AuthTools and AclEvaluator. We can make them obvious dependencies by changing them from static classes to instances and moving their initialization to the constructor.

Other videos from this article

• Overview
• Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee424155.aspx

Now that we have a new class, complete with functionality, we can start to refactor other parts of the application to use it instead of the AuthChecker singleton.  Like all the other refactorings we’ve done thus far in this article, it’s not that big of a deal.  As our example, we’re going to continue to refactor the AuthorizationServices class (see the previous Separation of Concerns article for the initial refactoring for this).  In AuthorizationServices, we want to eliminate the use of AuthChecker and, in its place, use an instance of AuthorizationChecker instead.

To do this, we first need to create a module level variable that provides the same capabilities as the AuthChecker singleton.  Earlier in this article, we created an IAuthenticationChecker interface that worked to enforce this for us.  Now is another time that we can use it.  As you can see in the code below, we now have created an instance of the AuthenticationChecker and assigned it to the module level variable:

public class AuthorizationServices
{
    private IAuthorizationChecker _authenticationChecker;

    public AuthorizationServices()
    {
        authorizationChecker = new AuthorizationChecker();
    }
    ...
}

Now that we have a way to access the authentication checking code, we just need to replace the AuthChecker calls in the RetrieveCurrentStatusFor method with calls to the module level variable.  As an example of these changes, here is what the first one would look like:

CanView = _authorizationChecker.CheckActionForPage(currentPage, 
    Actions.ForPages.ReadPage, currentUsername, currentGroups),

With that we have our AuthorizationServices class refactored and we’ve finished the first full round of changes that are required to eliminate the AuthChecker singleton.  If we take a look at the usages of the AuthChecker singleton instance, we’ll see that there are still a large number of places that it is being used.

Now that you’ve finished this first complete refactoring to use the new AuthorizationChecker class, you’ve also reached the first logical checkpoint in your refactoring exercise.  From here you can choose when you want to move from the AuthChecker singleton to an AuthorizationChecker instance class in any of the other places that AuthChecker is being used.  As you incrementally move through your changes from AuthChecker to AuthorizationChecker, you get closer and closer to the next step in this refactoring: deleting the AuthChecker singleton.

Once you have all of the usages of AuthChecker replaced with the AuthorizationChecker class you’re almost ready to remove the AuthChecker class from your code base.  Before we can do that, remember that we had the new AuthorizationChecker class delegating execution to the AuthChecker singleton.  To be able to get rid of AuthChecker completely, we need to move its logic into the new AuthorizationChecker class.  There are a couple of small things that we need to address in this refactoring, such as adding using statements.  

The main change we need is to address the code’s need for an ISettingsStorageProviderV30 typed object.  If we look into how that object is being passed into the AuthChecker singleton, we see that it’s actually being provided from another singleton named Settings:

AuthChecker.Instance = new AuthChecker(Settings.Instance.Provider);

Since this value is coming from a singleton, we can easily add a module level variable to AuthorizationChecker that can be used throughout its methods.  Assigning that variable is as simple as what you see below.  Also note that we no longer need the module level AuthChecker variable since we’ve now moved all of the AuthChecker code into this class.  Since it’s not needed, we’ve removed it and the code related to it in the constructor:

private ISettingsStorageProviderV30 _settingsProvider;
 
public AuthorizationChecker()
{
    _settingsProvider = Settings.Instance.Provider;
}

The result of this final refactoring is that the public methods on AuthChecker are no longer being executed anywhere in the code base.  If you were to do a Find Usages on AuthChecker, you’ll see that the only place it exists is in the StartupTools class where it was being initialized.  Since it’s not being used anywhere, there’s no need to initialize it, so we’ll just delete that line of code.  Now we’re completely free of any use of AuthChecker, so we can delete the class from the project.  With that, you’re free of your singleton past...or at least one part of it.

I realized what a ridiculous lie my whole life has been...

We’ve spent some quality time together on this article and have weaned you from a dependence on singletons in your code base.  Singletons often are seen as the “easy” way to code.  Just because you don’t have to “new up” a class to make use of its functionality, doesn’t mean that you’re not imposing a debt on your code base.  While singletons seem like the route of least friction at first, you quickly find out that they’re nothing more than a mirage on the way to software development bliss.  You see the ease of development that they offer, but every time that you move closer the goal is still just as far away as it was before.

Unless you truly need to ensure that one, and only one, instance of an object exists per application lifecycle, then you should be working to refactor singletons out of your code base.  Hopefully, the techniques in this article have pointed you in the right direction to be able to do that.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

I’ve Got Some Seeds, Right Away

So where should we start?  How about the AuthChecker class, since that’s what we’ve discussed through the first part of this article.  Earlier, we decided that there was no reason for it to continue to be a singleton, since there was no compelling reason for one, and only one, instance of it to exist for the life of the application.

The process that we’re going to go through will see us move from using the existing AuthChecker class to using instances of an AuthorizationChecker class.  Once we’ve made the transition from AuthChecker to AuthorizationChecker, we will delete the AuthChecker Singleton from our codebase.

The first challenge that we have to face in this process is how do we create a new class (AuthorizationChecker) which we can guarantee to expose the same functionality as the original (AuthChecker) class.  There are two reasonable options for this: abstract base class and interface.  Abstract base class is a good solution, if we were going to need to use the same AuthChecker functionality in multiple class implementation for the distant future.  In this case though, we’ve already determined that we’re going to be deleting the AuthChecker Singleton implementation once we’ve completed our refactoring.  As a result, using Interfaces makes more sense.

That makes our first step in the process to extract an interface from the AuthChecker class.  As you can see below, it’s really a simple interface, called IAuthorizationChecker, that defines the four publically exposed methods on the AuthChecker class:

public interface IAuthenticationChecker
{
    bool CheckActionForGlobals(string action, string currentUser,
        string[] groups);
    bool CheckActionForNamespace(NamespaceInfo nspace, string action,
        string currentUser, string[] groups);
    bool CheckActionForPage(PageInfo page, string action,
        string currentUser, string[] groups);
    bool CheckActionForDirectory(IFilesStorageProviderV30 provider, 
        string directory, string action, string currentUser, string[] groups);
}

Now that we have that interface we need to get the AuthChecker to implement it.  This is pretty easy, but has a couple of small twists.  Because we’re applying the interface to a Singleton class, we also have to ensure that the .Instance property is returning a type of the IAuthenticationChecker interface.  To get the code to compile we also have to change the type of the properties underlying module level variable so that it too is of type IAuthorizationChecker:

public class AuthorizationChecker : IAuthorizationChecker
{
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, string directory, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
}

Interestingly, this is the last of the changes that you’ll have to make to AuthChecker before you delete it from the project.

Now that we’ve established how calling code should expect us to behave (via the IAuthorizationChecker interface), we can go ahead and write a new class that meets that expectation.  In this case we’re going to call the class AuthorizationChecker and we’ll make it implement the interface.  The result, as shown in Figure 6, is a class with the same four public methods on it that the AuthChecker class has.

Figure 6 Class With Four Public Methods

public class AuthorizationChecker : IAuthorizationChecker
{
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, 
        string directory, string action, 
        string currentUser, string[] groups)
    {
        throw new NotImplementedException();
    }
}

Now that our new AuthorizationChecker class has a basic shell, we need to get it working with the same functionality as the original AuthChecker singleton.   One of the key things when doing refactorings like this is to be able to do them incrementally.   Big-bang approaches can be successful, but rarely do you have the ability to impose the constraints, such as time and cost, on your project’s current needs.  Instead, we want to be able to nibble away at the refactoring as time permits and in a way that won’t affect the project.

To do this, we’re going to take our new AuthenticationChecker class and simply pass through the calls to the original AuthChecker code.   This may seem like an extraneous step, but it’s one that is necessary to achieve the goal of refactoring little by little.  To make this happen, we need to get an instance of AuthChecker into the local scope of the newly created AuthenticationChecker class:

private IAuthorizationChecker _authChecker;
 
public AuthorizationChecker()
{
    AuthChecker.Instance = new AuthChecker(Settings.Instance.Provider);
    _authChecker = AuthChecker.Instance;
}

Once we have the AuthChecker instance in place, we can have the methods in the class simply delegate execution to the existing methods in the AuthChecker class.  Like we said before, this may seem extraneous, but trust us, we’re going somewhere here, as shown in Figure 7.

Figure 7 Execution of Existing Methods in the AuthChecker Class

public bool CheckActionForGlobals(string action, string currentUser, 
    string[] groups)
{
    return _authChecker.CheckActionForGlobals(action, currentUser,
        groups);
}
 
public bool CheckActionForNamespace(NamespaceInfo nspace, 
    string action, string currentUser, string[] groups)
{
    return _authChecker.CheckActionForNamespace(nspace, action, 
        currentUser, groups);
}
 
public bool CheckActionForPage(PageInfo page, string action, 
    string currentUser, string[] groups)
{
    return _authChecker.CheckActionForPage(page, action, 
        currentUser, groups);
}
 
public bool CheckActionForDirectory(IFilesStorageProviderV30 provider, 
    string directory, string action, string currentUser, string[] groups)
{
    return _authChecker.CheckActionForDirectory(provider, directory, 
        action, currentUser, groups);
}

One of the key things to note with this approach is that we’ve maintained a single place of change for the code that is related to the AuthChecker/AuthorizationChecker functionality.  If we’re going to be tackling this refactoring over a period of time, this is key, since we can’t be confidently maintaining multiple pieces of code that represent the same functionality.  Don’t be fooled that the maintenance cost of this approach is zero.  If you were to change the arguments in the methods, you’d have multiple places to change, but, on a positive note, you’d get compile errors from that due to the use of an interface enforcing the publically exposed contract.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

He’s Liked, But He’s Not Well Liked

If the current code works, why do we need to get rid of the singleton? What harm is it doing? After all, there’s a reason the pattern has a name. It must be useful.

We have a few issues with singletons. The easiest argument to make is that singletons make your code hard to test. If you make a call to a singleton in a class, then you must make sure the singleton is initialized whenever the test is run. If the singleton requires a connection to a database or the existence of a Web service, these must be configured prior to running the test. If you want reasons why this is a bad practice, look no further than our previous article on separation of concerns.

This lack of testability isn’t the only problem. After all, there are ways (usually neither easy nor pleasant) to make singletons testable. Indeed, ScrewTurn uses one of them by exposing a public constructor. Let’s look more closely at the AuthChecker class we’ve been working with. Why is it a singleton class? Perhaps so that its members can be accessed throughout the site without having to create a new instance of it? Perhaps to save on resources by reducing object allocation and garbage collection? (This would almost certainly be a premature optimization.)

Let’s look at the first public method on the class, CheckActionForGlobals. Where is this being used? If you trace its usages, you’ll find it is used in exactly three other classes: the AdminMaster master page and FileManager.ascx control (both in the WebApplication project) and the AuthorizationServices class in the Core project. (The latter is one of the refactorings we did in Part 6; originally, it was being called in Default.aspx in the WebApplication project.)

So this globally accessible method is really only being used in three places. Doesn’t sound all that global to us. One could make an argument that each of these classes could just create an instance of the class instead. That would make them easier to test and less fragile overall.

Of course, we’ve been cautiously selective in our example. CheckActionForGlobals is but one method in the AuthChecker singleton. If we look at all cases where we reference AuthChecker.Instance, we’ll find no less than 86 occurrences of it across 21 files.

“Aha!” you say. “Doesn’t that contradict your argument that it’s not really being used globally?” “Pshaw!” say we! What it does is highlight another issue with singletons. The Instance variable is used in 21 files, yet CheckActionForGlobals is used in 3. Another method, CheckActionForDirectory, is used in 5, not including calls made from within the AuthChecker class itself.

In short, our singleton has turned into a sort of catch-all bucket, a place to house disparate methods under the loosely-defined category of “authorization checking.” Granted, the AuthChecker class isn’t as messy as it could be, but the tendency with singleton classes is to make them more and more generic as you add “helper” methods to them. The ubiquitous Utils singleton often seen in many projects is a good example. Developers see a singleton and it’s just so darned tempting to drop a method in there rather than create a separate class with a more specific focus.

The result of those temptations is that you find code bases that are littered with unnecessary singletons.  While they may seem innocuous at first, the problems we described earlier will start to haunt your project.  To help you with those existing Singletons, let’s look at how we can move through our code and remove them.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx

Let’s review one of the changes we made to the code in part 6. In that discussion, we refactored the authorization checking into a separate class, AuthorizationServices. To do that, we moved a lot of code from the Page_Load method of our Default.aspx page into it. Figure 1 shows an excerpt from the RetrieveCurrentStatusFor method.

Figure 1 Excerpt from the RetrieveCurrentStatusFor Method

return new CurrentCapabilitiesStatus
{
    CanView = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ReadPage,
        currentUsername, currentGroups),
    CanDownloadAttachments = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.DownloadAttachments,
        currentUsername, currentGroups),
    CanSetPerms = AuthChecker.Instance.CheckActionForGlobals(
        Actions.ForGlobals.ManagePermissions,
        currentUsername, currentGroups),
    CanAdmin = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ManagePage,
        currentUsername, currentGroups),
    CanViewDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ReadDiscussion,
        currentUsername, currentGroups),
    CanPostDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.PostDiscussion,
        currentUsername, currentGroups),
    CanManageDiscussion = AuthChecker.Instance.CheckActionForPage(
        currentPage, Actions.ForPages.ManageDiscussion,
        currentUsername, currentGroups),
    CanEdit = canEdit,
    CanEditWithApproval = canEditWithApproval
};

Notice all the calls to AuthChecker.Instance. This is an example of the Singleton Design Pattern at work. We’ll define it now to get everyone on the same page.

There Can Be Only One

The defining characteristic of a singleton class is that there is only one instance of it at any given time (unless it is never used, in which case, there may not be any instances of it depending on how it is implemented).

Implementing a Singleton is not quite as trivial as it sounds. The intuitive approach is to make the constructor private and provide a public static accessor to it, as shown in Figure 2.

Figure 2 Implementing a Singleton

public class MySingleton
{
    private static MySingleton _instance;
 
    private MySingleton()
    {
    }
 
    public static MySingleton Instance
    {
        get
        {
            if (_instance == null)
                _instance = new MySingleton();
            return _instance;
        } 
 
    }
 
    ...
}

This works fine in single-threaded environments, but not in multi-threaded ones. Two threads could enter the Instance property before the instance variable is instantiated, resulting in two instances of the class. There are a few ways around this,  but the easiest solution in .NET takes advantage of the CLR and its guarantees around initialization of static variables, as shown in Figure 3.

Figure 3 Dealing With Two Instances of the Class

public class MySingleton
{
    private static readonly MySingleton _instance = new MySingleton();
 
    private MySingleton()
    {
    }
 

    public static MySingleton Instance
    {
        get
        {
            return _instance;
        } 
 
    }
 
    ...
}

The fact that the instance variable is marked static and readonly ensures only one instance can be created, even in multi-threaded environments.  Another side effect is that an instance of MySingleton is always going to be created for the _instance variable, regardless of if it’s needed or not.  This is, however, rarely an issue in real world code.

Some Background

A common implementation for singletons is to use double-checked locking, like so:

if (_instance == null) {

    lock (_initializationLock) {

        if (_instance == null) {

            _instance = new MySingleton();

        }                    

    }                

}

return _instance;

On the surface, double-checked locking appears to offer the best of all worlds. Singletons are instantiated lazily, are never instantiated if never used, and do not take an expensive lock after the singleton is initialized. Unfortunately, double-checked locking is subtlely broken in the vast majority of cases. You can read more about the problems in The “Double-Checked Locking is Broken” Declaration by David Bacon, et al. Double-checked locking can be fixed on the CLR (and JDK5+) by declaring the _instance variable with the volatile keyword. See Implementing Singleton in C# and Exploring the Singleton Design Pattern in the MSDN Library for more information.

That’s about as detailed as we’re going to get on implementing singletons, because there are a number of good resources already available. Plus, the focus of this article is to move away from them, not add more.

With that background behind us, the “singleton” classes in ScrewTurn aren’t actually singletons. Figure 4 looks at the AuthChecker class first.

Figure 4 AuthChecker Class

public class AuthChecker {
 
    private static AuthChecker instance;

    public static AuthChecker Instance 
    {
        get { return instance; }
        set { instance = value; }
    }
 
    private ISettingsStorageProviderV30 settingsProvider;
 
    public AuthChecker(ISettingsStorageProviderV30 settingsProvider) 
    {
        if(settingsProvider == null) throw new 
            ArgumentNullException("settingsProvider");
 
        this.settingsProvider = settingsProvider;
    }
 
    public bool CheckActionForGlobals(string action, 
        string currentUser, string[] groups) 
    {
   
    }
 
    public bool CheckActionForNamespace(NamespaceInfo nspace, 
        string action, string currentUser, 
        string[] groups) 
    {
   
    }
 
    public bool CheckActionForPage(PageInfo page, string action, 

    {
   
    }
 
    public bool CheckActionForDirectory(
        IFilesStorageProviderV30 provider, 
        string directory, string action, 
        string currentUser, string[] groups) 
    {
   
    }
}

The most obvious way you can tell this isn’t a singleton is that it has a public constructor. So the client code can create as many of these as it likes. Furthermore, the class doesn’t actually instantiate the instance variable itself. That is done elsewhere in the code, in StartupTools.cs, using the public constructor.

That said, it is still used as a singleton within the context of the application. Yes, the code could create more than one instance and re-assign the existing instance and basically treat it like any other class. But in the application’s current state, it doesn’t. This half-way status between singleton and non-singleton would be a bone of contention for us at a code review, so let’s see what we can do to fix it. But first, like any refactoring, we need to justify it.

Other videos from this article

• Demoing Different Singleton Implementations
• How Singletons Affect Testability
• Looking At AuthChecker
• Walkthrough Of The Entire Refactoring

Read the full article at http://msdn.microsoft.com/magazine/ee343987.aspx