On mutable shared state

Problems with mutable shared state are often discussed in a concurrent programming context. However, those who are lucky enough to avoid concurrent programming can still fall in trouble because of mutable shared state. First pitfall is a global variable. Everyone knows global variables are bad. Although in software design there is no absolute truth or principle, this statement is almost always true. But why are they bad? The full list of reasons can be looked up here, but in a few words – it is because it hinders code understandability and can cause nasty bugs. Understanding of function which uses global variable is never easy because you can not reason about it only by its signature. You can never predict its behavior because you can never be sure what state will global variable have during function’s execution. For the same reason, it is easy to make a mistake during coding.

So, if you don’t use global variables and don’t do concurrent programming, are you safe then? Not really. First, sometimes you can’t avoid global variables. For example, if you program in JavaScript. The problem with JavaScript is that it requires global variables. JavaScript does not have a linker. All compilation units are loaded into a common global object. Second, in case you are doing ordinary object-oriented programming, you can fall in trouble with your objects’ state. Take a close look at this design:

public class Student
{
    public string Name { get; set; }
    public int Age { get; set; }
}

public class AcademicGroup
{
    private readonly List<Student> _students;

    public AcademicGroup(List<Student> students)
    {
        if (HaveUniqueNames(students))
            _students = students;
        else
            throw new ArgumentException(
                "Two or more students with the same names are not allowed!");
    }

    public bool IsValid()
    {
        return HaveUniqueNames(_students);
    }

    private bool HaveUniqueNames(List<Student> students)
    {
        return students
            .Select(s => s.Name)
            .Distinct()
            .Count() == students.Count;
    }
}

AcademicGroup is perfectly encapsulated little class which holds a list of students and for this class to be valid all those students must have unique names. To ensure this, we have validation check in the constructor. Internal data is private (and even read-only!), hence it seems like no one can destroy successfully constructed object of this class. However, look at this usage of the class:

class Program
{
    static void Main()
    {
        var students = new List<Student>
            {
                new Student { Name = "Arnold Schwarzenegger", Age = 18},
                new Student { Name = "Britney Spears", Age = 20},
                new Student { Name = "Barak Obama", Age = 19}
            };

        var academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        var anotherBritney = new Student { Name = "Britney Spears", Age = 30 };
        students.Add(anotherBritney);
        Console.WriteLine(academicGroup.IsValid()); //False

        students.Remove(anotherBritney);
        academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        students.FirstOrDefault(s => s.Name == "Britney Spears").Name = "Barak Obama";
        Console.WriteLine(academicGroup.IsValid()); //False
    }
}

Nice, is not it? Especially nice to ask students about encapsulation using an example like this one. The internal state of the academic group has been broken after its construction. This line, students.Add(anotherBritney), could have happened anywhere in the system, so that you would search for the reason of having your object in the incorrect state for many hours. And maybe even on the customer side. The same issue arises when we use singleton pattern to simulate global variable.

The problem can be formulated as a combination of 3 conditions: 1) there is shared state between two modules (between Program and AcademicGroup there is the list of students); 2) there is a change of the shared state by one module without notifying another module which have references to this shared state (after creating object of AcademicGroup, Program changes list of students and does not notify about this action newly created object); 3) one of the modules which shares the state has assumptions about this state i.e. correctness of this module depends on the shared state (AcademicGroup assumes list of students to have unique references).

To avoid this problem, one must do one of the following 1) Make shared state immutable; 2) Notify all others about the change of the shared state which they depend on; 3) All modules should avoid making any assumptions about the shared state.

In my example, I can’t avoid making assumptions about incoming to AcademicGroup data. Therefore, I can try to do notification by adding another method to the AcademicGroup:

public class AcademicGroup
{
...
    public void NotifyAboutStudentsChange()
    {
        if (!IsValid())
            throw new
                InvalidConstraintException(
                   "Two or more students with the same names are not allowed!");
    }
....
}

And then notifying all objects of AcademicGroup like this:

class Program
{
    static void Main()
    {
        var students = new List<Student>
            {
                new Student { Name = "Arnold Schwarzenegger", Age = 18},
                new Student { Name = "Britney Spears", Age = 20},
                new Student { Name = "Barak Obama", Age = 19}
            };

        var academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        var anotherBritney = new Student { Name = "Britney Spears", Age = 30 };
        students.Add(anotherBritney);
        academicGroup.NotifyAboutStudentsChange();  //Trows
        Console.WriteLine(academicGroup.IsValid()); //This line never executes

        students.Remove(anotherBritney);
        academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        students.FirstOrDefault(s => s.Name == "Britney Spears").Name = "Barak Obama";
        academicGroup.NotifyAboutStudentsChange(); //Trows
        Console.WriteLine(academicGroup.IsValid()); //This line never executes
    }
}

Nasty mess, is not it? But without it, we have a design flaw which makes our code hard to understand and buggy. But don’t get me wrong, I am not suggesting creating stuff like this in your designs. No, although it is a solution if you can’t avoid assumptions about shared state and you can’t make shared state immutable. To my mind the best solution here is going functional way, even though in some cases it may be less efficient. Here is what well-designed code would look like (thanks to heaven we now have immutable collections in .NET 4.5):

class Program
{
    static void Main()
    {
        var students = new List<Student>
            {
                new Student(name: "Arnold Schwarzenegger", age: 18),
                new Student(name: "Britney Spears", age: 20),
                new Student(name: "Barak Obama", age: 19)
            };

        var academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        var anotherBritney = new Student(name: "Britney Spears", age: 30);
        students.Add(anotherBritney);
        Console.WriteLine(academicGroup.IsValid()); //True

        students.Remove(anotherBritney);
        academicGroup = new AcademicGroup(students);
        Console.WriteLine(academicGroup.IsValid()); //True
        
        //This does not even compile anymore: 
        //students.FirstOrDefault(s => s.Name == "Britney Spears").Name = "Barak Obama";
        
        var student = students.FirstOrDefault(s => s.Name == "Britney Spears");
        students[students.IndexOf(student)] =
            new Student(name: "Barak Obama", age: students[students.IndexOf(student)].Age);
        Console.WriteLine(academicGroup.IsValid()); //True
    }
}
public class Student
{
    //This can be done only in C# 6
    //In C# 5 you have to create readonly backing fields
    public string Name { get; }
    public int Age { get; }

    public Student(string name, int age)
    {
        Name = name;
        Age = age;
    }
}
public class AcademicGroup
{
    private readonly ImmutableList<Student> _students;

    public AcademicGroup(IEnumerable<Student> students)
    {
        _students = students.ToImmutableList();
        if (!HaveUniqueNames(_students))
            throw new ArgumentException(
                "Two or more students with the same names are not allowed!");
    }

    public bool IsValid()
    {
        return HaveUniqueNames(_students);
    }

    private bool HaveUniqueNames(IReadOnlyCollection<Student> students)
    {
        return students
            .Select(s => s.Name)
            .Distinct()
            .Count() == students.Count;
    }
}

To conclude, I would say I start more often thinking that I am not a fan of classical object-oriented programming anymore. Some functional elements, like immutable state, seem to be a really powerful tool to simplify designs and make us less likely to write a bug.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

C# implicit user-defined type conversion

C# has a very nice little feature named implicit user-defined type conversion. By far not every developer knows about its existence because its application is very limited. However, sometimes it can be very handy to help you increasing the readability of the code by removing unnecessary clutter.
For example, you have to write many functions, which take double[ ][ ], transform it in some way and return double[ ][ ]. Very soon you will want to extract low-level operations on double[ ][ ] into separate class Matrix. Something like this:

class Matrix
{
    private readonly double[][] _m;

    public Matrix(double[][] m)
    {
        _m = m;
    }
    public Matrix Transpond()
    {
        return new Matrix(
            _m
            .First()
            .Select((sink, i) => _m.Select(row => row.ElementAt(i)).ToArray())
            .ToArray());
    }

    public Matrix Map(Func<double, double> map)
    {
        return new Matrix(
            _m
            .Select(vector => vector.Select(map).ToArray())
            .ToArray());
    }

    public double[][] ToJaggedArray()
    {
        return _m;
    }
}

All valuable methods in Matrix class return transformed Matrix. It is done to enable chaining matrix methods. Here is usage of the Matrix class:

class Program
{
    static void Main()
    {
        var m = new[]
        {
           new[] {1.0, 2.0},
           new[] {3.0, 4.0}
        };
        Print(m);
        Print(Transform(m));
    }

    public static double[][] Transform(double[][] m)
    {
        // As you can see, it is possible to chain method calls
        // And also you have to call ToJaggedArray() method
        return new Matrix(m)
            .Transpond()
            .Map(x => x * 100)
            .ToJaggedArray();
    }

    static public void Print(double[][] m)
    {
        foreach (double[] row in m)
        {
            foreach (double cell in row)
            {
                //New C# 6 feature, named Interpolated Strings
                Console.Write($"{cell} ");
            }
            Console.WriteLine();
        }
        Console.WriteLine();
    }
}

Note the call to ToJaggedArray method to be able to return from Transform method. You have to write it over and over again in every method like Transform. But conceptually double[ ][ ] and Matrix type are the same things! It would be nice to have seamless conversion from one type to another. And C# gives a tool to do this. Let’s add one more method to Matrix class:

class Matrix
{
    ...

    public static implicit operator double[][](Matrix m)
    {
        return m.ToJaggedArray();
    }
}

This weird syntax is implicit user-defined type conversion. It basically says to execute this code every time user tries to assign Matrix object to the reference of type double[ ][ ]. Now it is legal to rewrite the Transform method in the following way:

class Program
{
    ...
    public static double[][] Transform(double[][] m)
    {
        //Legal to return Matrix even though return type is double[][]
        return new Matrix(m)
            .Transpond()
            .Map(x => x * 100); 
    }
    ...
}

This same trick can be done in unit tests which use Builder pattern. It spares you from calling Build() method every time you want to get final product from your builder.

Be cautious, though. This tool as every other tool can be abused. You should not apply it to convert logically unrelated things, like getting the driver from the car. Such a code would be extremely confusing:

var car = new Car();
Driver d = car;

Sometimes you would also like to be able to write something like this:

Matrix m = new double[][]{...};

Such things could be done using extension methods if they supported implicit conversion syntaxis. But they don’t. Hence, you can’t make this expression legal, at least for now (in C#6 as well).

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

My 7 favorite code design authors

In this post, I would like to share the list of my 7 favorite authors on code design. Books, articles, and courses from these guys made a huge impact on the way I code today. All of them have written at least one book which focuses on code design for maintainability, understandability or readability. These books are very interesting to read. When you finish them, you feel enlighted.

Robert C. Martin. It is hard to explain why I like this guy so much! I believe he has made the greatest contribution to the clean code movement. He focuses on having everything clean. His books (especially Clean Code one) are on every developer’s shelve. His presentations are really fun to watch. I think everyone should do presentations this way, otherwise there is no real need to do a presentation. People can always read the information on the web without spending much time listening to you. Robert has always deep insight. Most of his appearance makes me think hard on the topic. And his clean coders videos are awesome: entertaining and teach a lot!

Martin Fowler made a huge impact to the code design by his refactoring book. Maybe he is not the one who invented refactoring, but he is the one who brought refactoring to the everyday practice of millions of developers. Although Martin focuses on enterprise systems design, he very often writes a lot of useful information on code level design on his Bliki. He also wrote a very interesting book, on domain specific languages. This book did not become very popular, but it is extremely interesting from the code design point of view. For example, there you can learn how to design fluent interfaces (which are very popular in today frameworks).

Mark SeemannMark Seemann is the author of well-known in .NET community book Dependency Injection in .NET. Although the book is somewhat specific, I enjoyed very much Mark’s Pluralsight courses. Especially the course Encapsulation and SOLID. What is interesting about Mark’s stuff is that he brings a lot of functional practice into ordinary OO coding. If you like to learn how to write clean code in the functional language like F# or how to improve the ‘cleanness’ of your OO code with functional techniques, you should definitely check out his blog and Pluralsight courses.

Michael Feathers wrote a great book named Working effectively with legacy code. There you will learn that author understands that real-world programming is not as beautiful and easy as it is in simple code examples. Michael gives guidelines how to deal with ugly legacy code out there (who managed to avoid working with a legacy in his career?) and gradually arrive at the better-designed code. This book is very good help for those who are overwhelmed with huge legacy systems and just don’t believe that clean code rules and principle could help them or are of any value in their situations. Michael continues writing on code design on his blog.

Steve McConnell is the author of the seminal book Code Complete. This book is rated in many polls as the best book on software engineering out there. And I would agree. Although the book is ancient (taking to account the speed of our industry) it is still widely bought and read. People still develop code construction courses and video tutorials based on this book. If I was limited to read only one book in my career, I would most probably choose this one. Unfortunately, Steve seems to stop his activity in code design/construction area. I can’t see anything new from him on the web and conferences.

Roy Osherove. You probably will be surprised to see him on this list. Roy mostly works in the unit testing area. But who said unit tests are not code? All automated tests are code and all this code should be clean as well as production code. Otherwise, its value will be neglected with maintenance cost. And this is Roy’s book’s, The Art of Unit Testing, main idea and focus. He teaches you the way you should design your test code to avoid maintenance nightmare. Roy is still active on the topic, writes blog posts and records a lot of video on automated tests design. All of this content can be reached here.


Douglas Crockford/Jon Skeet
. Yes, 2 guys. But I did not want to break nice number 7. And they somewhat belong together, because on the 7-th position I wanted to put language, guru. But everyone develops in his own language. As .NET web developer, my languages are JavaScript and C#, hence gurus are Douglas Crockford are Jon Skeet. There are many experts on these languages, however. Why did I pick this couple? Because they care a lot about creating clean, maintainable code in their languages. They research, speak and participate in language development with clarity and readability in mind. Douglas’ JavaScript: The Good Parts and Jon’s C# in Depth are masterpieces. If you follow these guys closely, you will master not only JavaScript and C# but you will also learn how to design maintainable code in these languages. Also check out Jon’s videos specifically devoted to code design in C#.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail