A journey towards software craftsmanship

Programming has been my passion right from the day I have seen computer. After nearly 3.7 years of experience (2 years of freelancing and 1.7 years of Industry), I found that there are lot of areas in programming where I need to improve myself especially in the art of software craftsmanship. Programming is really an art!!

Fine, I have the passion and wish to move to the next level but the key is get started and focussing my efforts on a right path. After some extensive internet searches and fruitful discussions with my colleagues, I have drawn a road map. I feel it is worth sharing through this blog as it might help someone who aspires to reach the next level in programming.

We can’t become Einstein in single night. We can’t become Sachin just by scoring a match winning century in a single match either. Likewise we can’t become a Master in Software Craftsmanship by just creating a single Killer Application. It takes a lot of efforts, passion, endurance persistence, temperament and a well-defined path to reach the top.

             As a programmer/developer we all know very well about the benefits of Code Reuse. Have you ever thought of Experience Reuse!! Just think about it for some minutes. Obviously there is no replacement/substitute for Experience but what’s wrong in learning from others experience. It requires both hard work and smart work to make it to the next level. Here I am mentioning about smart work. Why are we doing the same mistakes which some people did already in their lives?  Why don’t we just learn it from them and get rid of those recurring mistakes. Come on, we are programmers, be smarter. Let’s learn from the some of the masters in the field and do some new mistakesJ.

            Before start mentioning about those masters, I would like to thank my colleague “Jijesh Mohan” who has helped a lot and inspired me to start the journey (Now I hope, you will know what is mean by Experience Reuse). Here is the list of Masters.

• Robert C Martin
• Dave Thomas
• Martin Fowler
• Ward Cunningham
• Kent Beck
• Grady Booch
• Joel Spolsky
• Eric S Raymond

One great thing about all these excellent folks is they share their knowledge, either through Books or through their blogs. We are very fortunate. Now it’s our turn to learn from their wisdom and move forward.

“The man who does not read good books has no advantage over the man who can't read them.  -Mark Twain”

I have found the following magnificent books in the quest

• Pragmatic Programmer – Andrew Hunt, Dave Thomas
• Must Read for every programmer. In my perspective it is the Bible of Programming
• Clean Code – Robert C Martin
• Refactoring – Martin Fowler
• Art of Unix Programming – Eric S Raymond

I’ve read the Pragmatic Programmer and all others are in my “To-Read” list. I am really searching for words in dictionary to describe about “Pragmatic Programmer”. It is a “Gem”.

When it comes to blogs, we have “Google Reader”. Just subscribe to the blog posts of these eminent people through Google Reader and learn the art of programming.

The stage has been setup. No one can ride bicycle by reading a book on “How to Ride Bicycle”. What books and blog posts would offer us is knowledge. In addition to knowledge to move further we need another thing called “Practice”. Yes get your hands dirty. Experiment, Research, Critique, Analyse, involve in healthy debates with your colleagues on various aspects of software craftsmanship, work and feel passionate about your work.

I have pledged myself to follow the best practices in all my development works and no compromise on the quality of the code I write. In nutshell, I am going to care about my craft, think about my work and strive for excellence.

I am in the very early stage of becoming a better programmer and looking forward to listen to your suggestions and inputs on this. When we grow older, we will be stronger. With all blessings and hope, the journey begins!    

   

Observer Pattern using Delegates V/s Observer Pattern using Events and Delegates

Most of the articles and texts in C# demonstrate the observer pattern using events and delegates. When going through one such text, a thought come across my mind. Why we are going for events when we can easily achieve the multicasting using Delegates alone. After some R&D, I found it out why and hence this blog post.
I am going to explain this “why” using a Weather Station example. To keep things simple, the Weather Station that we are going to see will keep track of only the temperature. Whenever the temperature changes, it simplify notifies its subscribers with the new temperature. Flash News is one of the subscribers which show the temperature in flash news. News Feed, another subscriber which adds the temperature information to the news feed. Fine, enough theory! It’s time to see the code.
Here is the implementation of Observer Pattern using Delegates alone.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DelegatesAndEvents
{
    class WeatherStation
    {
        private int _temperature;
        public TemperatureReporter Reporter { get; set; }
        public int Temperature
        {
            get { return _temperature; }
            set
            {
                if (Reporter != null)
                {
                    Reporter(value);
                }
                _tempearture = value;
            }
        }
    }

    class NewsFeed
    {
        WeatherStation weatherStation;

        public void AddTemperatureInfoToFeed(int temperature)
        {
            Console.WriteLine("News Feed: New temperature " + 
                                temperature + " added to feed.");
        }

        public NewsFeed(WeatherStation weatherStation)
        {            
            this.weatherStation = weatherStation;
            weatherStation.Reporter += AddTemperatureInfoToFeed;
        }
    }

    class FlashNews
    {
        WeatherStation weatherStation;

        public void ShowTemperatureInfoInFlashNews(int temperature)
        {
            Console.WriteLine("Flash News: New temperature is " + temperature + ".");
        }

        public FlashNews(WeatherStation weatherStation)
        {            
            this.weatherStation = weatherStation;
            weatherStation.Reporter += ShowTemperatureInfoInFlashNews;
        }
    
    }
}
        

The Main Program

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DelegatesAndEvents
{
    public delegate void TemperatureReporter(int tempearture);

    class Program
    {
        static void Main(string[] args)
        {   
            // Observer Pattern Using Delegates                     
            WeatherStation weatherStation = new WeatherStation();
            FlashNews flashNews = new FlashNews(weatherStation);
            NewsFeed newsFeed = new NewsFeed(weatherStation);        
            weatherStation.Temperature = 30;
            weatherStation.Temperature = 15;
            weatherStation.Temperature = 45;
        }
    }
}

The output

Hurrah! It’s working as expected. Both subscribers are get notified. We can implement the observer pattern using delegates alone. Stop for a minute and go through the code, is the implementation robust? Kudos if you are able to find the shortcomings of this implementation. If not continue reading.
Think of a world where everyone is good. There is no need of police, no need of court either. But it is not the case. You may wonder why I am mentioning this here. This analogy holds true for the objective of this blog post too. There is no need of using events in the c# programming world if all the subscribers are good. Miserably, here also it is not the case. Hence we are going for events instead of using delegates alone.
Drawbacks of using delegates alone:

• A subscriber can replace other subscribers by reassigning the delegate
• A subscriber can clear all other subscribers also (by setting the delegate to null).
• A subscriber can broadcast to other subscribers by invoking the delegate

Clearly all the above 3 drawbacks violates the Observer Pattern.
Here is our evil subscriber code implementation.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DelegatesAndEvents
{
    class EvilSubscriber
    {
        WeatherStation weatherStation;

        public void EvilMessage(int temperature)
        {
            Console.WriteLine("The temperature is " + (temperature * 100));
        }

        public EvilSubscriber(WeatherStation weatherStation)
        {
            this.weatherStation = weatherStation;
            
            // Broadcast to all the subscriber
            weatherStation.Reporter(60);

            // Reassign the subscriber
            weatherStation.Reporter = EvilMessage;

            // Replace all the subscribers
            weatherStation.Reporter = null;

        }
    }
}
    

Hope now you understand the need of a better implementation of observer pattern. Here comes the salvage. Event! Use event along with delegates. With event in place, compiler will not allow the evil subscriber to get compiled.
Robust implementation of Weather Station using events.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DelegatesAndEvents
{    
    class WeatherStation2
    {
        private int _tempearture;
        public event TemperatureReporter Reporter;
        public int Temperature
        {
            get { return _tempearture; }
            set
            {
                if (Reporter != null)
                {
                    Reporter(value);
                }
                _tempearture = value;
            }
        }
    }

    class NewsFeed2
    {
        WeatherStation2 weatherStation;

        public void AddTemperatureInfoToFeed(int temperature)
        {
            Console.WriteLine("News Feed2: New temperature " + temperature + " added to feed.");
        }

        public NewsFeed2(WeatherStation2 weatherStation)
        {
            this.weatherStation = weatherStation;
            weatherStation.Reporter += AddTemperatureInfoToFeed;
        }
    }

    class FlashNews2
    {
        WeatherStation2 weatherStation;

        public void ShowTemperatureInfoInFlashNews(int temperature)
        {
            Console.WriteLine("Flash News2: New temperature is " + temperature + ".");
        }

        public FlashNews2(WeatherStation2 weatherStation)
        {
            this.weatherStation = weatherStation;
            weatherStation.Reporter += ShowTemperatureInfoInFlashNews;            
        }
    }
}
    

The unfortunate evil subscriber which failed to compile

    class EvilSubscriber2
        {
            WeatherStation2 weatherStation;

            public void EvilMessage(int temperature)
            {
                Console.WriteLine("The temperature is " + (temperature * 100));
            }

            public EvilSubscriber2(WeatherStation2 weatherStation)
            {
                this.weatherStation = weatherStation;

                // Broadcast to all the subscriber
                weatherStation.Reporter(60); // Compiler Error

                // Reassign the subscriber
                weatherStation.Reporter = EvilMessage; // Compiler Error

                // Replace all the subscribers 
                weatherStation.Reporter = null; // Compiler Error  

            }
        }
    

Summary
Critique what you read and analyze.You can download the source code from here