Two documentations that I use the most when programming in .NET are the ReSharper 4.5 Default Keymaps and the C# Language Specification (ECMA-334).  In order to quickly access those two documents (and future documents I might need), I simply created an entry in the External Tools section of Visual Studio.  In order to do this, you can follow these simple steps:

1. Go to Tools -> External Tools…
2. In the External Tools window, click on the Add button to create a new entry
3. Fill in the required information, such as Title, Command, Arguments, etc.  In my case, the Command is simply the path to the executable of my favorite PDF reader (Foxit Reader) and the Arguments is simply the path to the PDF file.  You can also define a keyboard shortcut for them by prefixing the “&” symbol to one of the letters that aren’t already defined as shortcuts. 
4. When you’re done, click on OK. 

Take a look at the following screenshot:

With this little setup, I don’t need to go to either the ReSharper or ECMA’s website, not even launch Windows Explorer to look for those files.  I have access to those files directly from Visual Studio.  No more context switching.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

1. David Heinemeier Hansson on The Secret To Making Money Online (less than 30 minutes)

In this talk given in 2008, David Heinemeier, the creator of the Ruby on Rails framework and partner at 37Signals, gives a very creative and down-to-earth talk on how to create a profitable startup company.

2. Guy Kawasaki on The Art of Innovation (less than 60 minutes)

This is the first time I heard Guy Kawasaki speak.  This guy is a one of my “online heroes”.  He’s smart, he’s funny, and he speaks from experience.  In this talk, Guy talks about innovation about products, services and marketing.  He shares his experience from his work at Apple to now as a venture capitalist.  You’ll also learn about the 10-20-30 rule that can increase your chances in not only getting fund for your business, but most importantly, getting your point across.

3. Joel Spolsky on What Makes a Great Software (less than 60 minutes)

This is a talk that Joel Spolsky, founder of Fogcreek Software, gave as a keynote at RailsConf 2008, where he shares his valuable insight in what really makes a great software, so much so that we can actually qualify the software as great.  His talk is fantastic: it’s entertaining, it’s focused and it’s without a doubt an eye-opener for software developers to watch out some common pitfalls that can make your software not being adopted at all by potential users.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The Architectural Journal is an independent platform for free thinkers and practitioners of IT architecture.  New editions are issued quarterly with articles designed to offer perspective, share knowledge, and help you learn the discipline and pursue the art of IT architecture.  The Architectural Journal reaches over 67,00 subscribers worldwide.

I think one reason that it isn’t getting much attention is because its “feedless”, meaning you can’t directly subscribe to a feed, through your browser, that will notify you whenever a new issue has been published.  So in order to get notified when a new issue has been published, you need to subscribe through a fairly simple, but tedious, subscription workflow.  Once subscribed, you’ll get the quarterly journal as a PDF as soon as it’s released.  In short, here are the steps you should follow in order to subscribe to The Architectural Journal:

Go to the e-newsletters page in the Profile Center.  You may be required to sign up for a Windows Live ID account if you don’t have one already.  You may use your current email account or create a new one if you don’t have one.  From there, you follow these three steps:

1. Find The Architectural Journal in the list of available communications on the left and select it.
2. Press the Subscribe button.  You should now see your choices in the list on the right.
3. Select your delivery format: HTML (suggested) or plain text.

(Note: it would’ve been much easier had someone put an RSS feed link instead.)

So that’s it! Now, you should be getting four issues per year.  All great content about software architecture topics.  All free.  Past topics include:

• Distributed Computing
• The Role of an Architect
• Mobile Architecture
• Software + Services
• Web Architecture
• And more.

You can also skip the whole subscription process and directly download the current and previous issues in English, French, Spanish, etc., as a compressed (ZIP) file.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

1. Find dependent or referenced code

Using this new feature, you can find dependent or referenced code at either a project or file level.  Before going forward with this feature, it is important to understand what is meant by “dependent code” and “referenced code”.  Both of these terms have to do with dependencies/coupling.  When you ask ReSharper to tell you the dependent code at the project level, you are actually asking it to tell you which other projects (or assemblies) are dependent on that specific project.  On the other hand, when you ask ReSharper to tell you the referenced code at the project level, you are asking it to tell you which other projects (or assemblies) that specific project depends on.  For example, suppose the following UML class diagram:

In this scenario, I have four different assemblies: one client console executable (Client), and three class libraries (Provider, Utilities and SecurityManager).  Our Client executable references the three other assemblies because it’ll make use of their services.  Those references were created when I asked Visual Studio to add me the references for those three projects at the project level.  Now, if I were to ask ReSharper to tell me the dependent code at the project level (which means that you right-click on the Client project in the Solution Explorer, and then click on the Find Dependent Code contextual menu item), a message box will appear telling me that “Code dependent on project ‘Client.csproj’ was not found”: 

This is normal, because according to our class diagram above, Client has an afferent coupling of zero (Ca = 0). 

Afferent coupling(s) is the number of class(es) outside this component (i.e., Client) that depend on classes within this component (i.e., Client). 

On the other hand, if we were to ask ReSharper to tell us the referenced code at the project level (for Client), by this time clicking on the Find Referenced Code contextual menu item, you will get the following results:

In this case, ReSharper is telling us the types which are being used in that specific project (Client), even .NET types and assemblies like mscorlib.dll.  Since the Client class has a positive non-zero efferent coupling (Ce > 0), we actually get a result.

Efferent coupling(s) is the number of classes inside this component (i.e., Client) that depend on classes outside this component (i.e., Client).

These results could look daunting at first sight, but that’s because the results window is showing too much information.  All you have to do to get a more simplistic and lighter view of the results is simply to click on the Filter Usages button (that’s the one surrounded in red in the screenshot below) and unselect the Show Attribute Usage from the proposed choices, as you don’t really care that you’re depending on the AssemblyAttribute class for example.  Furthermore, you should also click on the Merge Occurences on the Same Line button (that’s the one surrounded in green in the screenshot below), so that you eliminate some of the redundancy usages on the same line.  Finally, choose an appropriate view to group your results (in this case, I have chosen to group the results by Namespaces and Types.  That’s the one surrounded in blue in the screenshot below).  This will give you the following (much more compact) result view:

NOTE: If you only reference external projects or assemblies in a project without actually using the public types or members in those external dependencies, ReSharper will not tell you that you are actually referencing those dependencies.  This is pretty slick, as you can visually know whether or not a reference is unnecessary, and thus proceed with its removal.

Ah, much better! And you know what?  That’s pretty much right, because the Client class is actually using those classes (Provider, SecurityManager and Utilities), as shown in the screenshot below:

At the file level, you only get to ask ReSharer to tell you the referenced code, through the Find Referenced Code contextual menu item.  In this case, the results will include any type being used in that file.  Suppose for example that in the SecurityManager class, you’re using an instance of a Logging class to log some errors in a few critical methods.  In that case, the results will include the Logging class, as it is a type being referenced in that file.  So far, so smart.

2. Go to implementation (Ctrl+Shift+Alt+B)

This one is pretty simple and very much useful.  Suppose you have the following class hierarchy:

In the previous versions of ReSharper, you couldn’t ask the tool to directly tell you which concrete classes derived from an abstract type.  Instead, you had to select the abstract type and ask it to tell you the derived types (or inheritors) through the Ctrl+Alt+B shortcut, which would give you a list of all the types deriving from that abstract type…even if those derived types were abstract themselves.  This was pretty frustrating when you had a hierarchy with a lot of abstract relationships amongst types, as it was the case in one WCF-driven project I was involved in, because you would lose a couple of seconds filtering out the concrete types from the abstract ones in the results list.  Well, that’s an old story because now you can get the list of all the concrete types (or implementation types) directly from a new shortcut: Ctrl+Shift+Alt+B, or through the “Go to implementation” command in the “Go to” navigation menu.  For example, if you asked ReSharper to tell you the concrete classes for IProvider, it’ll tell you that MembershipProvider and SecurityProvider are the only ones.  It will ignore ProviderBase, as it is abstract.  Well done!

3. Naming styles

With ReSharper 4.5, we get more flexibility in the naming style department.  You can apply either a common naming style for both C# and VB code, or set one differently for each of them.  It’s up to you.  The UI interface to manage the naming styles is pretty simple.  Here, for example, is the Naming Style window pertaining to both C# and VB:

So you get a list of predefined styles out-of-the-box which might suit most of your basic needs.  The flexibility offered by these features comes in handy when you want to create new styles, modify some existing ones, etc.  Suppose you want to add a new naming style for private fields only, and make them prefixed by an underscore.  You would simply click on the “Add” button under the User defined naming rules panel, which will show the following window:

All I have to do is select the affected entities, which in this case would be “Field” and “Readonly field”.  Then I would specify the access modifiers, which sould be Private and Protected. Following that, I will specify the underscore as the name prefix and tick the lowerCamelCase naming style, as to be follow the .NET design guidelines.  Finally, I would set the rule description to something explicit, such as “Private fields”.  That’s it!  Now I can save and share the code style file with my team.

4. Collapse all project nodes (in Solution Explorer)

Suppose you have the following project structure in Solution Explorer:

This would be a very typical folder structure in an ASP.NET MVC project, for example.  Every time you collapse the node associated with the SecurityManager project, and you expand it later, you will see the same result as above.  This can be very frustrating when you have dozens of projects with their child nodes expanded in a similar way in Solution Explorer, and God forbid you have also expanded the References node, because it tends to visually pollute the Solution Explorer.  ReSharper 4.5 introduced a new feature that allows you to definitively collapse a node, be it a folder or the project node itself, so that the next time you expand the root node, the previously collapsed node stays closed!  This might sound like nothing, but have you ever calculated how many seconds you probably were wasting trying to navigate the Solution Explorer when you have a multitude of projects with folders, or solution folders, all open at the same time even though you don’t really need them to be?  That’s not being productive.  That’s not being professional.

So here’s the trick: when you’re done with one node and you need to collapse it for good, simply right-click on it in the Solution Explorer, and choose “Collapse All”.  This would permanently collapse the node until you explicitly expand it again.  For example, if I decide to execute this “Collapse All” command on the Users folder, then each time I expand the SecurityManager node, the Users folder will stay collapsed, until I explicitly expand it.  In my opinion, this should’ve been a standard option for Visual Studio.  Good thinking once again!

5. Inline field (Ctrl+Alt+N)

The fifth of my favorite new features in ReSharper 4.5 is the possibility to inline a field.  As to tweak the original Inline Temp refactoring definition to suit this one:

You have a field that is assigned to once with a simple expression, and the field is getting in the way of other refactorings.  Replace all references to that field with the expression.

I think that little definition sums it up well what Inline Field does.  Simply highlight the field, then hit the Ctrl+Alt+N shortcut, and you’re done.  Here’s a last example.  Suppose you have the following class definition:

As you can see, the someString field is used only once in this class, which is pretty much useless.  In that case, I will place my cursor on it, then hit Ctrl+Alt+N to have it inlined:

And that’s it! Now through all the code, the field’s expression will be inlined.  This was a simple scenario, but I’m sure you can think how useful this refactoring could be in your codebase.

[UPDATE: 2009-04-14] The Inline Field refactoring also works to inline methods and properties, not only fields! This is very sweet.  They should call this command Inline Construct as it doesn’t just inline fields.

But there’s more!!!

Of course, my list of favorite new features in ReSharper 4.5 isn’t the whole story behind this new release.  For a complete list of new feature in ReSharper 4.5, I’ll invite you to review its What’s New in ReSharper 4.5 features page. ReSharper is getting better and better through each release, and I can’t wait to see what the team is going to include in the 5.0 release.  But meanwhile, if you haven’t upgraded to this new version, I urge you to do so.  Plus, the upgrade is free if you’re already a ReSharper 4.x licensee, so you really have no excuse.  And if you’re not currently using ReSharper at all, then I hope that the following post has incited you to ask your tech lead or manager to get a license for it (I would suggest to start with the trial, then demo it to your group).  I’ll also invite you to read my post on The Case for ReSharper in the Enterprise which might give you some pointers on the necessity of this tool in your development toolbox.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

What started as an article a few years ago, titled 10 Things Every Software Architect Should Know, has morphed into a collection of essays written by software professionals and for software professionals. The author of the original article, Richard Monson-Haefel, did well on following the suggestion of Jay Zimmerman to publish a book as a collection of essays sharing pragmatic experience, wisdom, insight and diversity in the field of software architecture.  From the back cover, we can read the following:

In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology.  More than four dozen architects - including Neal Ford, Michael Nygard, and Bill de hÒra - offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from their years of experience.

Published by O’Reilly, “97 Things Every Software Architect Should Know” turns out to be authored by a multitude of different people from around the world and from diverse companies.  The common point of interest amongst all the contributors is their role on the job, that of a software architect.  As the title suggests, there are in fact 97 different essays written by many practicing software professionals that were willing to share their experience, wisdom, proven techniques, mistakes, lessons learned, etc., about their profession and role of that of a software architect.

But what exactly is a software architect?  Though there isn’t a specific definition for that title, there are many accepted ones.  According to Wikipedia (source),

Despite the lack of an accepted overall definition, the role of software architect generally has certain common traits:

Strategic thinking
Architects address the technological aspects of business needs by considering what a given technology can contribute to the overall functions of the system, as distinct from how that technology will perform its own functions.  This encourages opportunities for re-use of the technology and ultimately contributes to the organization’s efficiency.

System interactions
Architects deal with the interactions of systems, whether between components written in different languages at different time and at different locations, or between components of the same software system that use the same coding language.

Design
The architect makes high-level design choices much more often that low-level choices.  In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms, so as to advance business goals rather than to place arbitrary restrictions on the choices of developers.

Communication
Architects also have to communicate effectively, not only to understand the business needs, but also to advance their own architectural vision.

As there are many different traits pertaining to software architecture, there also many different roles a software architect can play, be it: Enterprise Architect, Application Architect, Infrastructure Architect, Security Architect, etc.  As the author acknowledges,

“97 Things Every Software Architected Should Know” provides advice from software architects around the world on everything from how to avoid common pitfalls to how to build talented teams.  It’s a smorgasbord of advice from established software architects for other software architects or those who aspire to become software architects.

Throughout the book, you will find many essays dealing with at least one of these traits and some specific to a role.  The essays aren’t categorized in any way, so each one you read can deal with something different than a previous one, which might be a good idea…or not.  I would’ve preferred if the essays were categorized by traits (or other subject) so that I can focus my reading on a group of them when I want or need to.  For example, if I want to read some essays pertaining to effective team building, I could focus on reading a subset of those essays.  As it stands, I have no much choice but to read each of them sequentially, which can become quite tedious as some essays can be lightly equivalent to another in terms of idea and interest.  Nevertheless, since the content of the essays are rich, insightful and resourceful, I don’t mind too much about the overall layout.  On a last note about the structure of the book, I was very pleased to see that each essay was presented on a two-page presentation (left page and right page).  In other words, if you turn a page, you get a new essay.  At the end of each essay, you also get a brief bio of the author who wrote it so that you can either stalk him…or Google him.  Finally, there aren’t only male authors who contributed in this project.  As a matter of fact, Allison Randal and Rebecca Parsons (CTO of ThoughtWorks) also contributed their own insights.

Many of the co-authors that participated in this project were unknown to me, so reading this book actually allow me to plug into the world of some them through their personal websites or blogs.  Amongst the list of people who contributed to the book are Erik Doernenburg, Udi Dahan, Niclas Nilsson, Neal Ford, Keith Braithwaite, Gregor Hohpe, and many, many more.  Funny thing is that two articles that I very much enjoyed  much reading were written by a guy I’ve never heard of before: Timothy High, a software architect working for Sakonnet Technologies.  In fact, he’s the author of two of my favorite essays in the book: the first one being Empower Developers, in which he urges managers and architects to essentially “protect developers from nonessential parts of their job.  Too much paperwork and too many office chores add overhead and reduce their effectiveness.” and making sure developers have the tools, the skills and the trust necessary to get the job done; and the second one being Record Your Rationale where he suggests that architects should write down their rationale behind some of their technical decisions, as it may come in handy in a number of situations, as he writes:

• As a means of communication to developers regarding important architectural principles that should be followed
• To get the team “on the same page,” or even head off a mutiny, when developers question the logic behind the architecture (or even to humbly accept criticism if it turns out a decision doesn’t hold up under scrutiny)
• To show managers and stakeholders exactly why the software is being built the way it is (such as why an expensive piece of hardware or software is necessary)
• When handing off the project to a new architect (how many time have you inherited a piece of software and wondered exactly why the designers did it THAT way?)

Another interesting thing about this book is that O’Reilly agreed that all of the content of the essays should be freely available (Creative Commons) for to anyone through the book’s website.  Excellent idea, O’Reilly!

In essence, this book is all about software architecture, but not only for software architecture, but rather anyone involved in the software development lifecycle (testers, developers, QA, analysts) and even up the corporate ladder (CIO or CTO).  The content being technology-agnostic, there’s no doubt that the audience for this book will be heterogeneous, so whether you’re a .NET, Java or Ruby fan, you will surely find the essays valuable.  And just like the Head First series, this book has sprung another series focused on a “97 Things Every [fill in the blank] Should Know” idea.  [Note from my wife, the environmentalist: “There goes more trees!”].  If you’re a developer aspiring to take on more responsibilities and challenges for a software project, I would highly recommend you get a copy of this book.  Furthermore, I would also recommend reading a good complement for this book: “The Role of an Architect” published by The Architectural Journal (Microsoft).

[UPDATE: 2008-04-15] You can also read the other proposals which didn’t make it to the final cut.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Amazon Book Linker v1.0 is a free plugin for Windows Live Writer which provides many innovative functionalities for searching and linking books from Amazon on your blog post.  It allows you to specify your own Amazon Associate Tag to every link (you only have to provide this information once, and the plugin will remember it next time) so that you can make a sales commission out of a direct sale from one of the links.  Furthermore, it empowers the HTML ninja (or ninjette) to also customize the HTML template to better match the link layout to your own design.  In order to assist you with this process, the plugin also lists you a series of predefined macros to use.  You can also choose your preferred Amazon locale (US, CA, CO.UK, JP, FR or DE) too!

For more information, I’ll invite you to check the brand new Projects page on this site.  Meanwhile, here are a few screenshots.

Now that this little project is out the door, I can resume posting new ideas on our beloved craft and technologies.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

“Visual Basic .NET is not Visual Basic 6 with inheritance tacked onto it.  Rather, Visual Basic .NET has been entirely rewritten to be fully object-oriented.” For a programming language to be a true OOP language, the language must meet the following criteria:

• Abstraction: Abstraction manages the complexities of a business problem by allowing you to identify a set of objects involved with that business problem.
• Encapsulation: Encapsulation hides the internal implementation of an abstraction within the particular object.
• Polymorphism: Polymorphism provides for multiple implementations of the same method.  For example, different objects can have a Save method, each of which perform different processing.
• Inheritance: The excitement of Visual Basic .NET lies in inheritance.  Visual Basic 5 introduced the concept of interface inheritance, which allows you to reuse the interface of a class, but not its implementation.  Visual Basic .NET provides for true implementation inheritance whereby you can reuse the implementation of a class. [Source: MSDN]

Chances are that a VB6 veteran, that has been programming with VB since its earliest versions, will tend to write VB.NET code in a more traditional “procedural” way, instead of an “object-oriented” way. This is sad because .NET itself is not only built around, but also provides a rich object-oriented model for programming.  However, that doesn’t rattle my cage too much, because with enough practice and mentorship, they could learn to embrace the OO way of analysis, design and programming, as well as to appreciate its benefits.  What rather tends to rattle my cage is that I said could (in italic in case you haven’t noticed) because there’s not much out there that benefit Visual Basic (VB6 and VB.NET) programmers to really appreciate the OO paradigm to its fullest.

C++ and Java programmers coming to .NET via C# tend to reap more of the benefits from the platform than VB6 developers do when jumping on the .NET wagon with VB.NET, because they are already minded to the OO way of doing things.  I think the main reason that makes this balance shift more on one side than the other is because there is just SO MUCH MORE resources (open-source projects, books, blog posts, articles, training, etc.) that focus on the C-family languages, such as C++, JavaScript and C# (for the sake of this post, I will also include Java in this family).  OO concepts such as inheritance, encapsulation, polymorphism, and constructs such as interfaces or abstract classes, tends to be very hard subjects to grasp for VB6 and VB.NET developers (on a professional level, I can only support this fact through those same comments I get from VB developers taking my VB.NET courses and from fellow developers at user groups).   The VB development community will be in a much better position to take advantage of the OO model, the same way that C++, Java and C# developers did, if for every OO book, article or blog posts, there would be the equivalent counterpart code samples in VB.  Last time I checked on Amazon, there wasn’t many books focused on design patterns for Visual Basic developers.  However, there is a ton available for C++, Java, C# and even Ruby developers.  It’s hard for VB developers to grasp the essence of design patterns if they struggle to understand the concept of inheritance and polymorphism.

You know what?  Let’s dig a little deeper on the programming books case.  Table 1 shows the total number of books found in Amazon for Visual Basic, C#, C++ and Java:

Table 1. Books results for various programming languages at Amazon.com (search made on March 10th, 2009)

 
This is very shocking, because if my memory serves me well, Visual Basic is much older than C# and Java! I’m going to spare you the proportions for each of these books, because I think the numbers speak for themselves.  However, I do want you to notice something important: if we consider C# and Java being almost equivalent (putting the CLR and JVM aside), that means that VB developers have close to 68,000 books less to read from.  There’s a little “gotcha” in this study though: just for the programming related books for all these languages, Java comes first with 12,241 books, C++ comes at second place with 10,465 books, Visual Basic comes at third position with 6,351 books and C# comes last with 3,884 books.  However, most of the VB books are for VB6 and older versions (and maybe VBA or VBScript).  Joking aside, there’s not even a Head First series on Visual Basic!!! There is though a Head First C#, Head First JavaScript, Head First Design Patterns (Java), Head First Object-Oriented Analysis and Design (Java), even a Head First Rails and Head First SQL!  Here’s my point: some of the most influential books on software development and programming such as Design Patterns (by the GoF), Patterns of Enterprise Application Architecture (Fowler), Refactoring to Patterns (Keriesky), Implementation Patterns (Beck), Domain-Driven Design (Evans), even hardcore .NET books like CLR via C# (Richter) and the Effective C# series (Wagner), without forgetting the books from the Robert C. Martin series (Agile Principles, Patterns, and Practices; Clean Code and Working Effectively with Legacy Code) hold a vast, deep and rich knowledge of the craft of software development that VB/VB.NET developers are mostly ignorant of.  No wonder that I also tend to see more jobs offering for C# developers than VB.NET when it comes to .NET positions.  I don’t know about you, but that’s very unfortunate.  However, this paragraph was mostly about books.  What about tools and open-source projects?

When I teach the intermediate and advanced VB.NET courses, I tell the students that they should take a look at Enterprise Library from the Patterns and Practices Group at Microsoft (watch a video of it here) for it can save them time, cost and effort in common development situations.  I even tell them that it is open source, which means they have access to the code.  However, I don’t get much excitement from their part, mostly because the code is written in C#.  Code reading aside, I haven’t even heard of one VB developer simply using Enterprise Library in his projects.  The same goes for projects like nHibernate, the Castle project, NUnit, even mocking tools like Rhino.Mocks and Moq.  That’s very sad, because by not using some of these tools, VB developers tend to stay far behind common practices such as TDD and technologies like ORM tools.  What doesn’t help also, is that most of the screencasts where you see someone showing a piece of code or an utility, such as TDD with NUnit and Rhino.Mocks for example, the language is more often than not…wait for it…C#.  The only screencasts that I see a couple of developers programming in VB is in DNRtv.  Furthermore, I don’t recall ever seeing a VB example from the guys at CodeBetter.  Worse, I don’t even have one example written in VB in any of my posts!

One H U G E advantage that VB6 (or even VB.NET) developers tend to have when learning C# to program with .NET is that they can also be more comfortable in reading C# and Java books and source code (which the latter being as most important as reading books IMHO).  By doing this, for example, a VB developer having trouble understanding the implementation of a design pattern in VB, can easily learn it from another example written in C# or Java (and perhaps C++ if the VB developer understand the notion of pointers).  The last remark I said in parenthesis is important, because of all the .NET constructs, it seems to me that the one that causes much headaches to VB/VB.NET developers are delegates, which are essentially lists of method references.  It’s one of those concepts that I tend to spend more time on explaining to VB developers jumping to VB.NET, than C++ or Java developers learning C#.

Though there isn’t a simple and easy solution for VB developers in this situation, I can only encourage them to take a look at C#.  By doing that, they will also be more comfortable in exploring the world of Java, and perhaps even play around the JVM and see how it compares to .NET.  As Benjamin Franklin once said,

“An investment in knowledge always pays the best interest”, and

“The only thing more expensive than education is ignorance”.

In his article, “What VB Dev Should Know About C#”, Bill Wagner actually encourages VB developers to learn about C# (and C# developers to learn about VB) by saying that,

“Our discussion also covered the need for developers to get out of their comfort zones and learn something new.  Yes, the two languages are similar in features, but there are idiomatic differences between the languages, and some tasks are significantly easier in one language than the other.  In fact, you’ll find yourself much more skilled and much more in demand if you know the best features in both languages, as well as how to build applications that rely on both languages.”

And if what I’m writing about isn’t encouraging you enough to learn a new language, then maybe President Barack Obama can persuade you to learn more than “one language”.

I personally speak three languages (Spanish, French and English) and I’m very grateful that I can speak and write in those languages as it gives me a lot of opportunity to learn and embrace foreign cultures, philosophies, relationships and literature.  On the more technical side, I’m also fluent in C++ (not as much as the other languages though), PHP, Java, C# and Visual Basic.  The same benefits apply here, as I can read code written in those languages and books using examples also written in any of those languages.   I can also more easily conduct code reviews with other developers as I’m in a better position to understand their intent, disregard the programming language that was used.

So next time you’re thinking about starting a new personal project, see to it that you write it in C# (if you’re targeting the .NET framework), or even in Java for a change.  If you struggle, don’t quit.  There are many online language conversion tools out there to translate C# code to VB and vice-versa.  The Pragmatic Programmers once advised developers that they should learn at least one new language every year.  This year, Dear VB developer, make a commitment to learn a new language (I’d recommend C#) as it will make you more valuable and employable, and also more comfortable in learning about new ideas emerging in the world of software development.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Oh yes, you shaped me first inside, then out;
you formed me in my mother’s womb.
I thank you, High God - you’re breathtaking!
Body and soul, I am marvelously made!
I worship in adoration - what a creation!

You know me inside and out,
you know every bone in my body;
You know exactly how I was made, bit by bit,
how I was sculpted from nothing into something.
Like an open book, you watched me grow from conception to birth;
all the stages of my life were spread out before you,
The days of my life all prepared
before I’d even lived one day.

Psalm 139:13-16 (The Message)

Though I am not perfect, I am perfectly made.  I did not ask for either a working set of eyes or a complex and functional brain.  Never did it occur to me that my heart would be responsible for pumping my blood or that my lungs would filter the oxygen from the air that I breathe.  I am not a creator of life, but I do create a virtual kind of life, where instead of blood and oxygen there is a complex symbiosis of binary mathematics and electrical pulses.  As a software developer, I do bring life to objects that are responsible for the inner workings of my system.  I sometimes wonder whether the objects and components that we build for our software would thank and praise us in the same degree that King David praised his Creator.

Lately, there has been a popular trend going on in blogs and podcasts around object-oriented programming, notably with the SOLID principles, a composite of acronyms about key design principles introduced by Robert C. Martin.  One of the principles that I adhere stronger than the others is the Single Responsibility Principle (SRP).  According to Wikipedia’s definition,

The single responsibility principle states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.  [Wikipedia].

In the words of Uncle Bob, aside from a type having a well defined responsibility, it should have one, and only one, reason to change.  Going to back to the human body, we can clearly see that our inner components are highly cohesive and loosely coupled.  For example, when I pick up a broken piece of glass from my kitchen’s floor and suddenly I cut myself on the finger of my right hand, I shouldn’t expect my right eye to go blind.  Nor do I expect the other fingers to stop working!  Of course not!  That’s because I am wonderfully made!  And so are you!  When I cut myself, my body knows how to heal itself and within days I have no scar.  Leaving the “cutting” aside, we can clearly see how the eyes, the nose, the tongue, the teeth, the nails, the hair, the skin, etc., all have a single and specific responsibility, and if one member should stop working, it can be replaced by another compatible member.  For example, we can do heart transplants, lungs transplants, etc.  Given that the human body is so much more complex than any software ever created, how come that when my printer driver stops working, the whole operating system goes down with it?  How come when a component in an application stops working, it affects other components as well?  Take, for example, a tree: it looks very simple on the outside, but inside of it, God has clearly encapsulated the inner workings of the tree.  A tree that’s been around for decades can still grow and participate in photosynthesis.  It’s incredible.  Software systems tend to be replaced every year or two.  Anyhow, I want to keep writing on the topic of single responsibility for an object.

Suppose you have the following simple Car class:

Now, what do you think about the methods (or responsibilities) of this class?  Does it violate the SRP principle?  Here’s a simple test you can do to answer these questions (if you answer ‘NO’ to any of these questions, then you know that your class doesn’t adhere to the SRP principle.  Even better: if the question doesn’t seem to make any sense to you, then it’s a ‘NO’ by default):

• Can a car change gears by itself?
• Can a car change a radio station by itself?
• Can a car drive itself?
• Can a car idle by itself?
• Can a car park itself?
• Can a car start itself?

Unless you’re the lucky owner of the Knight Rider, you probably answered ‘NO’ to a few of these questions.  For every question or observation you have answered ‘NO’, you should more than likely refactor the class and move some of its responsibilities elsewhere.  But where exactly can you move these responsibilities?  Well, before we dive to some of these answers, let’s see if we can directly some of the original questions pertaining to our Car class:

• Can a car change gears by itself? ANSWER: Sure, if it has an automatic transmission.  Otherwise, only the driver can shift gears.
• Can a car change a radio station by itself?  ANSWER: Nope, only the driver (or the passenger) can change the radio station.
• Can a car drive itself? ANSWER: Not unless it’s KITT!  Only a driver can drive a car.
• Can a car idle by itself? ANSWER: Sure it can.
• Can a car park itself? ANSWER: Nope! Only a driver can know how to park a car.
• Can a car start itself? ANSWER: Uh, no.  Once again, only the driver can start the car.

Do you see how by answering such questions or observations you can better get through a cleaner design?  The pattern is pretty simple too: Can a [type] [action in the infinitive] itself? Though I picked a very trivial example, you could do the same test for any of your classes, e.g., an Order class, an Employee class, an Account class, a Repository<T> class, even interfaces!  Continuing with our beloved Car class, we see that it has a couple of responsibilities it cannot fulfill by itself, because either it doesn’t make sense that it should, or plainly that it isn’t logical for the class to offer those services in the first place.  From our answers, we can also see that we need another class to make all well orchestrated: a Driver class.  The driver should know how to fulfill some of these responsibilities.  How would you associate the Driver to a Car?  You can go with the Dependency Injection pattern on this one if you like, or pick another strategy.

So we talked about a few things here: the Bible, Knight Rider and Uncle Bob.  But more importantly in this post, we talked about some easy and simple techniques we can use to determine whether methods or properties (responsibilities) actually belong in the right type.  Unfortunately, following this technique isn’t a silver bullet for every situation!  You must still rely on your experience and wisdom to better answer that question.  If you are part of a team, that’s even better because it is those deep and insightful conversations that actually bring about a much suitable solution.  For example, what if our Car needs some reparations?  Should we create a Repair() method in the Car class or the Driver class?  Well, you can first of all use our little technique to answer this question:

• Should a car be able to repair itself? ANSWER: Not in this world, that’s for sure!
• Should a driver be able to repair a car? ANSWER: Well, it depends!  Maybe the driver can repair the car, and if not, maybe we should introduce a Mechanic class that knows how to repair the car.  This is when we should discuss it in front of a whiteboard.

I hope this little tip will help you to better evaluate your design.  And don’t stress too much about it if your design doesn’t follow the SRP or any of the SOLID principles.  Just be thankful that you’re wonderfully made and that you have Google at your disposal.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The Marker class

For this demonstration, I will be using a custom Marker class that will simply output text in the console.

This is the Marker class in C# (the class is equivalent in the Visual Basic module):

class Marker
{
    public Marker(string text)
    {
        Console.WriteLine(text);
    }
}

The Base class

Let’s kick off the idea with a single C# class (no inheritance whatsoever):

class Base
{
    private static Marker staticField = new Marker("base static field");
    private Marker instanceField = new Marker("base instance field");

    static Base()
    {
        new Marker("base static ctor");
    }

    public Base()
    {
        M();
        new Marker("base instance ctor");
    }

    protected  virtual void M()
    {
        Console.WriteLine( "base M() was called" );
    }
}

Here’s the same class in Visual Basic:

Class Base

    Private Shared staticField As New Marker("base static field")
    Private instanceField As New Marker("base instance field")

    Shared Sub New()
        Dim temp As New Marker("base static ctor")
    End Sub

    Public Sub New()
        M()
        Dim temp As New Marker("base instance ctor")
    End Sub

    Protected Overridable Sub M()
        Console.WriteLine("base M() was called")
    End Sub

End Class

When we instantiate the Base class, we get the following output in C# and Visual Basic.  The main point is that the results are the same whether we instantiate the C# or Visual Basic version of the Base class.

Instantiating a child class of Base in C# and Visual Basic

Here’s now the entire code in C# of the Base class (same as before) and a Derived class inheriting from it:

class Base
{
    private static Marker staticField = new Marker("base static field");
    private Marker instanceField = new Marker("base instance field");

    static Base()
    {
        new Marker("base static ctor");
    }

    public Base()
    {
        M();
        new Marker("base instance ctor");
    }

    protected  virtual void M()
    {
        Console.WriteLine( "base M() was called" );
    }
}

class Derived : Base
{
    private static Marker staticField = new Marker("derived static field");
    private Marker instanceField = new Marker("derived instance field");

    static Derived()
    {
        new Marker("derived static ctor");
    }

    public Derived()
    {
        new Marker("derived instance ctor");
    }

    protected override void M()
    {
        Console.WriteLine( "derived M() was called" );
    }
}

And here are the same classes in Visual Basic:

Class Base

    Private Shared staticField As New Marker("base static field")
    Private instanceField As New Marker("base instance field")

    Shared Sub New()
        Dim temp As New Marker("base static ctor")
    End Sub

    Public Sub New()
        M()
        Dim temp As New Marker("base instance ctor")
    End Sub

    Protected Overridable Sub M()
        Console.WriteLine("base M() was called")
    End Sub

End Class

Class Derived : Inherits Base

    Private Shared staticField As New Marker("derived static field")
    Private instanceField As New Marker("derived instance field")

    Shared Sub New()
        Dim temp As New Marker("derived static ctor")
    End Sub

    Sub New()
        Dim temp As New Marker("derived instance ctor")
    End Sub

    Protected Overrides Sub M()
        Console.WriteLine("derived M() was called")
    End Sub

End Class

Here’s the output generated when instantiating the Derived class in C# and Visual Basic (This is where the fun begins!  Try to notice any difference between the C# and Visual Basic execution before continuing.) :

As you can see, the order of execution in an inheritance relationship is both different in C# and Visual Basic (regardless of whether or not a virtual/abstract method was called from either constructor).  The danger of calling a virtual or abstract method from a constructor (in C# or Visual Basic) is that the overridden method will be invoked prior to the derived class’ constructor.  If that method tries to access or modify the state of the yet-to-be-fully-constructed object, you might end up with a corrupt or invalid instance.  The worse scenario is in Visual Basic.  As you can see from the results, the overridden method gets called not only before the derived class’ constructor (as it was with the C# version), but also gets called before the class’ instance fields get initialized.  Now, that’s even more dangerous if the overridden method tries to access any of its instance fields because chances are that they will default to Nothing (null in C#) for reference types since they haven’t even been initialized yet!

Referencing a Visual Basic assembly from a C# application and instantiating the Visual Basic version of the Derived type

Here’s another potential dangerous scenario: From a C# application, you reference a Visual Basic assembly that holds the exact same code as the Base and Derived classes shown above.  You then decide to instantiate the Visual Basic version of the Derived class:

static void Main(string[] args)
{
    Console.WriteLine( "From C# Program" );
    Console.WriteLine(  );
    new VBModule.Derived();
}

Here’s the output generated from instantiating the Visual Basic version of the Derived class in the C# application:

 As you can see, it is no longer having the same execution cycle as when instantiating the C# version of the Derived class from the C# code itself.

Referencing a C# assembly from a Visual Basic application and instantiating the C# version of the Derived type

This time, we’ll switch the roles and from a Visual Basic application, we’ll reference a C# assembly that holds the exact same code as the Base and Derived classes shown above.  We then decide to instantiate the C# version of the Derived class:

Sub Main()
    Console.WriteLine("From VB Program")
    Console.WriteLine()

    Dim d As New CSharp.Derived
End Sub

Here’s the output generated from instantiating the C# version of the Derived class in the Visual Basic application:

As you can see, it is no longer having the same execution cycle as when instantiating the Visual Basic version of the Derived class from the Visual Basic code itself.

Conclusion

You should never be calling a virtual or abstract method from a constructor in C#, and even more in Visual Basic, because in either case a derived type will invoke an instance method prior to the object being fully constructed!  In other words, the dynamic linking edition kicks in as soon as you instantiate a class.  According to Microsoft,

When a virtual method is called, the actual type that executes the method is not selected until run time.  When a constructor calls a virtual method, it is possible that the constructor for the instance that invokes the method has not executed.  The constructor should be redesigned to eliminate the call to the virtual method.

As you saw, the execution cycle is different for both languages even with the same codebase.  It gets even more interesting when referencing either assembly (C# or Visual Basic) in either language, because you just wouldn’t know what you’ll get at the other end.  Having a tool like ReSharper can be of a greater benefit in this circumstance as it’ll catch this kind of code and notify you about it.  By default, this situation will be treated as a warning, but I’ll suggest you to treat it as an error as to make it stand out better (ReSharper->Options…->Inspection Severity):

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

So these are the steps you should follow if your TweetDeck doesn’t show up in the primary (and only) monitor because it’s thinking it should display on an external monitor:

1. If you’re using Windows Vista, browse to the following directory: C:\Users\<username>\AppData\Roaming.  If you’re using Windows XP, browse to the following directory instead: C:\Documents and Settings\<username>\AppData.
2. Locate the folder that begins with TweetDeckFast.  For example, the complete name of that folder on my PC is TweetDeckFast.F9107117265DB7542C1A806C8DB837742CE14C21.1.
3. Open the Local Store folder.
4. Edit the preferences_<username>.xml configuration file with your favorite text editor.
5. Change the windowState XML element’s x attribute to 0.  If you don’t see the TweetDeck UI, it is because the x attribute’s value is negative (which makes sense if the external monitor was on the left side).
6. Save your changes to that file and load TweetDeck.  You should now be able to see the UI.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge.  Soon, more windows will be broken, and the sense of anarchy will spread from the building to the street on which it faces, sending a signal that anything goes.

I couldn’t help myself thinking how this theory fits well with the current state of software development.  When a software project first begins, it is void of any imperfection for no one began to write a single line of code for it.  Then as the team forms and the tasks are being assigned and executed, the team members start to breath life into the software.  That software could have a very different life depending on various factors of the team in charge of developing it, such as the team members’ experience, skills, knowledge, professionalism and passion for the craft. 

From my days of consulting and working as a team member, I more than often see a lack of responsibility from the individual team member for the most important organ of the software: the source code.  Once the source code has started to rot, it doesn’t matter how colorful or beautiful your design documents are or how detailed your development plan is…your software has a cancer and it will die unless you do something about it.  The typical scenario of the Broken Windows theory in software development goes like this: Robert, a programmer, is working on a subroutine for the Shipping module.  While at it, he notices that the NotifySupplier method is lacking a couple of guard clauses and the comments don’t reflect the code at all.  Since he wasn’t the one to write that code, he ignores it and continues working on his work item.  Will he remember to ask the developer who wrote the NotifySupplier method that it is in need of some fixing?  Who knows.  One meeting here, one phone call there, and chances are that Robert will forget about it.  Upon that time, the software has started to confirm the theory.  It now has a broken window.  What’s even more dangerous is that this theory can cascade all over the core of the software if its internals show a high degree of coupling with many components.  A good analogy would be like a tree burning in a forest.  It doesn’t take much time for the fire to spread to the other trees.  The outcome of this is simple: chaos.  The remedy is also simple: you.  What are you going to do about it?  Are you going to run from it or are you going to take corrective actions to prevent the cancer to spread all over the system?

Another potential risky situation that may arise from the Broken Window theory in software development is that if you don’t take care of fixing the broken code as soon as humanly possible, your junior developers and interns (if you have any) will have the impression that all this is normal in our industry.  The result of this is that as they continue to build and ship software in the future, those junior developers and interns will have shipped products with broken windows in them.  The theory can also backfire on your organization as the developers, sooner or later, realize that the organization isn’t mature enough and might decide to work somewhere else that will provide them the proper environment to appreciate the craft of building software and pay attention to the smallest details.   Here are a few examples of what I consider a broken window in the code and that should get fixed as soon as possible:

• Missing unit tests
• Comments out-of-sync with the target code
• A method, class or module that should be refactored
• A complex piece of code that could be replaced with a design pattern to better express its intent
• A broken build
• Etc.

There are also some solutions to prevent this theory to hinder the software project:

• Performing code reviews at least once a week
• Encouraging pair programming, as four eyes are better than two
• Putting in place automated tools that will break the build when rules are broken (FxCop, NDepend, NCover, etc.)
• Having the programmer check in her modifications in a private build such that if it succeeds then the modifications are merged to the repository.  Have a look at Team City for it does that very well.
• Providing intelligent tools to your developers so that they can work more effectively with the codebase.  A tool like ReSharper quickly comes into mind.
• Instilling an atmosphere that considers quality as the most important instrument to drive the organization to success.

But the tools and processes aren’t the heart of the solution.  What will either make or break the software is the attitude of every single individual affected to the project.  To encourage the growth and maturity of this attitude, developers should educate themselves on the trends of software development.  Developers should constantly thrive to do as much as possible to become more valuable software professionals.  

Though he doesn’t talk about this theory explicitly in his book, Agile Principles, Patterns, and Practices in C#, Robert C. Martin does reflect on the basis of the Broken Windows theory and also does provide a remedy to fight this problem in software.  According to him, and I agree with his statement, it’s all about having an attitude of being professional:

The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure.  Sterile procedure is what makes surgery possible.  Without it, the risk of infection would be far too high to tolerate.  Agile developers feel the same way about their designs.  The risk of letting even the tiniest bit of rot begin is too high to tolerate.

The design must remain clean.  And since the source code is the most important expression of the design, it too must remain clean.  Professionalism dictates that we, as software developers, cannot tolerate code rot.

Remember: Only YOU can prevent broken windows in your software project from spreading like cancer.  You have access to a grand vast of online resources and tools to help you fix those broken windows before it’s too late.  Do you have the attitude to do as such?

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The set of basic delegates that I think .NET developers should be familiar and comfortable using are the generic Action<T>, Comparison<T>, Converter<TInput, TOutput> and Predicate<T> delegates.  I will introduce you to each of these delegates by describing their usage with a simple example so that you can start using them in your codebase where needed.

The Action<T> delegate

In .NET 2.0, the Action delegate, declared in mscorlib.dll, has the following signature:

public delegate void Action<T>(T obj);

When Microsoft released .NET 3.5, four more Action delegates were included in System.Core.dll:

public delegate void Action()

public delegate void Action<T1,T2)(T1 arg1, T2 arg2)

public delegate void Action<T1,T2,T3)(T1 arg1, T2 arg2, T3 arg3)

public delegate void Action<T1,T2,T4)(T1 arg1, T2 arg2, T3 arg3, T4 arg4)

Regardless of the different signatures of the Action delegate, its semantic is to encapsulate a method which doesn’t return a value, and which holds a variable number of parameters:

• If the method is parameterless, you should prefer the Action delegate.
• If the method accepts one parameter, you should prefer the generic Action<T> delegate.
• If the method accepts two parameters, you should prefer the generic Action<T1, T2> delegate.
• If the method accepts three parameters, you should prefer the generic Action<T1, T2, T3> delegate.
• If the method accepts four parameters, you should prefer the generic Action<T1, T2, T3, T4> delegate.
• If the method accepts five (or more) parameters, you should prefer reviewing your design

A quick analysis with Reflector on the these delegates show that only the Action<T> delegate is being used by .NET in a couple of places, notably as a parameter for the ForEach method of both the static Array class and the generic List<T> class.  The other locations where this delegate is being used aren’t publicly accessible, so we will restrain ourselves to understanding the use of this delegate with a simple usage with the ForEach method of the generic List<T>.

Suppose we have a collection of toys which we want to iterate to display each of its name on the console.  A possible solution to satisfy this requirement without using the Action<T> delegate could be:

// Create our toys collection
List<Toy> toys = Repository<Toy>.FetchAll(); // Not that important how we get our toys collection here

// Iterate through the collection using a foreach statement and display each toy's name on the console
foreach(var toy in toys)
{
  System.Console.WriteLine(toy.Name);
}

The above solution works and your unit tests should pass.  But does it warrant a check-in to the source code repository?  This code we have written to satisfy the requirement seems to me very imperative, almost like how a robot would think.  I am mixing both the “how” and the “what” in this context.  For instance, I am iterating on the collection with a foreach statement (the “how”) in order to fulfill my intent which is to display the toy’s name on the console (the “what”).  Since my brain is better at processing one information at a time, I rather focus on the intention rather than the implementation.  Maybe we can hold on that check-in and see if there’s a better way to do this.

As a matter of fact, there is.  The generic List<T> class defines an instance method which iterates the collection and performs an action for each of its element via an Action<T> delegate.  The Array class defines the same method but it is added as an extension method on that type.  That being said, if there’s another data structure that implements IEnumerable<T> or IEnumerable which doesn’t have an equivalent of a ForEach method, there’s nothing stopping you from creating one on the type via an extension method.  This is the second solution that satisfy this requirement and which clearly brings out my intention forward because I don’t care how the collection is being iterated or what algorithm is used for the iteration, I’m just concerned of doing something with each of its element in a sequential manner.

// Create our toys collection
List<Toy> toys = Repository<Toy>.FetchAll(); // Not that important how we get our toys collection here

// Display each toy's name in the console (using a lambda expression)
toys.ForEach(toy => System.Console.WriteLine(toy.Name));

// You can also use an anonymous delegate to do the same thing...only with more keyboard typing than is necessary
toys.ForEach( delegate(Toy toy)
              {
                System.Console.WriteLine(toy.Name);
              }
            );

Ignoring the instruction using the anonymous delegate, and instead focusing on the one using the lambda expression, we can clearly see that our intention is much clearer.  On a side note, I will use lambda expression whenever needed for the following examples to keep them shorter.  I just added the anonymous delegate if you weren’t too familiar with lambdas.  As you see by using the lambda expression that I don’t have to use the delegate keyword and I can safely rest on the compiler’s type inference  functionality which are both a time saver.  The bottom line with the Action delegate is that it is there for you to do something (perform an action) on an element.  It is commonly used when some action must be performed on an element during an iteration over a collection, but keep in mind that it doesn’t have to be used just in the context of an iteration over a collection.  The Action delegate is also a powerful move to consider when, for example, a collection doesn’t offer a specific iterator that you’re looking for, such as an EvenNumberIterator.  In this case, for every iterated element, you’ll do something specific if the number is even, such as displaying it on the screen (notice that to use multiple statements with lambdas, those statements should be enclosed within braces):

List<int> numbers = Generator<int>.GenerateSequence( 10 ); // Generate a sequence of 10 random numbers

numbers.ForEach( number =>
                 {
                     // Display the number only if it's even
                     if ( number % 2 == 0 )
                        Console.WriteLine( number );
                 }
               );

Something to keep in mind with all the parameterized Action delegates is that the parameters are passed by value which means that any modification to anyone of them will only be local to the scope of delegate’s body or the method being invoked by the delegate.  In other words, the collection’s items won’t be modified.  The multiple parameterized Action delegates introduced in .NET 3.5 allow you to use them in case you need to do something with either two, three or four parameters (they can all be of the same type if needed).

The Comparison<T> delegate

Introduced in .NET 2.0, the generic Comparison<T> delegate is mostly used for sorting elements within a collection.  It is currently used by the Sort methods of both the Array and generic List<T> classes.  This delegate has the following signature:

public delegate int Comparison<T>(T x, T y)

The nature of the delegate is identical to the IComparer<T>.Compare method in that:

• if x > y, then a positive value is returned (traditionally that value is 1);
• if x < y then a negative value is returned (traditionally that value is -1);
• in the case where both x and y are equal, a value of 0 is returned.

This shouldn’t be too much of a surprise because internally the Sort method of both the Array and generic List<T> classes use the generic FunctorComparer<T> to wrap the delegate so that it can be used as an IComparer<T> object internally.  When the IComparer<T>.Compare method is invoked by .NET, it is actually the Comparison<T> delegate that is fired.  Pretty neat, uh?  The semantic of using this delegate (or the IComparer interface for that matter) is to define an alternative order for sorting elements within a collection.  Getting back to our toys collection, suppose we want to sort them by name (a string).  We could provide the following code to satisfy this requirement:

List<Toy> toys = Repository<Toy>.FetchAll();  // Again it doesn't matter how we get our toys

// using a lambda expression to define our sorting algorithm
toys.Sort((x, y) =>
           {
               if (x == y) return 0;

               if (x == null) return -1;

               if (y == null) return 1;

               return x.Name.CompareTo(y.Name);

           }
        );

This solution is great if you only have one sorting strategy and you foresee that it will not change in the future.  But there’s a better way to use this delegate.  In fact, the power of the Comparison<T> delegate is that…it’s a delegate!  This means that we can do some crazy and complex sorting if we must by combining various strategies!  What if we want to sort our toys first by name, then by price and also by a different criteria?  Using a lambda expression is asking way too much trouble.  Let’s see how we can take advantage of the Comparison<T> delegate in this case.  Let us now sort our toys by name, then by price.

private static void Main(string[] args)
{
    List<Toy> toys = Repository<Toy>.FetchAll();  // Again it doesn't matter how we get our toys

    // Instantiate our Comparison<T> delegate in a way that we want to sort our toys by name (first order), then by price (second order)
    Comparison<Toy> comparison = CompareToysByName;
    comparison += CompareToysByPrice;

    toys.Sort(comparison);
}

// Compare two toys by name
private static int CompareToysByName( Toy x, Toy y )
{
    if (x == y) return 0;

    if (x == null) return -1;

    if (y == null) return 1;

    return x.Name.CompareTo(y.Name);
}

// Compares two toys by price
private static int CompareToysByPrice( Toy x, Toy y )
{
    if (x == y) return 0;

    if (x == null) return -1;

    if (y == null) return 1;

    return x.Price.CompareTo(y.Price);
}

This is awesome because we can simply mix our sorting strategies through a simple delegate which will be used as a parameter to the Sort method of both an Array and generic List<T> classes.  Once the Sort method has finished its job, your collection will be sorted by the criteria you have specified. 

The Converter<TInput, TOutput> delegate

The next delegate that I would like to be familiar with is the generic Converter<TInput, TOutput> delegate which was introduced in .NET 2.0.  Just like its other counterparts, this delegate is being used by both the Array and generic List<T> classes, more specifically in their ConvertAll<TOutput> methods.  The signature of the Converter<TInput, TOutput> delegate is as follows:

public delegate TOutput Converter<TInput, TOutput>(TInput input)

This delegate is useful whenever you have to define a strategy to convert an object from one type to another type.  For example, you might want to convert an object of type System.Int32 to a type System.String.  Continuing with our toys example, let us consider the following simple requirement: we want to create a list containing only the names of every toy from our toys collection. 

List<Toy> toys = Repository<Toy>.FetchAll(); // Not really important how we get all our toys.

List<string> toysNames = toys.ConvertAll(toy => toy.Name);

It’s that easy!  Our strategy is basically that given a Toy (this is our closed type for TInput), we’ll return a String (this is our closed type for TOutput).  Just like we have done with the Comparison<T> delegate example, you can also mix in some conversion strategies.  Just remember that variance on delegates isn’t supported in C# 3.0.  For more information on this topic, I strongly suggest you to read Eric Lippert’s eleven-part posts on covariance and contravariance.

The Predicate<T> delegate

Though being used once again by the Array and generic List<T> classes, the generic Predicate<T> delegate is more used by the framework than the three other ones.  This delegate represents a method that defines a set of criteria and determines whether the specified object meets those criteria.  You can also see this delegate acting like a filter on a collection. The signature of the Predicate<T> delegate is as follows:

public delegate bool Predicate<T>(T obj)

Like I said, the .NET framework uses this delegate in both the Array and generic List<T> classes in many of their methods (Exists, Find, FindAll, FindIndex, etc.).  In short, you provide an evaluation context for a parameter where you either return true if the condition for that parameter is met, false otherwise.  Continuing with our toys example, suppose that we want to 1) find out whether we have a toy with a specific name and year, and 2) find all the toys that were made in Canada.  We could simply use the provided methods (Exists and FindAll) and passing them a Predicate<T> delegate that will contain our logic for evaluating whether or not the condition is satisfied.

List<Toy> toys = Repository<Toy>.FetchAll(); // We're not particularly interested in knowing how we got our toys.

// 1. We're interested in knowing whether we have my favorite Transformer of all: Megatron!  
// I have a couple of them, but I'm specifically interested in the one my parents bought me in 1985.
bool containsMy1985Megatron = toys.Exists( toy => toy.Name == "Megatron" && toy.Year = 1985 );

// 2. We're now interested in retrieving all our toys made in Canada.
List<Toy> myDecepticons = toys.FindAll( toy => toy.Country == "Canada" );

By simply invoking those methods and passing them a Predicate<T> delegate, I can concentrate on what I want in a more declarative way because I don’t have to explicitly iterate/loop over the collection with either a foreach statement, a for loop, a while loop, etc.  I just want to iterate over my toys, and either find out if a match was found or retrieve all my toys that satisfy some condition.  This last statement is also true for any of the other delegates that I presented here.

Conclusion

In this post, I wanted to familiarize you with some of the basic delegates that are offered by the .NET framework BCL (outside of ASP.NET, ADO.NET, etc.) that allow you more flexibility in specifying different strategies for various contexts (such as in finding, retrieving, converting or performing an action to an element of a collection).  In other words, these delegates allow me to concentrate more on the business logic rather than, for example, writing the plumbing necessary to iterate over a collection, because they are commonly used as a parameter to a method which already implements the plumbing on my behalf.

Whether I’m consulting with companies or training developers, more often than not I see these kind of delegates redefined in code because the developers were completely ignorant of the existence of these delegates!  That’s too bad, because violating the DRY principle forces you to document, test and maintain more code than you would actually need in your codebase.  Remember that the .NET framework isn’t solely C#.  The .NET framework is a huge toolbox that provides you with many tools (interfaces, classes, events, delegates, etc.) to build various applications.  The more you know about those tools and how to use them properly, the better your code will be and the more valuable you will become to your organization and team.

For more information on delegates, I highly recommend you the following links:

• Get a copy of More Effective C#: 50 Specific Ways to Improve Your C# by Bill Wagner.  More specifically, take a look at Item 18: Decouple Iterations from Actions, Predicate, and Functions to get a better understanding of Action, Predicate and Func delegates.
• Get a copy of C# in Depth by Jon Skeet.  This is one guy who has been very helpful in the .NET community by writing many useful articles and also published, in my opinion, the best practical book on C# 2.0/3.0 to date.
• Check out dnrTV’s episode on events and delegates with Mark Miller.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

For example, I tend to see a severe chronic problems amongst C# developers towards operations related to boxing and unboxing. Reading some newsgroups posts, blog posts’ comments and working with many .NET developers that have never heard these terms before made me aware that this chronic problem was pretty much widespread. This phenomena is even more real for developers that are too keen on using coding/refactoring tools, like ReSharper, because they tend to rely more on the suggestions of those tools instead of relying on deeper knowledge to decide whether or not a change in the code is due. Before building on this idea, I think it’ll be a good idea to refresh our concepts of boxing and unboxing in .NET. For this, I’ll share some notes from the excellent book on .NET programming, CLR via C# (second edition), by Jeffrey Richter.

Let us consider what happens when boxing occurs:

It’s possible to convert a value type to a reference type by using a mechanism called boxing. Internally, here’s what happens when an instance of a value type is boxed:

1. Memory is allocated from the managed heap. The amount of memory allocated is the size required by the value type’s fields plus the two additional overhead members (the type object pointer and the sync block index) required by all objects on the managed heap.
2. The value type’s fields are copied to the newly allocated heap memory.
3. The address of the object is returned. This address is now a reference to an object; the value type is now a reference type.

The C# compiler automatically produces the IL code necessary to box a value type instance, but you still need to understand what’s going on internally so that you’re aware of code size and performance issues.

You see that I have put the last sentence in bold. What Jeffrey is saying there is extremely important, because some tools aren’t smart enough to handle every single mechanisms of the compiler, therefore “you still need to understand what’s going on internally so that you’re aware of code size and performance issues”. Let us move on.

Let us now consider what happens during unboxing:

Unboxing is not the exact opposite of boxing. The unboxing operation is much less costly than boxing. Unboxing is really just the operation of obtaining a pointer to the raw value type (data fields) contained within an object. In effect, the pointer refers to the unboxed portion in the boxed instance. So, unlike boxing, unboxing doesn’t involve the copying of any bytes in memory. Having made this important clarification, it is important to note than an unboxing operation is typically followed by copying the fields. Frequently, however, an unboxing operation is followed immediately by copying its fields. Internally, here’s exactly what happens when a boxed value type instance in unboxed:

1. If the variable containing the reference to the boxed value type is null, a NullReferenceException is thrown.
2. If the reference doesn’t refer to an object that is a boxed instance of the desired value type, an InvalidCastException is thrown.

Now that we have a general idea of what boxing and unboxing are and how they work, we should consider the following as an important principle:

Obviously, boxing and unboxing/copy operations hurt your application’s performance in terms of both speed and memory, so you should be aware of when the compiler generates code to perform these operations automatically and try to write code that minimizes this code generation.

In a nutshell you get boxing whenever a conversion from a value type to a reference type occurs. Conceptually, unboxing is the reverse operation where a conversion from a reference type (such as an instance of Object) to a value type occurs. In .NET, value types are any object that derives from System.ValueType, such as your familiar primitive types (Int32, Boolean, Char, Decimal, etc.), structures and enumerations. Reference types are classes, interfaces, events, delegates, exceptions, etc. (basically anything that doesn’t derive from System.ValueType). The key element to understand is not necessary the mechanisms involved by the compiler, but rather to be conscious that there is a performance hit whenever boxing and unboxing occurs. Since the introduction of generics with .NET 2.0, we don’t have to deal as much with such concepts because generics provide type safety and better performance by avoiding boxing/unboxing operations. But not everything in .NET is generic and it’s extremely important to discover those potential “danger zones” where boxing/unboxing operations can occur within the framework, especially if you’re using development tools like ReSharper.

I’m a big fan of JetBrains and all their products that help me be more effective as a developer. Their continuous integration tool, TeamCity, is in my opinion the most innovative and complete software to set up a CI environment. Their dotTrace profiling application is also one of those tools that is installed whenever I set up a fresh development environment. But the one tool that I cannot code without is none other than ReSharper. I believe so much in that tool for making me more productive and effective when I code that I even wrote a post about reasons why the enterprise should seriously consider ReSharper for its developers. Unfortunately, ReSharper isn’t perfect. Excellent yes, but not perfect. Which means that developers should still use their knowledge about the programming language and the compiler to really take advantage of the .NET platform. This statement is even more pronounced when potential boxing/unboxing situations can occur. For example, consider the following code:

private static void Main()
{
  string name = "Brian";
  int age = 27;
  System.Console.WriteLine("Hello, my name is " + name + " and I'm " + age + " years old.");
}

At first sight, it seems that the above code is right.  I would agree with you at some extend.  I agree that it compiles just fine and that it outputs the correct message on the console.  If you had ReSharper installed, it will also say that the code is well formatted and that you’re good to check it in (the feedback for this is a little green icon on the top right side of the code window in Visual Studio).  The underlying problem with this code is that your application gets a performance hit because a boxing operation has occurred.  In fact, if you view the IL emitted by the compiler you will see a box instruction which forces the CLR to perform boxing for the value type.  The reason for this is that implicitly, this overloaded version of Console.WriteLine() calls one of the overloaded versions String.Concat() which accepts Object parameters (a tool like Reflector or ILDASM can help you to see this for yourself).

This is the point where knowledge and experience kicks in.  The proper way to write the above code is as following:

private static void Main()
{
  string name = "Brian";
  int age = 27;
  System.Console.WriteLine("Hello, my name is " + name + " and I'm " + age.ToString() + " years old.");
}

The reason the code above is superior is that you get all the benefits of the first version without the performance hit because no boxing occurs (again you can check this for yourself by viewing the IL emitted by the compiler).  As a matter of fact, calling a ToString() method on a value type will tell the CLR to invoke that method instead on that particular instance instead of boxing the value type as a reference type and then calling Object’s ToString() on it.  If you call Console.WriteLine( age ) instead, you might be surprised to know that no boxing occurs because one of the overloaded versions of that method actually accepts an Int32 as a parameter. 

This is why I said that knowledge and experience counts because unless you know these nifty facts you could blindly follow your tools’ recommendations which might propose some false positives.  An example of a false positive can be ReSharper graying out the ToString() method call on the age variable and recommending you to remove it.  Most developers using ReSharper will blindly follow such recommendation and actually remove the invocation of ToString() on the value type by either hitting ALT+ENTER on the line and let ReSharper remove the invocation or by reformatting the whole code file by hitting CTRL+ALT+SHIFT+F.  Though the above example seems pretty negligent, you can imagine this kind of operation in a loop or anywhere else a boxing/unboxing operation might occur in a library or within the framework itself.  A simple profiling on the application should detect such a performance bottleneck.  In other words, don’t checkmate yourself by blindly following your tools recommendations!

Even though I only touched on the subject of boxing and unboxing, it’s important to understand that there are many other areas that this post’s ideas apply.  For example, knowing when to explicitly implement an interface, deciding when to favor composition over inheritance, justifying the encapsulation level of a class and its members, etc.  These are strategies that some tools can’t provide a hint for, therefore you should rely on your knowledge and experience on the platform and the programming paradigms (object-oriented, functional, etc.) currently used.  If you have the chance of working in a larger team, I highly recommend your team to conduct code review sessions so that each team member can leverage each other’s knowledge and experience on the platform.  On the other hand, if you don’t have the privilege of participating in code reviews, or even worse if your organization doesn’t encourage such a practice, then you’re pretty much on your own, but you’re not alone!  In that case, I recommend you to read the following books which will no doubt make you a better C#/.NET programmer:

• CLR via C# (Second Edition) by Jeffrey Richter
• C# in Depth by Jon Skeet
• Effective C# by Bill Wagner

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

One thing that I wish came out of the box, but is currently missing, is a shortcut that allows me to run my unit test in the current context (by context I mean where my cursor is currently located.  If my cursor is currently in the body of TestA, then that shortcut will run the TestA unit test).  This will allow me to use the mouse even less, because right now I’m using the mouse to tell ReSharper to execute the current test. It turns out that though this functionality is lacking in ReSharper 4.1, the possibility to do so still exists. 

Here are the steps to follow if you want to map a keyboard shortcut that will run a test in the current context:

1. In Visual Studio, go to Tools –> Options
2. Expand the Environment node, then go to Keyboard
3. In the commands list, search for Resharper.Resharper_UnitTest_ContextRun
4. Assign a shortcut for that command.  In my case, I have decided to map it with Alt + X in the Global context.  That shortcut is intuitive (X for "execute”) and easy to trigger.  You can choose whatever mapping you want, just make sure there are no conflicts with other existing shortcuts.

Here’s a screenshot of the above steps in action:

Now you can place your cursor in a test context (test body or test method name) and hit that shortcut (Alt + X in my case) and that test will get executed.  A good tip to follow is to save your Visual Studio keyboard settings (and ReSharper settings too) under a backup repository (such as Live Mesh for example) so that you (or your team) can re-use those same settings in your Visual Studio sessions in other machines.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

A couple of things that made me jump while listening to this interview were when Michael Feathers says that in one company, in which he consulted, none of the developers have heard of the “Design Patterns” book by the GoF.  Even a story that Pete McBreen told us about a developer who didn’t checked in his code after working on it more than four weeks.  This is a very important interview that the JAOO folks have made public and even more important for managers and developers to watch it together.  A special thanks for this discovery goes to Dave Hoover who started a thread on “apprenticeship” over at the Software Craftsmanship Google group.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

A couple of years ago, Edsger Dijkstra was interviewed for sharing his thoughts on the discipline of programming.  For example, he mentions the beauty of code being measured in terms of quality, correctness and elegance.  That’s a key value which I hold tight in my heart when programming:  Always having that struggle with my ego, my mind and my intuition about how to write or change an implementation to make it just right…not perfect, but just right.  But what is just right?  See…that’s the kind of struggle I constantly have.  I love it.

While watching the interview, he seemed pretty sad or disappointed with the current state of computer science in the industry, as well as in the academia.  No doubt that we still have a long way to go to bring beauty in code, but I think that we have also make a strong progress since that first 1968 NATO conference on software engineering.  I believe that we’re living in exciting times in this industry.  I don’t know if Dijkstra would agree with that statement.  What do you think? 

NOTE: I came about this video from the most excellent blog of Peteris Krumins.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Mike Swanson has prepared for us a simple list of all keynotes and sessions by code and title from this year’s PDC.  This is some really cool stuff!

Remember that you can also browse the sessions by tag on the Channel 9 PDC 2008 page.

Now, let’s see what Azure is really all about…

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

• Code is easier to maintain because any change can be isolated to a very limited number of objects (hopefully only one)
• Code is easier to use and reuse because your objects are not tightly related to a web of other objects
• Code is easier to understand because we can focus on the behavior of a very limited number of objects (hopefully only one)
• Code is easier to test because of the reasons stated above (it also reduces the use of mock objects in our tests which simplifies writing and maintaining them)

The last point is very important.  Code that is easier to test favors the writing of unit tests, which avoids potential bugs infesting the system, and embraces change as we have confidence in refactoring the codebase because our unit tests act as a safety net so that if we should brake something in the system, we’ll be notified in a short time…if the tests were well written of course, but that’s a subject for another post.

The Principle of Least Knowledge, also known as the Law of Demeter, is one of those principles which favor low coupling in your codebase.  The most excellent book “Head First Design Patterns” defines this principle as the following:

The Principle of Least Knowledge guides us to reduce the interactions between objects to just a few close “friends”.

But what does this mean in real terms?  It means when you are designing a system, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes.

This principle prevents us from creating designs that have a large number of classes coupled together so that changes in one part of the system cascade to other parts.  When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.  — “Head First Design Patterns”, pages 265-266.

In other words, this principle states that given an object, any of its method should only invoke methods that belong to:

• The object itself
• Objects passed in as a parameter to the method
• Any object the method creates or instantiates
• Any components of the object

Least but nonetheless important is another pointer which makes the whole difference (like spreading Nutella on whole wheat bread): methods should avoid invoking methods belonging to objects that were returned from some other call.

For example, you should avoid writing the following:.

public void DepositAmount(int accountId, double amount)
{
  Account account = bank.GetAccount( accountId );
  account.Deposit( amount );
}

And instead opt for this:

public void DepositAmount(int accountId, double amount)
{
  bank.Deposit( accountId, amount );
}

You should see that the latter implementation is easier to maintain, reuse, understand and test.  We haven’t changed the interface of the method, just its implementation.  This implementation is easier to reuse and test because we don’t have to rely on another external (whether concrete or abstract) object, in this case an Account, to fulfill the service.  We only have one object, the Bank, to deal with.

One of my mentors refers to this principle as the “Tell, don’t ask” principle.  It makes a lot of sense.  Alec Sharp, author of Smalltalk by Example, summarizes this principle in other words:

Procedural code gets information then makes decisions.  Object-oriented code tells objects to do things. — Alec Sharp

That was the theory behind the principle.  Let’s see a concrete and simple example which demonstrates what we should avoid and what we should strive for in our design.

This example doesn’t follow the Principle of Least Knowledge:

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      var car = new Car();
      var driver = new Driver( car );

      driver.Car.Engine.Start(); // Not good.
                                 // Changing the signature of Start() will force to change
                                 // the callers too because of the strong coupling.
                                 // It also breaks the encapusalation of CarEngine because
                                 // the Driver knows too much about that class.
    }
  }

  class Driver
  {
    public Driver( Car car )
    {
      Car = car;
    }

    public Car Car { get; private set; }
  }

  class Car
  {
    private readonly CarEngine _engine;

    public Car()
    {
      _engine = new CarEngine();
    }

    public CarEngine Engine
    {
      get
      {
        return _engine;
      }
    }

    public class CarEngine
    {
      public void Start()
      {
        Console.WriteLine( "vroum! vroum!" );
      }
    }
  }
}

Whereas this same example does respect the Principle of Least Knowledge:

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      var car = new Car();
      var driver = new Driver( car );

      driver.Car.Start(); /* Much better.  Why?
                             Now, we can also make CarEngine private to the Car class.
                             Even though CarEngine.Start is public doesn't mean we should
                             use it!  Here we decided to remove the Engine property in the Car
                             class.

                             With this approach, the Driver could care less HOW the Car gets
                             started.  Now, CarEngine can evolve on its own without impacting
                             the rest of the system.

                             In other words...just because there's a gun laying on the ground
                             outside Montreal East and it's past 2AM...doesn't mean you should
                             take it!  Not everything that's public is good to take.
                             */
    }
  }

  class Driver
  {
    public Driver( Car car )
    {
      Car = car;
    }

    public Car Car { get; private set; }
  }

  class Car
  {
    private readonly CarEngine _engine;

    public Car()
    {
      _engine = new CarEngine();
    }

    class CarEngine
    {
      public void Start()
      {
        Console.WriteLine( "vroum! vroum!" );
      }
    }

    public void Start()
    {
      _engine.Start();
    }
  }
}

As you can see from the preceding example, adopting the Principle of Least Knowledge in your design allows you to easily evolve other components in your system since they’re not tightly coupled with other components in other areas of the system.  In this instance, I can easily evolve CarEngine without impacting the rest of the system.  For example, I can change the way an engine is started.  Furthermore, I can even make the CarEngine class abstract, then have various implementations of it and still avoid rippling changes to my system.  The Principle of Least Knowledge gives me so much ease, flexibility and possibilities to evolve my design and test my system.

Using a tool like NDepend can help you to pinpoint locations in your code where coupling is strong so that you leverage this principle and step-by-step eliminate the unnecessary coupling among components.

In conclusion, I urge you to not get too personal with objects.  Don’t be too polite with them neither.  With people yes, but not with objects.  If you need an object to do something for you, tell it to do so.  Another variation of "tell" is "command".  Don’t tell the object to ask another object to do some job for you.  If you see that happening, you should remove the intermediate object and have the one that knows more about the underlying operation to execute the job for you.  In his book Applying UML and Patterns, Craig Larman refers to the Information Expert pattern for this kind of situation.  According to that pattern, you should "assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility".

As you can see, there are many different interpretations for this principle.  Whether you know it as the Principle of Least Knowledge, the Law of Demeter or the Information Expert pattern, what’s important is that you understand and apply the essence behind it.  It’s all about doing object-oriented development right.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

For each of these exams, I have used the “self-paced” book series (the same series used for 70-536 and 70-529), which are:

• MCTS Self-Paced Training Kit (Exam 70-528): Microsoft .NET Framework 2.0 Web-Based Client Development
• MCTS Self-Paced Training Kit (Exam 70-526): Microsoft .NET Framework 2.0 Windows-Based Client Development
• MCPD Self-Paced Training Kit (Exam 70-549): Designing and Developing Enterprise Applications Using the Microsoft .NET Framework

Now, I’m going to say it straight and simple: all of these books suck.  The only good thing about them is that the authors have done a pretty good job copy/pasting the right MSDN documentation so that we wouldn’t waste our time doing it ourselves.  The major drawbacks I have against these books are the really poor coding style of the authors towards their examples.  A big portion of the examples contain errors, are sometimes misleading and some of them clearly won’t compile if you copy/paste the code in Visual Studio.   It’s sad to see so many mistakes like these, especially when each book is written by so many authors, because the credibility of these individuals take a pretty bad hit in the public’s eye.  I’m sure they were pushed by the deadline, but I wished they’ve polished the examples a little bit more.  I know…I know…Nobody’s perfect…I know.  But that’s still no reason to deliver mediocre products.

All right.  So just in case you’re thinking (or already started) to get your MCPD-EAD credentials, I am going to tell you how I’ve managed my time to pass each of these exams in hope that it might help you to pass them successfully.  In average, I dedicated about 40 hours per exam:

• 15 hours to read the book (1 hour in the morning and 1 hour in the evening should be enough for you to read the whole book within a week.  You don’t have to read EVERYTHING.  If you’re proficient in C#, then skip all the VB.NET examples.  Same idea goes if you’re more proficient in VB.NET than C#.   Whenever the authors mentions something in a box with the title “Real-World Scenario” you SKIP it.  It doesn’t matter.  The “real-world scenario” isn’t in the book…it’s in the REAL WORLD.  Don’t waste your time.  Also, don’t do all of the activities at the end of each chapter.  Just get through the book because you don’t want to waste too much of your time.  Here we’re really trying to cram our brain with tons of information.  The exams are roughly 80% based on memorization of the content and 20% on actual thinking.  Feel free to write notes and underline important ideas as you read along.  I used to write “EXAM” in red ink on the margin so that I can review it at a later time.)
• 20 hours to practice with Transcender or MeasureUp exams.  I have only used Transcenders, so I can’t say much about MeasureUp.  I’ve heard they’re quite good too.  Whichever you decide to do, I strongly suggest you to do all of the questions more than once.  Then when you’re confident enough about the material, take a moment to answer the questions in the “certification” mode to give you a better feel for the exam.  By the way, none of the questions of either Transcenders or MeasureUp were in the exams I’ve taken.  To be honest, the mock exams’ goals are to deepen your knowledge with the various technologies.  That’s it, that’s all.  Don’t put too much confidence in them, because what I’ve concluded at the end of each real exam is that the mock exams only helped me about 20% on the “knowledge” stuff and 80% on the actual “feeling” for the exam.  Take a week or two to practice these.
• 5 hours to practice some things I didn’t fully understand (proper use of some class, understanding the use behind some interfaces, getting comfortable with the security model, etc.) inside Visual Studio.  I strongly suggest you use Reflector to assist you in quickly discovering the information behind some objects in the framework.

I also suggest you to book your exam in advance.  For example, suppose you start studying for an exam today, then you will book an exam date four weeks from now.  This should motivate you to stay on course and respect your schedule.  And if that’s not enough, then mention to your boss and your fellow co-workers that you intend to pass this exam by that date.  Feel free to also share you exam date as a comment on this post! That should put enough pressure to get the job done…wouldn’t it?

In closing, I found that the 70-526 (Windows Applications) exam was the easiest exam of the bunch.  As for the hardest, I must say that it was the 70-529 (Distributed Applications) exam, mostly because I’ve never done .NET Remoting in the past.  And now that WCF is in the neighborhood, I doubt I’ll even have to touch .NET Remoting in the future!  It all depends on your experience with these technologies.  The more you practice and learn, the greater your chance in passing.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Juggling Is Not What You Think It Is

“Sometimes, I teach juggling classes.  Everyone wants to get the learning process of how to juggle three balls over with as quickly as he can.  The universal approach people take is to devote all their attention and effort at catching the calls.  They just throw ‘em up and rush around trying to catch them.  Extraordinary efforts are justified to catch the balls, because after all, if a ball hits the ground, you’ve failed.  The nascent juggler expects that with enough practice, they’ll get really good at catching balls.”

“Lots of your peers think that they’re good at juggling.  They rush this way and that, dealing with emergencies, handling multiple priorities, and never letting anything fall through the cracks.”

“But that’s not juggling.  That’s rushing around like a madman.  Let them be good at that.  There are plenty of people out there who are great at rushing about and handling emergencies, and frankly, they don’t need your help.”

“It turns out that juggling is about throwing, not catching. The way to learn how to juggle is not to focus obsessively on not dropping a ball.  No, the way to get good at juggling is to focus on your throw instead.”

“If you are good at throwing, the catching will take care of itself.”

“Once you’ve got three or four or five projects in the air at work, no amount of rushing around is going to keep them from crashing to the ground.  No amount of effort can help you catch the misthrown balls.  It’s physically impossible.”

“On the other hand, if your balls are well thrown, the catching is effortless.”

“That’s part of the secret of becoming remarkable.  Don’t spend any time at all worrying about catching.  Let your co-workers do that.  Instead, become the best thrower there ever was.  If you become good at throwing, you’ll find that you’re irreplaceable.  Organizations need really good throwers.”

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

They Say I’m Extreme

They say I’m extreme.
I say I’m a realist.

They say I demand too much.
I say they accept mediocrity and continuous improvement too readily.

They say, “We can’t handle this much change.”
I say, “Your job and career are in jeopardy; what other options do you have?”

They say, “What’s wrong with a ‘good product’?”
I say, “Wal-Mart or China or both are about to eat your lunch.  Why can’t you provide instead a fabulous experience?”

They say, “Take a deep breath.  Be calm.”
I say, “Tell it to Wal-Mart.  Tell it to China.  Tell it to India.  Tell it to Dell.  Tell it to Microsoft.”

They say the Web is a useful tool.
I say the Web changes everything.  Now.

They say, “We need an initiative.”
I say, “We need a dream.  And dreamers.”

They say great design is “nice”.
I say great design is necessary.

They say, “Effective governance is important.”
I say bold, brash boards that are representative of the market served - more than a token woman or two and an empty seat for the “forthcoming Hispanic” - are an imperative.  Now.

They say, “Plan it.”
I say, “Do it”.

They say, “We need more steady, loyal employees.”
I say, “We need more ‘freaks’ who routinely tell those in charge to take a flying leap…before it’s too late.”

They say, “We need Good People.”
I say, “We need Quirky Talent.”

They say, “We like people who, with steely determination, say, ‘I can make it better’.”
I say, “I love people who, with a certain maniacal gleam in their eye, perhaps even a giggle, say, ‘I can turn the world upside down.  Watch me!’”

They say, “Sure, we need change.”
I say we need revolution now.

They say, “Fast follower.”
I say, “Battered and bruised leader.”

They say, “Conglomerate and imitate!”
I say, “Create and innovate!”

They say, “Market share.”
I say, “Market creation.”

They say, “Improve and maintain.”
I say, “Destroy and reimagine.”

They say, “Normal.”
I say, “Weird.”

They say, “Happy balance.”
I say, “Creative tension.”

They say they favor a “team that works and lives in harmony.”
I say, “Give me a raucous brawl among the most creative people imaginable.”

They say, “Peace, brother.”
I say, “Bruise my feelings.  Flatten my ego.  Save my job.”

They say, “Basic black.”
I say, “Technicolor rules!”

They say, “We need happy customers.”
I say, “Give me pushy, needy, nasty, provocative customers.”

They say, “We seek Harvard M.B.A.s.”
I say, “I seek certificate-free ‘Ph.D.S’ from the School of Hard Knocks.”

They say they want recruits with “spotless records.”
I say, “the spots are what matter most.”

They say, “Integrity is important.”
I say, “Tell the unvarnished truth, all the time…or take a hike.”

They say diversity is a “good thing.”
I say diversity is breath of fresh, creative air - absolutely necessary for economic salvation in perilous times.

They say it’s “daunting.”
I say it’s “a hoot.”

They say, “Zero defects.”
I say, “A day without a screwup or two is a day pissed away.”

They say, “Think about it.”
I say, “Try it.”

They say, “Plan it.”
I say, “Test it.”

They say, “Radical change takes a decade.”
I say, “Radical change takes a minute.”

They say, “Times are changing.”
I say, “Everything has already changed.  Tomorrow is the first day of your revolution…or you’re toast.”

They say, “We can’t all be revolutionaries.”
I say, “Why not?”

They say, “We can’t all be a brand.”
I say, “Why not?”

They say this is just a rant.
I say this is just reality.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Here are the books I bought with the easiest and fastest $250 earned in my life:

• Agile Principles, Patterns, and Practices in C# by Robert C. Martin
• Working Effectively with Legacy Code by Michael Feathers
• Refactoring to Patterns by Joshua Kerievsky
• xUnit Test Patterns by Gerarld Meszaros
• Object Thinking by David West

I’ve actually started reading one of them, “Object Thinking“, and I have to tell you that it’s by far one of the best book I’ve read on object design.  What books would you have bought had you be given a similar amount of easy money?

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Here’s the full text of this essay (author unknown):

The Problem With Compromise

“Any organization with more than one person in it is a place of compromise.  If you want to get something done, a project okayed, a budget approved, a product sold, you’re going to have to compromise.”

“Most of the time, it seems as though half is better than none.  If you refuse to compromise, nothing happens.  And this desire to make it happen explains why so many things are mediocre.  It tells us why it’s so hard to make something remarkable, and why the remarkable succeeds so easily.  Because everything is a compromise, everything is sort of mediocre, isn’t it?”

“The wireless Internet access at the Denver airport has compromise written all over it.  I’m sure that when it was first designed (probably by a lone engineer in a cubicle), it was simple and fast and easy to use.  Today, however, it takes at least a dozen clicks to get started.  You need to enter a username and ID not once, but twice.  And your ID must be at least eight characters long and include numbers and a special character like $, %, or #.  So, something like “$3eVh!” is not secure enough because it’s too short.  Huh?  This isn’t your credit rating you’re protecting…it’s just the right to spend nine dollars and go online.”

“At every step along the way, each compromise to the sign-on system seemed reasonable.  At each step, the evolution of the design was simple: Either the project manager had to go along with the needs of this or that person (and the boss) or risk having the project canceled.  What would you do?  All those compromises may have made each person happy, but the final product was something that absolutely no one liked.”

“The first step to fighting back is understanding how compromise corrupts the things you’re so busy building.  More often than not, half is actually worse than none.  More often than not, you’re better off doing nothing than shipping something that is just average.  The project manager in Denver should have just stopped the project and let the chorus of complaints from passengers sink in to make the case for doing things the right way from the start.”

“Twenty years ago, Japanese car companies solved their quality control problem using a technique called Kanban.  Instead of following the American technique of having plenty of spare parts on the assembly line (workers were told to just discard a screw if it didn’t fit right), the Japanese adopted a fundamentally different strategy.  They kept only one necessary part at a time on the assembly line.  If the part wasn’t perfect, the entire assembly line stopped until a new part arrived.”

“The Americans said that this was insane.  Everyone knew that keeping the assembly line moving was the only way to make a car efficiently.  If a finished car wasn’t good enough, then you fixed it after it was assembled.”

“What Toyota and Honda understood was that the act of stopping the assembly line would send a powerful signal to every worker and to every supplier.  Sure enough, the line didn’t have to stop very often.  Every part improved in quality, because no one wanted to be responsible for shutting the operation down.  As a result, better parts improved every car as well.  With Kanban, very few cars left the assembly line in need of later reworking.  It turned out to be cheaper and faster to build cars right the first time than it was to fix them later.”

“You might try the same thing in your organization.  Refuse to compromise.  See what happens.  For a while, the assembly line will slow down or even stop.  Things won’t ship, products will get stuck in development.  And then a funny thing will happen: People will begin to understand that compromising the product just to keep the system working is stupid.  The only reason the system exists is so that you can make the things you make, right?  So if the system is demeaning your work, change the system.”

What do you think?  Are you currently in such a situation where compromise has settled in your project team?  What did you do to get out of the situation and prevent it from repeating itself?  Your comments are encouraged for this first lesson learned.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

As Seth Godin said in his widely quoted best-seller Purple Cow, first you need to stop being a brown cow - in a field of hundreds of other brown cows - and dare to be purple.  But after a while, that’s not enough.  You need a big moo, an extreme purple cow, an innovation that completely changes the game.

With the collaboration of "33 of the world’s smartest business thinkers", including Malcolm Gladwell, Tom Peters, Guy Kawasaki, Marc Benioff, etc., this book is truly a collection of 21st-century wisdom for any organization that’s looking for a way or a purpose to reach a higher plateau in the way business is done with people.  As stated in the back cover:

The Big Moo tells their stories.  Stories that will stick to your ribs, light your fire, and give you flashes of inspiration.  Stories about memorable customer service, amazing dedication, daring design standards, and legendary leadership.  The Big Moo will help you drive growth and change in your organization, from the mail room to the boardroom to the front lines.

No doubt that being remarkable (in the eye of the customer) will give you an edge over your competition that’s simply doing business.  But The Big Moo is not just for growing and differentiating organizations.  It’s also a valuable asset to help YOU grow both on a personal and professional level too!  In case you haven’t noticed, you are also in competition with other people when it comes to signing a contract for a job, a music record, a part in the school’s play, etc. 

I don’t want to say too much about this 177-pages book because I rather let you discover its fruits on your own.  While reading it daily on my way to work and back home, I realized that each single essay had something inspiring and concrete that could easily apply to my personal and professional life.  Speaking of essays, you never know which collaborator wrote an essay because each one of them is anonymous…neat, huh?  Also, we are recommended to share some of these essays publicly without any legal constraints.  Therefore, I will share with you three essays that struck me profoundly in further posts so that you can get a better taste of what the book has to offer.  So stay tuned! 

Meanwhile, I highly recommend anyone in your organization that has a role of leadership to get a copy of The Big Moo and share the stories with the rest of the organization.  Even better…Get some people in your organization to participate in writing their own remarkable stories and publish them either on your intranet or on the Web.  Let the "purple cow" in you run free from any boundary!

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

/// 

/// Stores an image to the database
/// 
private static void StoreImageInDatabase( string imageFilename, ImageFormat imageFormat )
{
    // Make sure the image file exists prior to proceeding with the storage.
    // Note: The File.Exists method will return false whether the imageFilename parameter is null or empty.
    if ( !File.Exists( imageFilename ) ) throw new FileNotFoundException( "The image file was not found", imageFilename );

    // Load the image from the filename received as a parameter.
    Image image = Image.FromFile( imageFilename );

    // Holds the byte representation of the image.
    Byte[] content;

    // Use a MemoryStream to store the image representation as stream of bytes.
    using ( var stream = new MemoryStream() )
    {
        image.Save( stream, imageFormat );

        // Convert the stream into an array of bytes because that's the value we'll pass to our SQL parameter.
        content = stream.ToArray();
    }

    // Our connection string (put it in your configuration file if needed)
    const string connectionString = "INSERT YOUR DATABASE'S CONNECTION STRING HERE";

    // Create an SQL connection based on a connection string pre-defined (the using statement will close/dispose the connection on our behalf even if an exception should occur).
    using ( var connection = new SqlConnection( connectionString ) )
    {
        // The SQL statement/stored procedure used to store our image.
        // Just make sure that you have a parameter named '@PICTURE' of type Image as well as a column named 'PICTURE' of type Image too in the table.
        const string sqlStatement = "UPDATE SOME_TABLE SET PICTURE = @PICTURE WHERE SOME_CONDITION";

        // Create an SQL command based on our stored procedure and SQL connection.
        using ( var command = new SqlCommand( sqlStatement, connection ) )
        {
            // Explicitly state that we'll be using a SQL statement or a stored procedure (CommandType.StoredProcedure).
            command.CommandType = CommandType.Text;

            // Define the SQL parameter which will hold our image to store.
            var parameter = new SqlParameter( "@PICTURE", SqlDbType.Image )
                            {
                                    Value = content
                            };
            command.Parameters.Add( parameter );

            try
            {
                // Open the connection.
                connection.Open();

                // Execute the stored procedure to store our image in the database.
                command.ExecuteNonQuery();

                MessageBox.Show( "Image stored successfully", "Image storage", MessageBoxButtons.OK,
                                 MessageBoxIcon.Information );
            }

            catch ( SqlException ex )
            {
                MessageBox.Show( ex.Message, "SQLException", MessageBoxButtons.OK, MessageBoxIcon.Error );
                // Other error handling, logging, etc.
            }
        }
    }
}

/// 

/// Retrieves an image from the database
/// 
private static Image RetrieveImageFromDatabase()
{
    // The image that will be retrieved
    Image image = null;

    // Our connection string (put it in your configuration file if needed)
    const string connectionString = "INSERT YOUR DATABASE'S CONNECTION STRING HERE";

    // Create an SQL connection based on a connection string pre-defined (the using statement will close/dispose the connection on our behalf even if an exception should occur).
    using ( var connection = new SqlConnection( connectionString ) )
    {
        // The SQL statement/stored procedure used to retrieve our image.
        // Just make sure that you have a column named 'PICTURE' of type Image.
        const string sqlStatement = "SELECT PICTURE FROM SOME_TABLE WHERE SOME_CONDITION";

        // Create an SQL command based on our stored procedure and SQL connection.
        using ( var command = new SqlCommand( sqlStatement, connection ) )
        {
            try
            {
                // Explicitly state that we'll be using a SQL statement or a stored procedure (CommandType.StoredProcedure).
                command.CommandType = CommandType.Text;

                // Open the connection.
                connection.Open();

                // Execute the query and build a DataReader with the results.
                var reader = command.ExecuteReader();

                Debug.Assert( reader != null );

                // Since we only have one image stored in the table (this is an example after all...), we'll only have one image to retrieve from our table.
                // If you have to retrieve one specific image (or more) from a collection of images in the table, then you can precise which one to retrieve via a parameter.
                reader.Read();

                // Since the only column of our table is used to store/retrieve an image, its column index is zero.
                // We simply cast that column into an array of bytes.
                var content = (byte[])reader[0];

                // Create a stream based on the entire content of our buffer.
                using ( Stream stream = new MemoryStream( content, 0, content.Length ) )
                {
                    // Write the content (array of bytes) to our stream.
                    stream.Write( content, 0, content.Length );

                    // Create an image object based on the stream.
                    image = Image.FromStream( stream );
                }
            }

            catch ( SqlException ex )
            {
                MessageBox.Show( ex.Message, "SQLException", MessageBoxButtons.OK, MessageBoxIcon.Error );
                // Other error handling, logging, etc.
            }
        }
    }

    return image;
}

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Let’s start with a simple example of a Person class.  One way I could write the class is like this:

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    // No constructors defined means the compiler will create a default (parameterless) constructor for us.
}

All right, so if I want to use this class, I need to know or figure out which properties of my newly instantiated Person object to set before actually using it.  This is an important step, because if the object participates in some method that requests a valid value from one of its properties, and that property isn’t in a valid, coherent state, then we might not get the expected result and debugging the problem might be cumbersome.  In our case, since a Person object is fairly straightforward and common, we pretty much know that its FirstName and LastName properties should be set prior to use it.  But what about its Age?  Let’s suppose that the Age is as important as the FirstName and the LastName.  Let’s also suppose that there are a bunch of other properties that defines a Person, such as Weight, Height, EyesColor, HairColor, Cavities, Faith, etc.  How can we possibly know that we must set the Age property when IntelliSense gives us a myriad of other properties belonging to this object?  Frankly, we can’t, unless the author of the class tells us or it’s documented somewhere (but then again who documents code, right?).

I believe that if the author of the Person class had use an intention-revealing technique to design the class, such as Test-Driven Development, she probably would’ve thought about how to properly initialize the class.  But then again, even that depends on the developer’s experience, philosophy and imagination on designing object-oriented software.

When designing objects, it’s important to ask ourselves a few questions prior to coding.  For example, should we provide a parameterless constructor (which will force the clients of the object to properly initialize its members)?  Should we provide constructors which accept parameters to properly initialize the object so that it’s ready to be used?  Even that question forces us to ask whether or not we should fully or partially initialize the object. 

Whenever I instantiate an object, I like to know the information it needs to be properly initialized (ReSharper is pretty helpful in such a scenario).  In other words, I want to know the “what” NOW…not later.  Furthermore, I don’t want the clients using my object to think too much about these concerns either.  I just want them to instantiate the object and be ready to start using it.  Am I asking for too much here?  I don’t consider myself a good programmer if I remove the developer out of the “zone” whenever she uses my objects.  It’s like constantly turning on and off a lighting switch…it gets annoying…very annoying.  That being said, if I take our previous little example, I would design the Person class as the following:

class Person
{
    public Person (string firstName, string lastName, int age)
    {
        // Implementation…
    }

    // No more constructors…not even a default (parameterless) constructor.
}

This constructor implementation would be valid if I want this object to be initialized with a FirstName, LastName and Age upon instantiation.  How can I know whether or not this is a “good” practice?  In most cases, you can probably find the answer directly in the requirements document, but again I strongly believe that it depends on one’s own experience, philosophy and imagination with object-oriented design and programming.  Nevertheless, with the now refactored Person class, I can easily communicate to the client of that class what she needs to provide to the object for it to be properly instantiated and ready to use.  I don’t make her think…I don’t push her out of the “zone”.

Another way to think about it is that when you go to the bank to open a new account, the bank teller doesn’t just hand you over a new “empty” account.  First, she asks you a few questions and gets some information from you, such as your name, your address, your credit history, etc.  Does it make sense for her to ask those things?  Absolutely, because it makes sense in the process of creating a bank account.  Going back to our Person class, does it make sense for that object to ask you to provide a FirstName, LastName and Age information prior to creating one?  Well, it also depends on the process of creating a Person object in your business domain.  (Software development is a field where there’s a lot of those “well, it depends!” moments).

Let me wrap up this idea by giving you two more examples from the .NET Framework.  If you search for the “MailMessage” class with Reflector, you will see that there are two MailMessage classes in the search results (see the picture below).  One of these belongs to the System.Net.Mail namespace and another one belongs to the System.Web.Mail namespace.  They both provide the same functionality, but the one from System.Web.Mail is actually obsolete.  In fact, it’ll ask you to use the one from the System.Net.Mail namespace instead. 

Figure 1. Search results for “Mail Message” in Reflector

• A public parameterless constructor which initializes an empty instance of it.
• Another public constructor which accepts two MailAddress objects as parameters (one is the source MailAddress and another the destination MailAddress)
• Another public constructor which accepts two string parameters (the source email address and the destination email address)
• Another public constructor which accepts four string parameters (the source email address, the destination email address, the subject and the message body)

I can understand that providing multiple ways to instantiate such an object is required in this context, because this MailMessage object belongs to a framework and not a custom application.  As Kent Beck righteously points out in his latest book, “Implementation Patterns”, there is a big difference in the way objects are designed and built in a framework versus a custom application.  As you can see, these constructors are telling me what specific information I should provide them in order to instantiate a fully working object.

Now take a look at the obsolete MailMessage class from System.Web.Mail.  You might expect the same number of constructors as the one from System.Net.Mail.  Instead, this one only provides one constructor: the default parameterless one.  Oh boy!  Now, the client of this class must know which properties (Attachments, Bcc, Body, BodyEncoding, From, CC, etc.) to set before actually using the object.  She is getting out of her “zone”…the light bulb is flashing…it’s annoying.  Good thing this one is now obsolete.

I still see much code in custom application that doesn’t offer the developer the guidance to properly instantiate an object prior to using it.  This forces us to ask ourselves “Ok, now that I have instantiated this object, what exactly do I need to provide it with for it to work properly?”.  I hate asking myself these questions.  I just want to use the object.  I want to think about more important things that knowing which properties to set.  If you’re at this crossroad and need to know what kind of information should an object request in its constructor, writing a unit test for it prior to coding might reveal a powerful weapon to counter the never-ending battle in our minds when designing good objects.

What other tricks or ways do you know about writing good object constructors?

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008