In my last post, I discussed one of my favorite new features in C# – Optional and Named Arguments. Although they are very easy to use, and quite intuitive, I have seen few discussions which explain how they actually work. Understanding how they are implemented helps in understanding the repercussions of using these features in development.
After focusing on some of the .NET framework enhancements, I thought I’d turn my attention to two of my most anticipated new features coming with C# 4 – Optional and Named Arguments. These two features provide benefits I haven’t seen mentioned in most of the announcements…
Handling text has always been the bane of my programming career. Starting off as a C developer forever tainted me when it comes to processing text; it’s difficult for me to not cringe every time I think of having to do text parsing. String manipulation in .NET was a pleasant surprise for me – when I started with C# I found I suddenly lost my urge to wince every time I had to deal with text input, and no longer was I itching to jump over to a loosely typed language just for handling string manipulation. The System.String class in .NET provided most of the ease of use I missed in C (and even C++).
However, even in .NET, there have been little annoyances when dealing with the String class. Version 4 of the .NET framework, again, adds some functionality to simplify day to day programming tasks. It’s really nice to see that the base class library team is giving some attention to the core, very common classes. Here is a summary of the changes to the String class, and why they help.
The more I investigate the changes in Version 4 of the .NET framework, the more I find little tweaks that just reduce the pain of day to day programming. For example, the System.Enum class is getting some extra methods that finally make day to day programming a bit simpler.
A very common pattern in programming is the Lazy Initialization Pattern. Version 4 of the .NET Framework makes using this pattern very, very easy.
Unlike standard .NET properties, implementing a DependencyProperty requires a bit more code, and has the potential to cause nasty errors to creep up at runtime, without any compile time warnings. Here’s one easy, common mistake, as well as an explanation of why it occurs…
It is very difficult to handle situations in a master-detail view, where the master side displays a value derived from aggregating the detail collection. The Model-View-ViewModel pattern makes this even more challenging, since most means of handling this require changing your model, or using extensive code behind.
One common issue people face in the Model-View-ViewModel pattern is how to cleanly deal with the lifetime of the View from within the ViewModel. Keeping all of the logic in the ViewModel for preventing the View from closing can be a daunting task, especially at first.