Why abstraction can be detrimental.

The other day someone asked a question about the relation between the Socket class, and the UdpClient class. Specifically, what is the relation? While the answer is simple because UdpClient is merely wrapper around a UDP initialized socket, this also lead me to thinking more about abstraction.

So what is abstraction?
Take the following code sample.

XDocument xdoc = XDocument.Load(ConfigurationFilePath);
string boolstr = xdoc
    .Element("ApplicationConfiguration")
        .Element("Settings")
            .Element("AutoLogin")
            .Attribute("Enabled")
            .Value;
return boolstr.Equals(Boolean.TrueString, StringComparison.OrdinalIgnoreCase);

Imagine if you had to write that every time you wanted to retrieve a value in a configurationfile. That's a lot of replicated code. In it's simplist form, a C# Property is a form of abstraction - it hides the underlying implementation. Functions can also be considered abstraction. So, in essence we could do the following.

/// <summary>
/// Gets or sets a System.Boolean value indicating whether automatic login is enabled
/// </summary>
public static bool AutoLoginEnabled {
    get {
        XDocument xdoc = XDocument.Load(ConfigurationFilePath);
        string boolstr = xdoc
            .Element("ApplicationConfiguration")
                .Element("Settings")
                    .Element("AutoLogin")
                    .Attribute("Enabled")
                    .Value;
        return boolstr.Equals(Boolean.TrueString, StringComparison.OrdinalIgnoreCase);
    }
    set {
        XDocument xdoc = XDocument.Load(ConfigurationFilePath);
        xdoc.Element("ApplicationConfiguration")
                .Element("Settings")
                    .Element("AutoLogin")
                    .Attribute("Enabled")
                    .Value = value ? Boolean.TrueString : Boolean.FalseString;
        xdoc.Save(ConfigurationFilePath);
    }
}

So what happened here? We took a segment of code and wrapped in a C# Property, hiding the underlying implementation. This is called abstraction. So now we can easily just call SomeClass.AutoLoginEnabled = true, and the Property takes care of the dirty work underneath. Now this is obviously a very basic concept of abstraction. Generally, real-world abstraction in program code means asbtracting base classes, services, and other really complex things, but the idea here to understand the basic concept of abstraction.

How this relates to UdpClient and Socket
I always thought the Socket class was easy enough, but I often find that quite a few people prefer to use UdpClient or TcpClient, because they feel that it is easier to work with. This may be the case, but even the Socket class is a layer of abstraction as it is a wrapper around the Berkeley socket interface.

C# makes abstraction easy to do. It's plain and simple. The reason this is dangerous though, is because often times developers create so many layers of abstraction, that it is often hard for either Jr. Developers or new people to the code to learn what is going on. I often find that many beginners in programming can understand the fundamentals of the code they are using. So in this case a beginner programmer may learn the UdpClient class inside-and-out, but in the end, they may not have a single clue about how that class is actually implemented, what goes on underneath, and how network programming is actually done.

In short, absraction is a good thing - when you also take the time to learn and understand the underlying implementations. However, you can definitely see how this can act negatively on a developer's understanding of program code.