Extreme Programming: User Stories

user-storyAs professional developers, our role is to write high quality code within our applications. Yet this is worthless if it does not provide any value to our customers.

There are not much companies that will hire you to let you work on whatever you want. These businesses have customers that need new features and improvements in the software they buy and use.

It most cases you will work in an industry you know nothing, or almost nothing about. But don’t worry, you will work with people who know it, the business analysts. They know how to provide value for their customers and they need talents to implement it: YOU! You form a whole team.

In order to ease the specification and especially the prioritization of development in an “agile” environment, you can rely on user stories.

User Story

A user story describes a single requirement for the system. It is expressed by the business team and it generally written as a sentence matching the following format:

As a <role>, I want <goal/desire> so that <benefit>

The details are not defined within the sentence because they are likely to change with time even if the main goal will not. Details are discussed during conversations between the business analysts and the development team.

The use of user stories allow the developers to be able to provide a low risk estimate and by extension a budget for the feature. It is focused on the user needs, specific technology details should be excluded (data base schema, algorithm, …).

The role

In the sentence describing a user story a role is defined. By doing so you are able to detect the user of the system. It is likely the person who will know all the details you need to complete the task.

If the user story needs a new User Interface (U.I.) and this person is the final user of it, you should ask him how he wants to use it. Because I think that a UI providing the goal of the user story but with a really bad User Experience (U.X.) is not as valuable as it should be.

The goal

In a user story the goal is the new feature that needs to be created. It defines what the final customer/user wants and needs. This is the part of the system that needs to be well crafted, from a code perspective and from a user experience perspective (see previous section).

The benefit

The last part of the user story describes the benefit. This way you can understand the value it provides to the customers/clients. It can also describes the final result and if you know it, you can test it!

If the benefit of a user story is hard to write down maybe it means that it is not as valuable as you think it is. And therefore there might be others user stories to prioritize first.

In an agile environment such as Extreme Programming (X.P.) the use of user stories allow the business analysts to express their needs for the customers without writing an entire documentation containing every details. They are focused on the user, the goal and the benefit. This way the development team should be able to properly estimate it and they gather the details using a good communication in the whole team.

See you next time!


Image credits:

https://boagworld.com/usability/user-stories/

Extreme Programming: Whole Team

whole-teamExtreme Programming (XP) is one of the agile software development methodologies. Therefore it focuses on short development cycles and to do so it has defined several practices to follow when working with it. In this blog post I will introduce the first one: Whole Team.

As a professional developer I firmly believe in collaboration among a software development team. I believe that is by working together that we are able to create more valuable products.

The developers, the testers, the project manager and the business analysts (sometimes called “product owners”) have a common goal: product value for their customers. This is why they have to work closely with each others and they should be able to speak with each others easily, a good communication is mandatory.

Every role is important in the organization and everyone as a part to play in the project. The business analysts know what has to be done, they represent the customers needs. The developers know how it has to be done, the testers ensure that the quality standards are met and the project manager makes sure that everything runs smoothly.

I know that all of this makes sense, yet sometimes I feel like the common vision is lost in a software development team. Maybe you have experienced the well-known “programmers vs the business” work environment, or maybe the “developers vs testers”.

I know that I have experienced similar situations and I was part responsible for it. Because I only had consideration for my world, where coding is king and everything else is secondary. Now I keep in mind the “big picture”: creating value for the clients. It still requires writing well-crafted code, it is my role in the team. I have to make my teammates understand my point of view and I also have to understand their.

When working in an agile environment, in Extreme Programming for instance, you have to keep in mind that you are part of a whole team. Everyone as a role toward the creation of value.

See you next time!


Image credits:

http://www.branddrivendigital.com/how-to-engage-your-whole-team/

The Law of Demeter

demeterDo not let the title mislead you, today’s article is not about greek mythology. As always I will speak about software development. In my last article I introduced the Tell Don’t Ask principle where it was about object behavior using encapsulation. The Law of Demeter (LoD) is an Object Oriented Programming (OOP) design guideline that fits well with this last principle. This practice uses encapsulation in order to reduce coupling between your components, and therefore it helps you improve your code quality. Here is a definition for the LoD:

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

For OOP it can be described with the followings list, which I consider easier to digest:

A method of an object may only call methods of:

  1. The object itself.
  2. An argument of the method.
  3. Any object created within the method.
  4. Any direct properties/fields of the object.

I will now demonstrate the use of the LoD with an example in C#. I will use the famous “The Paperboy and the Wallet” case from the original paper about the Demeter practice. In this example, the paperboy get a payment from a customer who as a wallet.

Initial situation

public class Wallet
{
    public float Value { get; set; }
 
    public void AddMoney(float amount)
    {
        Value += amount;
    }
 
    public void SubMoney(float amount)
    {
        Value -= amount;
    }
}
 
public class Customer
{
    public string FirstName { get; set; }
 
    public string LastName { get; set; }
 
    public Wallet Wallet { get; set; }
}
 
public class Paperboy
{
    public void SellPaper(Customer customer)
    {
        var payment = 2.0f;
        var wallet = customer.Wallet;
        if (wallet.Value >= payment)
        {
            wallet.SubMoney(payment);
        }
        else
        {
            // come back later
        }
    }
}

The Wallet class just stores its amount and exposes two methods to manipulate this amount. A customer has a first name, last name and a wallet. And finally the paperboy sell its good to a given customer using its wallet.

The problems

To me, it does not really looks like a real world scenario, I personally don’t give my wallet to every person I must pay. The paperboy knows that the customer has a wallet and he is able to manipulate it, this can be seen as a Single Responsibility Principle violation. And nothing prevents the paperboy code to do something like this:

customer.Wallet = null;

And maybe the customer’s wallet is already null, and therefore the paperboy’s method has to add a null check to avoid unwanted NullReferenceException.

public void SellPaper(Customer customer)
{
    var payment = 2.0f;
    var wallet = customer.Wallet;
    if (wallet != null)
    {
        if (wallet.Value >= payment)
        {
            wallet.SubMoney(payment);
        }
        else
        {
            // come back later
        }
    }
}

For a simple functionality, I think my code starts to look “heavier” than it should. A modification of the Wallet class will result in an update in the Paperboy class as well, the 3 classes are tightly coupled and it is unnecessary. The paperboy just wants to be paid, no matter if the money comes from a wallet or something else.

Following the Law of Demeter

I will now rewrite the code to fix the previous issues. To do so I will use encapsulation and add a PayAmount() method to the Customer class.

public class Wallet
{
    public Wallet(float initialAmount)
    {
        Value = initialAmount;
    }
 
    public float Value { get; private set; }
 
    public void AddMoney(float amount)
    {
        Value += amount;
    }
 
    public void SubMoney(float amount)
    {
        Value -= amount;
    }
}
 
public class Customer
{
    public Customer()
    {
        FirstName = "John";
        LastName = "Doe";
        _wallet = new Wallet(20.0f); // amount set to 20 for example
    }
 
    public string FirstName { get; private set; }
 
    public string LastName { get; private set; }
 
    private Wallet _wallet;
 
    public float PayAmount(float amountToPay)
    {
        if (_wallet.Value >= amountToPay)
        {
            _wallet.SubMoney(amountToPay);
            return amountToPay;
        }
        return 0;
    }
}
 
public class Paperboy
{
    public void SellPaper(Customer customer)
    {
        var payment = 2.0f;
        var amountPaid = customer.PayAmount(payment);
        if (amountPaid != payment)
        {
            // come back later
        }
    }
}

Now, the paperboy can only access to the first name and last name of the customer, without being able to modify them (for invoicing purposes for example). And he can tell the later to pay a certain amount for the paper without knowing that the money comes from a wallet, the LoD is also known as the principle of least knowledge. The relationship between the Paperboy class and the Wallet class has been removed, the code is less coupled.

With my refactoring, I increased the readability and the maintainability of my code without losing any functionality.

More than simple dot counting

Sometimes the Law of Demeter is stated with a simple phrase: “use only one dot“. This aims to focus on avoiding lines like the following, from the initial example:

