C# Interfaces and Default Parameters

How does a default parameter work?

One of the things that I love about C# is how so many of it's features are just very conveniently designed compiler tricks. This means that, just like any other magic trick, once you know how the trick is performed you immediately realize that there is nothing magical about it all!

So, let's talk about default parameters. They are actually just constant values that get compiled into your code when you go to use a method that has them. Let's look at an example...

public class DefaultParamTests1

{

    [Fact]

    public void WhatYouWrite()

    {

        var actual = Double();

        Assert.Equal(2, actual);

    }

    private static int Double(int i = 1)

    {

        return i * 2;

    }

}

public class DefaultParamTests2

{

    [Fact]

    public void WhatItCompilesTo()

    {

        var actual = Double(1);

        Assert.Equal(2, actual);

    }

    private static int Double(int i)

    {

        return i * 2;

    }

}

What happens when interfaces and methods don't match?

So, now that you know how the trick is performed, what happens if you use a different default value for a parameter defined by an interface and a class?

The answer is simple: if your object is cast as the class, then it will use the class value. If your object is cast as the interface, it will use the interface value instead. Let's take a look at another example...

How to Optimize Json.NET Serialization Performance

Newtonsoft is a pretty fast JSON serializer, but you can make it even faster!

By default, JsonConvert uses reflection to recursively search through the structure of an object during the serialization process. By implementing a custom JsonConverter that already knows the exact structure of the object, you can significantly increase serialization performance.

How much faster? That depends! The more complicated the data structure, the larger the performance gain. Below is a simple example...

Action	Method	Milliseconds	Performance Increase
Serialize	Standard	1134	115.59%
	Custom	526
Deserialize	Standard	1488	62.98%
	Custom	913

Why do you enjoy programming?

Recently a friend of mine asked me to participate in a study that he is conducting. He asked me to answer the following questions, and I thought that they were interesting enough to share...

1. You’ve mentioned before how you enjoy programming and choose to do it in your free time, and I was wondering what aspects of the work do you enjoy the most and what reasons you think you have for enjoying it?

I am going to try to answer those questions in reverse order.

What reasons do I have for enjoying programming? I think that programming is problem solving its purest form; it is the application of raw logic to a very specific and well defined problem. As a person who has always enjoyed math and science, my brain just seems to naturally gravitate towards computer science. To me programming is like solving a puzzle, and I get the same high from making my code compile as I do from beating a video game.

What aspects of the work do I enjoy the most? This question is much easier to answer! Anyone can solve any problem using only their mind. You can define languages and protocols to meet your needs. You can communicate between any number or parties at the speed of light. You can literally engineer entire worlds. It’s fun, it's challenging, and it is always rewarding when you build something that impacts others in a positive way.

2. In addition to that, how do you view the projects you are working on while you are working on them, and how do you view them once they are done?

These are opinions that have evolved overtime, often through trial by fire.

How do you view projects while you are working on them? During a project you need to keep your eyes on the prize, the best thing any engineer can do is to try and deliver the minimal viable product as soon as possible. During this time engineers need to engage in a very difficult balancing act of trying to make the best long term decisions, while still tempering their ideas and ambitions with more reasonable compromises to achieve short term goals and deliverables. After you have something that works, then designs can be iterated upon, implementations refactored, and schedules revised. In short, I think every project that does not ship is a failure, regardless of how perfectly it was designed or optimally it was implemented.

How do you view projects once they are done? First and foremost, I feel that the quote "art is never done" applies to software. There are almost infinite ways to solve a problem, each with their own set of pros and cons, so projects can always be improved. That being said, after a project is complete you need to be honest about it. You can, and should, be proud of what worked. You should also be open to talking about what didn't. No matter how good a project was, you can always do it better next time!

Those are my answers...what are yours?

Thanks,
Tom