This month’s MSDN Magazine has a pretty interesting article on Object Role Stereotypes. The article reminded me of the GRASP design patterns that I learned back in college.
The article also mentions the value of using CRC cards as a design exercise. This is another practices that I’ve heard about, but have not had a chance to experience first hand.
All in all, a decent read if you’re interested in some conceptual knowledge around object-oriented design.
Craig Shoemaker over at Polymorphic Podcast has created a series of short webcasts on the Model-View-Presenter design pattern. I spent some time tonight looking through them and was pretty impressed with the topic overview.
While I have heard others discuss the MVP design pattern and its benefits, I have neither implemented it myself nor seen it implemented in any concrete fashion. So I went into the webcasts with some skepticism to determine whether the pattern was as useful as I had been told.
After watching the first webcast, my initial reaction was, “Why would people want to write all that extra code? Just to say they had another layer of abstaction? I could never sell anyone on this idea!” But I decided to watch the second webcast, which took the first project (a web project) and applied the Presentation (Presenter) and Business (Model) layers to a new WinForms application. Without a single change to either of the two aforementioned layers, Craig was able to re-create the UI functionality with minimal coding changes.
Now, granted, the examples are a bit vanilla and more real-world projects will require additional forethought. And, as with everything else, this design pattern is no silver bullet. However, I can say with certainty that I am a bit less skeptical of the MVP design pattern after watching these webcasts.
Ted Neward wrote a good article on MSDN about distinguishing layers and tiers in system design. This is to be his first article in a series of articles about Pragmatic Architecture.
The article has some pretty good points about the over-use of n-tier architecture, which I will admit to using more often than necessary. His article goes on to say that a separation of concerns is not itself a bad idea, but rather, the popular implementation of using separate assemblies spread over multiple machines (for example, a client’s machine, an application server, a database, etc.)
A previous project I worked on implemented a rich-client system containing a user interface executable, a few too many business layer DLLs, and a separate data access layer DLL — all installed on the client’s machine. At the time, I was graying the distinctions between layers and tiers. While my design had loose coupling, I was taking a significant performance hit by using several separate DLLs to separate the concerns instead of relying solely on the .NET namespaces.
The point of Ted’s article is to show that, in a design like the one described above, it is better to use logical layering (layers) rather than physical layering (tiers); however, in other designs, the use of n-tier architectures may be preferable. This is a good concept to remember, as it can save time and effort later down the road during performance tuning.
Looking back on my first real-world project, I remember applying a lot of different agile and iterative practices, trying to get a feel for what worked and what didn’t work. Among those practices was the use of modeling UML diagrams (domain models, class and sequence diagrams) prior to actually writing the code.
What I discovered is that this task in itself can be applied using a variety of ways, from hand-sketching UML diagrams to whiteboarding to using a professional software tool. And each of these methods are better than others in the right setting.
I love the anonymous methods feature that was added to C# 2.0. I got a taste of this feature in college when I used Java (which refers to them as anonymous inner classes). Regardless, this is yet another feature to help developers write cleaner code.
For example, let’s say your application has a button that, upon clicking, shows an “About” dialog, which displays various information about your application (e.g. version, logo, etc.). Upon closing that dialog, you’d like to display a message box, telling your user that they just saw your “About” dialog box (because users like having to click a lot…).
In C# 1.x, you’d have to write the following code to accomplish this:
private void Button1_Click(object sender, EventArgs e)
{
AboutDialog dlg = new AboutDialog();
dlg.Closed += new EventHandler(OnAboutDlgClosed);
dlg.ShowDialog(this);
}
// separate method for handling the form close event.
private void OnAboutDlgClosed(object sender, EventArgs e)
{
MessageBox.Show("You just saw my About dialog!");
}
However, in C# 2.0, you can do the same thing using anonymous methods:
private void Button1_Click(object sender, EventArgs e)
{
AboutDialog dlg = new AboutDialog();
// .NET 2.0 changed the name of the event to FormClosed
dlg.FormClosed += delegate
{
MessageBox.Show("You just saw my About dialog!");
}
dlg.ShowDialog(this);
}
That’s it. Frickin’ sweet!
Ok, so there are a couple drawbacks that I’ve found while using anonymous methods. First, I’ve found that I cannot use the “Edit and Continue” feature in the Visual Studio 2005 Debugger. That is, I am not allowed to make a change in the method or anonymous method while stepping through the code — instead, I have to make my code change and restart the debugger. A minor nuisance, but still a nuisance.
The other potential issue is that, assuming the code in the anonymous method needs to be executed in response to multiple events, some developers may find themselves copying and pasting the code in several places of their application, thus ignoring the general rule of code re-use.
This second issue can be very subtle. It is a problem of design, and it is up to the developer to be on the lookout for it. In cases like this, the C# 1.x example would be a good solution that promotes code re-use.
I attended an Agile Iowa meeting for the first time June 15th (when I first started writing up this post…), and walked away with a head full of ideas and aspirations. But I had come with a purpose first and foremost. I was there to get some insight from other professionals on how to improve quality on my current project.
Toward the end, we talked extensively about various uses of TDD, all of which I had heard of, but only some of which I had used in development. But the idea of using mock objects really made an impact on me.
Which brings me to NMock, an interesting tool for incorporating mock objects into your unit and acceptance testing. So far, I’ve only had the chance to test out the introductory tutorial, and my impressions of it are mixed. A google search returns sites with different types of examples, some of which referring to objects I couldn’t find in the assembly for .NET 2.0. But the documentation on the download site looks pretty useful, once I have more time to read through it.
In the coming weeks, I hope to find more time to play around with it, and have more to say on the subject. Stay tuned…