customer.Wallet.Value;
customer.Wallet.SubMoney();

The risk with doing this is that you can have a NullReferenceException if the Wallet instance is not initialized, in these examples I used 2 dots. And here it is an indication that the LoD is violated.

But this is not always the case and this is why I consider that the rule should not be sum up to the simple “only one dot” principle. When working with the .NET framework and especially with Linq, it is easier to chain the calls and it has been designed to be used that way. I don’t consider that the following code sample breaks the LoD even if I use more than one dot.

enumerable.Where(o => o.LastName == "Doe").Select(o => o.FirstName).ToList();

The LoD is about loose coupling and encapsulation, it is not about dot counting.

This is the end of my presentation of the Law of Demeter, which I use a lot to avoid unnecessary coupling in my code. Remember that when working with an OOP language you are able to control the way you design your components to expose only what is required and nothing more.

See you next time!


Image credits:

http://sterendenn.deviantart.com/art/Art-Nouveau-Demeter-255076200

SOLID: Dependency Inversion Principle

inversion-arrowsIt is time to see the fifth and last principle of SOLID: the Dependency Inversion Principle, also known as DIP. If you missed the other principles, you can learn more about them by following these links:

When developing software you will have a lot of different modules having each their role and responsibility. You will have to connect these modules between them in order to create the desired functionalities for your system. They will have dependencies between them and it will increase the coupling between your components. So it is important to reduce the risk involved in these dependencies. This is where the DIP rules come in play:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

When a high-level module (business service for instance) depends on low-level module (data validator, a repository, …) it is difficult to reuse this module because it is highly coupled.

I have created an example that violates the DIP and I will show a way to solve the issue.

public class User
{
    public string UserName { get; set; }
    // some more properties
}
 
public class UserRepository
{
    public User GetUser(string userName)
    {
        // retrieve user in Database
        return new User();
    }
}
 
public class NotificationService
{
    public void Send(string message, User user)
    {
        // populate a message with the user information
        // send the message
    }
}
 
public class MessageSender
{
    // Send a message to a specific user
    public void SendMessage(string message, string userName)
    {
        var userRepository = new UserRepository();
        var user = userRepository.GetUser(userName);
 
        var notificationService = new NotificationService();
        notificationService.Send(message, user);
    }
}

In this piece of code my high-level module is the MessageSender, it allows me to send a given message to a given user (found by its username). For example this is a class that can be used from a user interface with a form. You can see that it has dependencies on a repository and a service, a modification of one of them can have impacts on my class. And what if I want to retrieve my user through a web service instead of the database? Or if I want to be able to send message to my friend via Twitter, Facebook or another social network? I will have to add complexity in this module even if its responsibility does not change from a “business” point of view.

My code is highly coupled and violates the Dependency Inversion Principle, I have to change it and I will by using abstraction (interfaces in my case).

public interface IUserRepository
{
    User GetUser(string userName);
}
 
public class UserRepository : IUserRepository
{
    public User GetUser(string userName)
    {
        // retrieve user in Database
        return new User();
    }
}
 
public interface INotificationService
{
    void Send(string mesage, User user);
}
 
public class NotificationService : INotificationService
{
    public void Send(string message, User user)
    {
        // populate a message with the user information
        // send the message
    }
}
 
public class MessageSender
{
    public INotificationService NotificationService { get; set; }
    public IUserRepository UserRepository { get; set; }
 
    // Send a message to a specific user
    public void SendMessage(string message, string userName)
    {
        var user = UserRepository.GetUser(userName);
        NotificationService.Send(message, user);
    }
}

In this new version I only use contracts/abstractions for my high-level component and this way I reduced the coupling with the implementations of the low-level modules. I decided to expose the dependencies via properties to access them and set them in order to clean the “SendMessage” method. When using this class I can now specify if I want to use an EmailNotificationService, a TwitterNotificationService, another social network related service or even a test double if I am in a test context.

Imagine creating automated tests with the first implementation! I would have to create an actual database for my UserRepository and a STMP service for my email based NotificationService. All of this only to test this little piece of logic, with abstraction and dependency inversion it is much easier now to test my components. A few months ago I introduced a DIP pattern known as Dependency Injection, you can learn more here.

This is the end of my presentation of the Dependency Inversion Principle and the end of the SOLID principles as well. I hope you like it and do not hesitate to leave a comment if you want to improve the concepts I have introduced in these blog posts.

See you next time!

SOLID: Interface Segregation Principle

multi-cablesIn my latest posts I introduced the Single Responsibility Principle, the Open Closed Principle and the Liskov Substitution Principle of SOLID. Now it is time to see the Interface Segregation Principle (ISP). In Object Oriented Programming (OOP) abstraction is a valuable asset especially with interfaces that allow you to design your application by contracts. Even if the interfaces do not contain any actual code it is important to control their size. The following sentence defines the ISP rule:

Clients should not be forced to depend on methods they do not use.

In other words it means that you should have small dedicated interfaces instead of larger ones. This way the client code will only have access to the functionalities it needs. I have created an example to show how the ISP can be violated and how to fix it.

public interface IRepository<T> where T : class
{
    void Insert(T entity);
    void Update(T entity);
    T Get(int id);
    void Delete(int id);
}

I have this interface that represents a repository to manipulate the entities stored in my database, it has the basic CRUD (Create Read Update Delete) operations. I will use this interface on my User entity:

public class User
{
    public int Id { get; set; }
    // other properties
}
 
public class UserRepository : IRepository<User>
{
    public void Insert(User entity)
    {
        // save user in DB
    }
 
    public void Update(User entity)
    {
        // update user in DB
    }
 
    public User Get(int id)
    {
        // retrieve user from DB
        return new User();
    }
 
    public void Delete(int id)
    {
        // delete user from DB
    }
}

Good, I have now a full control over my User objects lifetime in the database. Now I also want to be able to retrieve some event logs to be able to consult them, I will use my repository interface to do so.

public class EventLog
{
    public int Id { get; set; }
    public string Message { get; set; }
    // other properties
}
 
public class LogRepository : IRepository<EventLog>
{
    public void Insert(EventLog entity)
    {
        // nothing to do
    }
 
    public void Update(EventLog entity)
    {
        // nothing to do
    }
 
    public EventLog Get(int id)
    {
        // retrieve log from DB
        return new EventLog();
    }
 
    public void Delete(int id)
    {
        // nothing to do
    }
}

The issue is that my logs are stored in the database by other applications and in the one I’m working on I don’t have any logging to do. This force me to leave 3 methods empty since they are not used but are defined in my interface… This is clearly a violation of the Interface Segregation Principle. In this example I have a repository that is “read & write” and another that is just “read”. My abstraction is not correct in my context.

I have to find a solution that allows me to keep the functionalities for both repositories without breaking the ISP. I will then create two separate interfaces:

public interface IReadRepository<T> where T : class
{
    T Get(int id);
}
 
public interface IWriteRepository<T> where T : class
{
    void Insert(T entity);
    void Update(T entity);
    void Delete(int id);
}

As you can see one is dedicated to “read” operations and the other to “write” operations. My LogRepository can now inherits the IReadRepository because it does not need anything else.

public class LogRepository : IReadRepository<EventLog>
{
    public EventLog Get(int id)
    {
        // retrieve log from data source
        return new EventLog();
    }
}

And what about the UserRepository? Since it is “read & write” it will implement both interfaces. Multiple inheritance is commonly use when the ISP is in play.

public class UserRepository : IReadRepository<User>, IWriteRepository<User>
{
    public void Insert(User entity)
    {
        // save user in DB
    }
 
    public void Update(User entity)
    {
        // update user in DB
    }
 
    public User Get(int id)
    {
        // retrieve user from DB
        return new User();
    }
 
    public void Delete(int id)
    {
        // delete user from DB
    }
}

With time my application is likely to grow and use more and more entities from the database that will need “read” and “write” operations. If it is the case I can create an IReadWriteRepository that will be defined like this:

public interface IReadWriteRepository<T> : IReadRepository<T>, IWriteRepository<T>
    where T : class
{
 
}

In my example the UserRepository can implement this interface since it works as an alias over the two other ones. The ISP does not prevent you from regrouping interfaces under a common one. This will allow your code to be “cleaner” and explicit without losing functionalities.

This is the end of the Interface Segregation Principle presentation, remember to look for partial implementations of an interface if you want to spot where the ISP is violated.

I hope you liked this 4th principle of the SOLID series and as always do not hesitate to share, comment and give your opinion.

See you next time!

SOLID: Liskov Substitution Principle

lego-duploIt is time for the third entry for the SOLID series, after the SRP and the OCP, I’ll introduce the Liskov Substitution Principle (LSP). This concept has been introduced by Barbara Liskov in 1984, with Jeannette Wing they define this principle as the following:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S, where S is a subtype of T.

Well, if you are like me you must be still trying to figure this one out to understand how it can be applied to Object Oriented Programming. Do not worry, a more accessible rule has been defined to specify the LSP.

Subtypes must be substitutable for their base types.

In other words it means that consuming any implementation of a base class should not change the correctness of the system. To give more depth to this principle I will use the famous Rectangle-Square example to show how this rule can be violated.

public class Rectangle
{
    public int Width { get; set; }
    public int Length { get; set; }
    public virtual int CalculateArea()
    {
        return Width * Length;
    }
}
 
public class Square : Rectangle
{
    public override int CalculateArea()
    {
        return Width * Width;
    }
}

As you can see, the Square is a subclass of Rectangle and that makes sense since a square is a rectangle with the same width and length. Now I will use these two classes in a program:

class Program
{
    static void Main(string[] args)
    {
        Rectangle rectangle = new Square();
        rectangle.Length = 10;
        rectangle.Width = 5;
        Console.WriteLine("Area : {0}", rectangle.CalculateArea());
    }
}
Area: 25

Let me resume the situation: I have a rectangle of 10 by 5 and its area is 25?! This does not make sense. Even if the inheritance seems legitimate, the way it is used in my application violates the Liskov Substitution Principle.

Using the NotSupportedException of the .NET framework is likely showing that the LSP is not respected in your source code. There is even a part of this same framework that transgress this principle.

class Program
{
    static void Main(string[] args)
    {
        ICollection<int> collection = new ReadOnlyCollection<int>(new List<int>{1,2});
        collection.Add(3);  // throws a NotSupportedException
    }
}

The ReadOnlyCollection does not allow any modification to the collection, it is impossible to add or remove items in it. Yet its the ICollection interface that defines methods to manipulate the items: the LSP is clearly violated.

The LSP is closely related to the Design by Contract approach to create software. This way your thinking ahead of the pre-conditions,  post-conditions and side effects for your application and every implementations of your subtypes are related to your contracts.

This is the end of the introduction to the Liskov Substitution Principle and especially how to detect when the rule is broken. I am still working on a relevant example to demonstrate how to start from a “bad” code sample, like the ones I gave you, to a sample that respect the LSP.

In the meantime do not hesitate to give your opinion regarding this topic.

See you next time!

SOLID: Open Closed Principle

dutch-door

In my last entry I introduced the S of the SOLID principles: Single Responsibility Principle. Today I will move to the next letter, the O which stands for Open Closed Principle. In an agile environment, teams and projects have to be responsive to change (4th value of the agile manifesto) in order to steadily add value (2nd value of the software craftsmanship manifesto). But respecting these values can be really hard if the code of your application is not easily extensible. This is where this second principle come in play.

Software entities (classes, modules, functions, etc…) should be open for extension but closed for modification.

This is the rule for the Open Closed Principle. There are 2 key attributes in this statement and in the name of the principle as well: open & close. Even if they are in opposition this does not imply that they block each other.

The module is open for extension, this means that it can be extended with new behaviors as the requirements for the application change. Yet the module is also closed for modification, in other words it implies that you should be able to extend the functionalities of this module without modifying its source code. I know it might sound confusing and this is why I’ll show an example to explain how this principle can be used.

public class User
{
    // some properties
}
 
public class NotificationCenter
{
    public void NotifyByEmail(User user, string message)
    {
        // some email related logic
    }
 
    public void NotifyByText(User user, string message)
    {
        // some texting relating logic
    }
}

In this piece of code I created a class that allows me to send notifications to a user by email or by text. Now imagine that I want my application to notify my users using social networks… I will have to modify the source code of this class to add new behaviors and it clearly violates the OCP. I will update my class in order to change this “mistake”:

public interface INotificationService
{
    void SendMessage(User user, string message);
}
 
public class EmailNotificationService : INotificationService
{
    public void SendMessage(User user, string message)
    {
        // some email related logic
    }
}
 
public class TextNotificationService : INotificationService
{
    public void SendMessage(User user, string message)
    {
        // some texting related logic
    }
}

public class FacebookNotificationService : INotificationService
{
    public void SendMessage(User user, string message)
    {
        // some facebook related logic
    }
}
 
public class TwitterNotificationService : INotificationService
{
    public void SendMessage(User user, string message)
    {
        // some twitter related logic
    }
}
 
public class NotificationCenter
{
    public void Notify(User user, string message, INotificationService service)
    {
        // some logic
        service.SendMessage(user, message);
    }
}

My NotificationCenter now use a specific interface to do its work and I am able to add functionalities to it without changing the code. All I have to do is to implement the INotificationService to add a new behavior. By doing this I can even separate each implementation in a specific assembly and I avoid putting Facebook or Twitter dependencies in my class. For instance if the Twitter API changes and I have to change the code, I can only package and deliver the TwitterNotificationService, I don’t have to redeploy everything.

The key to the OCP is abstraction. Yet this does not mean that you have to use it everywhere, the context is important and premature abstraction may add complexity to your source code where it is not needed.

I hope you like this presentation of the Open Closed Principle for the SOLID series. You can also check this great article by Joel Abrahamsson about this principle.

See you next time!

SOLID: Single Responsibility Principle

swiss-army-knifeA blog about software craftsmanship cannot be complete without mentioning the SOLID principles. I discovered these principles about a year ago and it completely changed the way I write software and think about it. By using SOLID I feel like my code is more robust than before, more understandable, more maintainable and easier to test. Will them solve all your problems? Of course not but, in my opinion, it can definitely help you writing better crafted software. There are 5 object-oriented programming principles in SOLID:

  • Single Responsibility Principle (SRP)
  • Open Close Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)

And today I will present the first one, the Single Responsibility Principle, by giving an example and explaining my understanding of this principle.

A class should have only one reason to change.

This is the rule of this first principle. Is that all? Yes it is, so now I will give details about the meaning of this rule and what it implies. If a class has more than one reason to change it means that this class certainly have more than one responsibility. If you are not able to describe the goal of your class with a short sentence you are most likely violating the SRP. And if your short sentence contains words like “or”, “and” or “then” you probably violates this principle as well.

I will use a basic example to demonstrate the concept of this principle. I created the following helper class:

class EmailHelper
{
    public void Validate(string email)
    {
        // some validation logic
    }
 
    public void Send(string email, string message)
    {
        // some sending logic
    }
}

So, what does this class do? I can answer by the following sentence: “This class helps manipulating email addresses”. I did use a short sentence to describe my class and without saying “and” or “or”. True, but in my opinion this is definitely imprecise and it reveals that the SRP might be violated. To describe this class I would much likely say: “This class validates email addresses and sends a message to a given address”. This is much more accurate and it shows that the class has more than one responsibility.

To respect the Single Responsibility Principle, I will create two different classes having each its own responsibility:

class EmailValidator
{
    public void Validate(string email)
    {
        // some validation logic
    }
}
 
class EmailSender
{
    public void Send(string email, string message)
    {
        // some sending logic
    }
}

I now have a class that validates a given email address and another that sends a message to an email address. I can now use the validation logic without having the sending logic in the same “area”. I know that my example might look mundane and sometimes it is much more difficult to tell if the SRP is violated or not. I can only advise you to keep the rule in mind to tell if you are respecting the SRP.

