Plunging into .NET Development

Weblog Pieter Gheysens
Microsoft .NET Development - C# - Enterprise Library - Visual Studio 2005 Team System - Compuware DevPartner - ...
 


Sunday, December 14

Passing parameters in public signatures

Passing List<T> in a public signature is generally not a good idea. Consider this simple example :



MyMethod accepts List<string> as a parameter and the method just iterates through the list to write all strings in the collection to the output window. The code will compile and it will work, but it's not good design. If code analysis was enabled for the project this method belongs, a warning/error would definitely pop up ...

CA1002 (Microsoft Design) : Change 'List<string>' in 'MyService.MyMethod(List<string>)' to use Collection<T>, ReadOnlyCollection<T> or KeyedCollection<K,V>

The rule explains that List<T> was not designed for inheritance (no virtual members) and another generic collection should be exposed instead. In fact List<T> also contains too many irrelevant members : searching, sorting and manipulating the list. The best choice in the example above would be to expose a ReadOnlyCollection<T>.

Let's go a little bit further here. One of the first principles of object oriented design is to program against interfaces and not to an implementation. And for passing a list of strings as input parameters, we should always try to start with IEnumerable<string> and increase the amount of responsibilities (ICollection<string> --> IList<string>) only when required. In the example above IEnumerable<string> should be used because we only need the list for simple iteration. If it would for example also be necessary to get the number of elements in the list, then ICollection<string> should be used ... and so on ...

In conclusion it must be said that it's very important to review the public signatures of your classes. You don't want to expose more members than you need to expose. For returning objects from a method, you should only return the simplest working object (ReadOnlyCollection<T> --> Collection<T> --> List<T>) and for passing input parameters always start with IEnumerable<T> and go up the stack only when it's really needed. To help you with this review you can rely on some rules of Static Code Analysis in Visual Studio. Basically there aren't any good reasons to turn off Static Code Analysis completely for your development projects!

Labels:

Saturday, December 6

Geek Dinner after VISUG Event with Hadi Hariri

I'm trying to setup a Geek Dinner for after the VISUG Event with Hadi Hariri on December 16, 2008. All who's interested in joining for the Geek Dinner with Hadi Hariri may leave a comment on this post. You are not obliged to follow the VISUG session if you only want to come for food and informal discussions, but the session of Hadi Hariri is highly recommended! Post a comment before December 14 to be sure of your spot in the restaurant!

Place to be for the Geek Dinner [20h30] : Mexican Restaurant Pablo's Brussels.

There's a public parking in the neighborhood : Parking 2 Portes Brussels

Labels:

Tuesday, December 2

Dedicated VSTS blog

A while ago I was thinking about setting up a new blog, 100% dedicated to Visual Studio Team System. After test running the blog for some time with some initial content, my VSTS blog is finally live at http://www.intovsts.net. Subscribe if you are also into Visual Studio Team System! The slides from my VISUG presentation (What's new in VS2010?) are also available for download!

Labels: