AD searching and the Template Method design pattern

A while back I had the funny task to obtain users from the AD and do present them in a neatly designed list. Since neatly organized employee lists hold a certain coolness factor, soon other departments grew jealous and wanted peeking their own employees, only with more info available and more neatly organized.

Now nothing holds more fun to the everyday developer than maintaining classes that does the same thing, only in a slightly different way. So I thought the logic can be made reusable, and by employing the magic of generics combined with the template method design pattern, the soon-to-come new departments needing slightly different info for their neatly organized employee lists could be taken care very fast.

So what is a template method and how does it work? Template method is just a fancy name for a method that your base class will call, and you can override its implementation in subclasses. I created a sample project and pushed it to GitHub, so let’s review what’s in there.

The gist of the template method is found in the class ADUserFinderAbstract<T>. Here’s how it’s looks like:

As you see, there’s a method called GetUser which goes into the AD and try to find a user. Then it calls an abstract method in the same class, called convertPrincipal, and passes the found user (or null, to be entirely correct) to this method. You can easily guess what is the point of this whole thing: override the abstract method in a subclass, and provide different implementations depending on various business needs. That’s what is done in the solution.

There are two implementations, one (EmailADUserFinder) simply returns the e-mail address of the user, the other (ComplexADUserFinder) does a lot more work, and tries to load department information, too.

And why go generic? In this particular business case, a generic implementation was more than ideal. I could map to the UserPrincipal object whatever entity I wanted, and do work with that. But template methods doesn’t necessary have to be generic methods of course. It only grants more power in this case.

I hope you’ll find this post useful, don’t forget to check out the GitHub project again!


“Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.”

Design Patterns: Elements of Reusable Object-Oriented Software

Imagine the time before fancy and automatic GUIs, and the case of a simple textview. Sometimes, we enter more information in it than it can show. The behavior which we are accustomed to in these cases is that suddenly a scrollbar will appear out of nowhere, and magic! we can scroll down to see the rest of the text entered. But do we always need that scrollbar? If we’d create a subclass for textview with the name TextViewWithScrollBar, and use it anyway, would it make sense?

No it wouldn’t, we’d only need those bars whenever we exceed the space given us within the textview. And we cannot see that fore. So what is the solution?

From the title, you can guess easily that it’s nothing else but the Decorator pattern. Notice the following: “Attach additional responsibilities to an object dynamically.”. Not a class, but an instance of a given class, the object. This is the key phrase here. But how can we achieve such behavior. The answer is simple, we need four players here:

  • Component: a very brief and lightweight interface for your objects that can have dynamic responsibilities (such as render a scrollbar).
  • ConcreteComponent: the object itself which implements Component.
  • Decorator: implements Component, and maintains a reference to a ConcreteComponent.
  • ConcreteDecotator: adds the dynamic responsibilities to ConcreteComponent, implements Decorator.

Now a code example for the above:

Continue reading “Decorator”


“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.”

Design Patterns: Elements of Reusable Object-Oriented Software

A Composite is something really simple and straightforward, with countless examples in the computing world (at least I found quite many examples for it). You can easily imagine it as a tree structure: a node can be a composite, or a leaf. Composites can contain further composites and/or leaves, and so forth.

The big advantage in this pattern is that it lets you treat primitive and container objects in the same manner, thus simplifying your code. Now let’s understand the key players here:

  • Component: defines the interface for the objects of the composition, their default behavior, the method to get or set the child components.
  • Leaf: primitives of the composition which haven’t got child objects.
  • Composite: components that have child objects, defining their own child-management methods.
  • Client: works with composition through the component interface.

An example is the View object in the Cocoa Touch Framework (to get a bit further from the .NET Framework). Each View can have further Views which can be accessed through the parent View. But here’s a .NET sample:

Continue reading “Composite”


“Decouple an abstraction from its implementation so that the two can vary independently.”

Design Patterns: Elements of Reusable Object-Oriented Software

The Bridge pattern is a bit mysterious for me, I’m trying to find a concrete implementation of it in the .NET Framework, but it is a bit hard task. The main point in bridge is to decouple the implementation from its abstraction, and let them evolve separately. We have four key players here:

  • Abstraction: is the interface our client is aware of. It also maintains a reference on the implementation (something moved into the RefinedAbstraction commonly).
  • RefinedAbstraction: implements Abstraction, and extends its functionality (in all examples, the reference to Implementor was moved here).
  • Implementor: defines the functionality of abstraction, and the methods to call.
  • ConcreteImplementor: extends implementor.

Now let’s see a real example:
Continue reading “Bridge”


„Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.”

Design Patterns: Elements of Reusable Object-Oriented Software

As you may have noticed, with Singleton, we reached the end of the creational patterns. From now on, we’ll consider the benefits of each so-called structural pattern. You don’t have to be a genius to find out what structural patterns are involved in: defining the composition of larger structures, built from objects.

The first one in the list is called Adapter (you may (and I have) known it as Wrapper). It comes handy when you are dealing with incompatible types (to be strict, interfaces). There are four players in the adapter pattern:

  • Target: that is, what the client can use, the shape we need to from the adaptee.
  • Client: our code which works with the Target.
  • Adaptee: an existing interface, that the client needs to use
  • Adapter: the class which acts as a wrapper, and adapts Adaptee to Target.

Maybe I haven’t described the problem in the best available way, so let’s see a code sample for this one:
Continue reading “Adapter”


“Ensure a class only has one instance, and provide a global point of access to it.”

Design Patterns: Elements of Reusable Object-Oriented Software

The Singleton pattern is something really simple. Let’s assume you have a class, which represents your data access layer, as a whole. As you might guess, a DAL object can grow quite large, especially when it stores disconnected data, such as in the case of a DataSet. There might be good reasons to have multiple ones instantiated of them, but maybe that’s not the best idea ever.

This is when Singleton pattern comes to place. It ensures that only one and only instance can live of a specific class, and that instance is accessible for every part of your code which needs it for its work. Implementing this behavior in code is very easy, consider the following example:

public sealed class MySingleton
                public static readonly MySingleton SoleInstance = new MySingleton();
                //rest of the class

Continue reading “Singleton”


“Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.”

Design Patterns: Elements of Reusable Object-Oriented Software

Instantiating a class multiple times can be resource intensive, and can result in repeating the very same code multiple times. Sometimes it is more convenient to copy or clone your existing objects. Fortunately, the .NET Framework has built-in support for these cases, the aforementioned IClonable interface. This interface contains only one method, the Clone, which returns Object. So any time you need to use the Prototype pattern, just implement IClonable, and you are good to go.

A little about the idea: imagine that you are working with a complex class, such as one representing a table of data from a SQL database. You’d do something with it, then you’re in the need of the same data again. Instead of rebuilding the whole object again, you should clone the first one, and call your methods on it. It saves you from writing the same code twice, and the cost of creating a new object on the heap.

To be straightforward, let’s enlist the participants here, too:
Continue reading “Prototype”