I hope you like this introduction to the Single Responsibility Principle from SOLID. And as always do not hesitate to share your opinion on this topic.

If you want to know more about the SRP and the SOLID principles I recommend to acquire the “Agile Principles, Patterns and Practices in C#” book by Robert “Uncle Bob” Martin and Micah Martin.

See you next time!

The Null Object Pattern

empty-frameIn a lot of object-oriented programming languages there is a moment where we have to deal with null pointers/references/objects. These references must be checked to avoid any exception that might end the program in an unexpected way or moment. I think that most of us have encountered this type of error at least once in our lives. Tony Hoare said that the introduction of the null reference is its “billion-dollar mistake”. Yet sometimes it is possible to avoid the use of null pointer in our application by using the Null Object Pattern.

The intent of this pattern is to provide a specific implementation of an abstraction by doing nothing, it is used to replace manipulation of undefined references (null) when it can be and is therefore predictable (again, it does nothing).

I have created the following piece of code, in C#, to show how it can be done.

public class User
{
    public enum NotificationTypes
    {
        Email,
        Text,
        Twitter,
        None
    }
 
    public string Name { get; set; }
 
    public NotificationTypes NotificationPreference { get; set; }
}
public interface INotifier
{
    void Notify(User user, string message);
}
 
public class EmailNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by email", user.Name, message);
    }
}
 
public class TextNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by text", user.Name, message);
    }
}
 
public class TwitterNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by twitter", user.Name, message);
    }
}
 
public static class NotifierFactory
{
    public static INotifier CreateNotifier(User user)
    {
        switch (user.NotificationPreference)
        {
            case User.NotificationTypes.Email:
                return new EmailNotifier();
            case User.NotificationTypes.Text:
                return new TextNotifier();
            case User.NotificationTypes.Twitter:
                return new TwitterNotifier();
        }
        return null;
    }
}
static void Main(string[] args)
{
    var bob = new User { Name = "Bob", NotificationPreference = User.NotificationTypes.Email };
    var john = new User { Name = "John", NotificationPreference = User.NotificationTypes.Text };
    var martin = new User { Name = "Martin", NotificationPreference = User.NotificationTypes.Twitter };
    var jeff = new User { Name = "Jeff", NotificationPreference = User.NotificationTypes.None };
 
    var users = new List<User> { bob, john, martin, jeff };
 
    foreach (var user in users)
    {
        var notifier = NotifierFactory.CreateNotifier(user);
        if (notifier != null)
        {
            notifier.Notify(user, "This is a message");
        }
    }
}

In this example, a message is sent to several users using the notification system they prefer. And they can turn off the notification system by choosing the “None” option and in this case the Notifier instance returned by the factory is null and force us to put a check in the calling code to avoid any NullReferenceException. As you can see, if the Notifier is null there is no particular behavior, this is a sign that the Null Object Pattern might be used. To use this pattern, the first thing to do is to add a new implementation of INotifier:

public class NullNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        // Nothing to do
    }
}

I can now update my factory to return an instance of this new class instead of null:

public static class NotifierFactory
{
    private static INotifier NullNotifier = new NullNotifier();
 
    public static INotifier CreateNotifier(User user)
    {
        switch (user.NotificationPreference)
        {
            case User.NotificationTypes.Email:
                return new EmailNotifier();
            case User.NotificationTypes.Text:
                return new TextNotifier();
            case User.NotificationTypes.Twitter:
                return new TwitterNotifier();
        }
        return NotifierFactory.NullNotifier;
    }
}

Since the Null Object Pattern is stateless, it is common to use it as a Singleton, this is why I used a static field to hold the reference to the pattern. I can now clean the caller code by removing the null check:

static void Main(string[] args)
{
    var bob = new User { Name = "Bob", NotificationPreference = User.NotificationTypes.Email };
    var john = new User { Name = "John", NotificationPreference = User.NotificationTypes.Text };
    var martin = new User { Name = "Martin", NotificationPreference = User.NotificationTypes.Twitter };
    var jeff = new User { Name = "Jeff", NotificationPreference = User.NotificationTypes.None };
 
    var users = new List<User> { bob, john, martin, jeff };
 
    foreach (var user in users)
    {
        var notifier = NotifierFactory.CreateNotifier(user);
        notifier.Notify(user, "This is a message");
    }
}

Now my application has the same behavior as before and is cleaner. With the Null Object Pattern I have been able to remove a check for a null reference in my code without losing any functionality. This pattern may look like a test double but its purpose is not for testing, it’s for production code and match a case of the domain model: in my example the absence of notification is a deliberated choice.

The Null Object Pattern is often used with the Factory pattern (like in my example). You should consider this pattern if you have null check over an abstraction that does not trigger any behavior.

I hope you like this presentation of the Null Object Pattern, and as always do not hesitate to comment.

See you next time!

Dependency Injection and highly coupled objects

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

public class IndexController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = HttpContext.Request.UserLanguages;
        return View(model:languages);
    }
}
@model string[]
@{
    Layout = null;
}
 
<!--DOCTYPE html>
 
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Index</title>
</head>
<body>
    <div> 
        @foreach (string language in Model)
        {
            @language
            <br/>
        }
    </div>
</body>
</html>

This view displays the languages preferences from the request for the visitor:

languages-preferences

Now, I want to test my Controller (even if there is no logic in my example) with the following code:

[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController();
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

I just want to check that the view is not null but the test fails. I get a NullReferenceException because the HttpContext property of the Controller is null. This happens because there is no web context when executing the test and it makes sense since the execution occurred in a test context.

The first thing that comes to mind to fix this issue is to set the HttpContext property with a mock. But I cannot do that because this property is read only and thus I am not able to set it when doing the instantiation of the controller in the test method.

And if you need to mock the HttpContext class, you cannot because it is sealed. To avoid this you can use the HttpContextBase abstract class instead but in a test environment you will have to implement it in order to mock it and you don’t want to do this. Why? Because it’s a pain to do, you will have to provide implementation for everything, it’s like creating an entire web context just for the test. And in my case I just need the user languages.

So? What now? Do we give up testing our controllers? Absolutely not, it is possible to achieve our goal without too much complications. From the beginning I tried to mock the wrong thing. What I need is the user languages not the HttpContext, so let’s remove this dependency. I created the following interface with the data my code will use:

public interface IWebContext
{
    string[] UserLanguages { get; }
}

And now I will inject this interface in my Controller and I will create a specific implementation that will use the HttpContext to retrieve the languages from the request:

public class RealContext : IWebContext
{
    private HttpContext _context;
 
    public RealContext(HttpContext context)
    {
        _context = context;
    }
 
    public string[] UserLanguages
    {
        get { return _context.Request.UserLanguages; }
    }
}
 
public class IndexController : Controller
{
    IWebContext _context;
 
    public IndexController()
        : this(new RealContext(System.Web.HttpContext.Current)) { }
 
    public IndexController(IWebContext context)
    {
        _context = context;
    }
 
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = _context.UserLanguages;
        return View(model:languages);
    }
}

Note that I created a parameters-less constructor that instantiate the dependency, without this constructor the ASP .NET MVC will not be able to create the Controller (it won’t even compile).

I can now update my test by using a mock for my interface:

public class MockContext : IWebContext
{
    public string[] UserLanguages
    {
        get { return new string[1]; }
    }
}
 
[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController(new MockContext());
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

My test is now passing! I removed the dependency between the test and the web context objects, I can now test the logic of my controller without having to set up an awful lot of mocks.

I encapsulated my specific logic inside an abstraction that is far easier to mock. This way I was able to reduced the coupling, I was also able to increase my code coverage and all of it without losing any behavior.

You can use this technique for other properties of the HttpContext like the user agent if you want to apply some logic on it and test it. Or also for static classes/methods (that you can maybe found in your legacy code).

I hope this will help you and as usual do not hesitate to leave a comment.

See you next time!