The Use and Misuse of Design Patterns

Design Patterns have always been of great interest to me.  (If you doubt this, you can see that I have a section of my Bookshelf dedicated to the topic.)  One of the greatest advantages to learning the basic patterns is to share a common language with your fellow developers, so when you talk about a Factory Method or Decorator, I know what you are talking about.  But at the same time, I see a tendency for some developers to use patterns for the sake of using patterns without fully considering the benefits and costs.

Rocky Lhotka has a great article about what developers should think about when considering patterns in their projects.  You can find it here: On the use and misuse of patterns.  Go take a look at it now.  Don't worry; I'll wait.

Okay, are you done reading it?  Go back and read it again.  It's that important.

Welcome back.  I've experienced a few of the issues that Rocky mentions.  First, I have seen the "Pattern of the Year" phenomenon.  It seems like some of the developers in my group get stuck on the current popular pattern.  I won't mention any specifics, because as Rocky notes, there's nothing wrong with the pattern itself.  The problem is that the popularity leads to a sort of cult of people who feel like they need to implement the pattern whether it fits in with the application or not.

Second, I have seen developers that get so enamored with a particular pattern than they try to use it at every turn.  Rocky's analogy is great on this:

"It is kind of like a carpenter who spends a lot of money buying some really nice new power tool.  And then trying to use that power tool for every part of the construction process -- even if that means being less efficient or increasing the complexity of the job -- just to use the tool."

Design patterns are just tools.  Part of being a good developer is understanding the strengths and weaknesses of each of those tools.  As developers, we need to focus on the problem space that we are working on and pick the appropriate tools for that job.  (As a side note, this extends beyond design patterns to the technologies that we use -- whether WPF, Silverlight, or WebForms -- and even further out to the platform -- whether .NET, LAMP, Java, or whatever.)

I do have an issue that I'm not quite sure how to approach: I have worked with a developer and talked about the benefits and costs of a specific design pattern.  We both agreed on the strengths (what the pattern was trying to solve for) and the weaknesses (the added complexity).  And we also agreed that we would not get the benefits of the pattern in the current application we were discussing.  The frustration is that the other developer still wanted to use the pattern because "we might need it later."  Experience shows that this would be unlikely.

So, if you have any suggestions on how to approach this type of situation, let me know.  I'll be sure to share the good responses here.  Send them to feeback@jeremybytes.com.

If you are new to the design patterns world, I would encourage you to learn the benefits and costs of each pattern.  And above all, consider their usage carefully.  Patterns are a wonderful tool.  But don't get so wrapped up in the tool that you forget the problem you are trying to solve.

Before you go, go back and read Rocky's article one more time: On the use and misuse of patterns.

Happy Coding!

Intro to XAML Questions

While presenting the Intro to XAML session at recent code camp and user groups, a few questions came up.  Here's some more information on those topics that I didn't have at my fingertips at the time.

FrameworkElement in the Ticker Class
Question: Why does the Ticker class in the demo code descend from FrameworkElement?

Answer: As I noted during the session, the Ticker class exposes the DisplayInterval property as a DependencyProperty.  A DependencyProperty is a WPF/Silverlight construct that adds functionality above a normal property.  This is used for features such as animation, styles, and data binding.  We used it for data binding in our sample.

So where does FrameworkElement come in?  A dependency property can only be added to a DependencyObject (or a class that descends from DependencyObject).  FrameworkElement happens to be a descendent of DependencyObject.  And since it is also the base class for most of the elements in WPF and Silverlight, it also makes a convenient base class for our custom Ticker class.

If you want more information on dependency properties, you can check out MSDN here: http://msdn.microsoft.com/en-us/library/ms752914.aspx.

User Controls in WPF/Silverlight
Question: Can you create user controls in XAML that would allow you to use the same control on multiple screens?

Answer: The answer to this is definitely yes.  "UserControl" is one of the common root-level elements in XAML UIs (in addition to "Window" and "Page").  UserControl is now the default root element for Silverlight, but you can create your own user controls and embed them in other screens (whether they are Window, Page, or another UserControl).

I do have an example in Silverlight that creates a UserControl in a separate XAML file and then uses it on a screen.  The sample is available here: http://jeremybytes.blogspot.com/2009/06/more-silverlight-part-2-user-controls.html.  There is a small caveat to this, though: it is Silverlight 2.  Fortunately, the part that shows how to create a user control and use it in your application is still relevant in Silverlight 4 (and WPF as well).  The section on events is also still accurate; however, there is a much easier way to build this particular sample in Silverlight 3 or 4 by using object binding instead of events.

Attached Properties
Question: The XAML syntax for attached properties is intriguing.  How do they work?

Answer: An attached property is a construct in WPF and Silverlight, and how the framework handles it internally is more information that you probably want.  So, let's just take a look at a short sample.

In the demo code, we use an attached property by setting Grid.Row="0" inside of our TextBlock.  Here's a reminder of the code:

To get an idea of how this property gets set, let's take a look at how we would set this property in code rather than in the XAML.  We'll assume that our text block is named "myTextblock".  There are actually 2 ways we can set the property: either from the point of view of the Grid or from the point of view of the TextBlock.

From the Grid's viewpoint, the property is set like this:
Grid.SetRow(myTextBlock, 0);

From the TextBlock's viewpoint, the property is set like this:
myTextBlock.SetValue(Grid.RowProperty, 0);

Although this doesn't explain the internals, it does give you an idea of how it works.  With the first method, we are passing the element (myTextBlock) and value (0) to the Grid's SetRow method.  SetRow is a static method of the Grid class that allows for the "Row" attached property to be set.  With the second method, we use the SetValue method which allows us to set an attached property from the element (myTextBlock) itself.

Of course, there is more info on attached properties available on MSDN: http://msdn.microsoft.com/en-us/library/ms749011.aspx.

ZoomIt
Question: Where can I get the zooming tool used during the presentation?

Answer: ZoomIt is a tool that was created by a Microsoft employee (Mark Russinovich) for his own use in presentations.  It has several features including zooming the screen (like a magnifier), adding annotations (either drawing or text), and showing a break timer.  I ran across it while watching a webcast where the speaker was using the tool.

You can download ZoomIt for free here: http://technet.microsoft.com/en-us/sysinternals/bb897434.aspx

Additional XAML Samples
Not exactly a questions, but there are additional XAML samples available on my website.  The Target Practice application is a sample I built to see if I could build an application using XAML only.  I did this in both WPF and Silverlight 3.  Here are the links to the walkthroughs:

WFP: http://jeremybytes.blogspot.com/2009/03/wpf-xaml-sample.html
Silverlight: http://jeremybytes.blogspot.com/2009/09/target-practice-silverlight-3-xaml.html

As with all of my samples, the code can be downloaded from my website: http://www.jeremybytes.com/Demos.aspx.

That's it for now.  If you have any questions, feel free to send them to feedback@jeremybytes.com.

Happy Coding!

What's Wrong with VB.NET?

VB.NET has the reputation of being a second class language in the .NET world.  A lot of this has to do with the history of VB and its transformation from VB6 into VB.NET.  Conversely, there is a perception that C# is the "real" .NET language, and I think that comes from its (much shorter) history.

At a recent user group meeting, someone joked that VB had been deprecated, and I will admit that I picked up and echoed that joke.  I hope that folks could tell that I wasn't serious.  When I'm talking to people, I try to point out VB resources where I can -- for example, my favorite Silverlight and WPF books have both VB and C# versions available -- but I'm personally more familiar with the C# resources since those are the ones I use on a day-to-day basis.

Today, VB.NET and C# are pretty much the same language with different syntax (at least that's how I like to think of them).  And the great thing about .NET is that whatever language you work with still gets compiled down to the same IL, and you can use assemblies in your project that are created in any .NET language (in fact, you probably don't even know what language a third-party assembly was created with).

Real programmers don't get stuck on syntax.  Programmers in general are opinionated and have their tools and languages of choice.  Good programmers generally have several different languages under their belts (and not just .NET languages, but things like Ruby, Python, Perl, Delphi, and Java).  I have my language of choice (which is currently C#, but has been different in the past), and before I start a task I try to make sure there isn't another tool that would do the job better.

Why the Bum Rap?
So, why does VB.NET have this reputation?  My theory is based on looking at the history of .NET.  When .NET launched, it was a brand new platform.  Along with that launch, Microsoft was promoting a brand new language (C#) that was created just for that platform.  In order for .NET to succeed, Microsoft had to get as many people on board as possible.  C# was the vehicle they used for most of their demonstrations.  This was because C# had all of the capabilities of .NET (at the time).  Because of this, C# became equated in many people's minds as the "primary" .NET language.

But Microsoft also knew that there were millions of people invested in VB.  They could not succeed if they forced all of the programmers who were comfortable with the VB syntax to switch over to a C-based syntax.  And more importantly, they couldn't force those developers to abandon all of their existing code.  So, we got VB.NET.  And that's sort of where the problems started.

First of all, VB.NET was very different from VB6.  There were a number of "features" that were put in to VB.NET to make migration of existing VB6 code easier.  But if programmers wanted to really start using the .NET platform to its full potential, they needed to re-write quite a bit of code to fit in with the new paradigm.

VB.NET and C# had quite a few differences in the early versions.  There were some constructs in C# that did not have an equivalent in VB.NET (and vice-versa).  In addition, Visual Studio tended to favor C# when it came to features such as refactoring and IntelliSense.  C# would get these feature updates first, and then they were made available to VB.NET later (as much later as the next release).

Forget Everything You Thought You Knew
But it's time to forget everything you thought you knew about the differences between VB.NET and C#.  With the latest release of .NET 4, the languages are almost equivalent; there are a few minor differences, but for all intents and purposes, you can accomplish the same tasks in similar ways.

Steve K. pointed me to this blog article from Steve Wiltamuth regarding the futures of both languages: VB and C# Coevolution.  In short, Microsoft is committed to moving both languages forward in the same direction and keep parity in the features and tools (such as the refactoring and IntelliSense features in Visual Studio).

Wrap Up
The good news of the similarities between the languages is that both C# and VB.NET programmers can take advantage of the vast amount of sample code that's available on the net.

Having both C# and VB.NET is great for the .NET development community.  C# (and the C-based syntax) provided a comfortable migration for folks using Java and C++; VB.NET provide a comfortable migration path for folks using VB.  Together, this has created a mix of developers that can share code and still hang on to their preferred syntax.  That sounds like the best of both worlds to me.

Happy Coding!