Using the dynamic Keyword in C# to Improve Object Orientation – A Follow-up

Based on some feedback, some clarification is warranted with regard to my previous post titled “Using the dynamic Keyword in C# to Improve Object Orientation”. As Jarek Kowalski correctly pointed out, the example code that I provided could have used the Visitor pattern instead to get the same result.  My impetus for using the dynamic keyword the way I did was slightly different from how I described my example—which was meant to be easier to read. I think it’s worthwhile describing the Visitor Pattern.  The Visitor pattern is a pattern used to separate the responsibility of an algorithm from the … Continue reading Using the dynamic Keyword in C# to Improve Object Orientation – A Follow-up

Using the dynamic Keyword in C# to Improve Object-Orientation

With polymorphism, object-oriented languages allow “…different data types to be handled using a uniform interface”.  Ad-hoc polymorphism is when you declare multiple methods of the same name but differ by the type of an argument.  For example: private static void Draw(Circle circle) { //… } private static void Draw(Square square) { //… } These are usually referred to as method overloads or method overloading.  Which Draw method that gets invoked would be decided upon at compile-time based on the type of the parameter passed to it. This is great, there are many situations where this is useful; but what about … Continue reading Using the dynamic Keyword in C# to Improve Object-Orientation

The Difference between an Anti-Pattern and a Code Smell

I think the term “Anti-Pattern” is being over used.  There’s various definitions for Anti-Pattern like “obvious but wrong, solutions to recurring problems” and “common approaches to solving recurring problems that prove to be ineffective”.  All definitions have a common thread: they’re recognizable solutions (pattern) that don’t work in at least one way and should never be used. This means that anything that does work, when used correctly, isn’t an Anti-Pattern.  Transitively, that doesn’t make incorrectly used Patterns Anti-Patterns. Code Smells, on the other hand, are defined as “…a hint that something might be wrong, not a certainty.”. I’ve seen the … Continue reading The Difference between an Anti-Pattern and a Code Smell

Evolving code over time

Given economics, time constraints, resource limitations, etc.; you can’t write all the functionality for a given solution for a single release.  Even if you weren’t limited by these constraints, you’re likely to get changing requirements as development progresses and everyone learns more about the software under development. It’s fairly easy to prioritize what is developed and what isn’t.  You simply develop only what you need (see YAGNI).  But, how do you manage adding new functionality without causing undue grief?  One way is to only make additive changes to the code.  For example, let’s say we have the method create CreateRequestPacket … Continue reading Evolving code over time

DevTeach 2009 Vancouver

The schedule for DevTeach 2009 Vancouver has been announced (  There’s lots of great software development sessions from some of the leaders in our industry. If you’re planning on improving yourself, this is the conference to go to.  Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains. If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price:

A Upcoming Pandemic of Domain Anaemia

There’s a well-known anti-pattern called the anaemic domain model[1][2].  This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour). It should be obvious that a domain model that isn’t truly object oriented is a domain model with a problem.  But, let’s look at other reasons why the Anaemic Domain Model is an anti-pattern.  Your Domain is the nexus, the essence, of your system. An anaemic domain model is basically a reporting system.  Each “Entity” becomes, essentially, a query.  This is fine, reporting systems are necessary and prevalent.  But, to shoe-horn … Continue reading A Upcoming Pandemic of Domain Anaemia

House of Cards Design Anti-pattern

I’ve had this anti-pattern in my head for years.  It’s an observance of some projects and methodologies that I’ve witnessed over the years.  I believe it’s a form of Voodoo Programming, Programming by coincidence, and is often a side effect of Cargo Cult Programming. Anti-Pattern Name House of Cards Anti-pattern Problem A problem occurs when software is written that works in a specific observed scenario but no one knows why it works in that scenario.  Observation of "working" is taken as enough evidence of completeness.  It is very often not enough to observe something working in one scenario for the … Continue reading House of Cards Design Anti-pattern

Becoming a Visual Studio Jedi Part 1

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi In much the same grain as James’ Resharper Jedi posts, I’m beginning a series of posts on becoming a Visual Studio Jedi.  It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible.  I think it’s useful for all users; but especially useful for those who are in situations where they can’t install refactoring tools like Refactor Pro! or Resharper. First, familiarize yourself with Sara’s Visual Studio Tips blog; then subscribe to her blog. I’ll attempt to … Continue reading Becoming a Visual Studio Jedi Part 1

Location of unit tests.

I had a short  conversation at Alt.Net Canada about the location of unit tests.  I personally tend towards a distinct unit test project.  But, I deal with mostly commercial, off-the-shelf (COTS) projects where I simply can’t ship code like that.  I also don’t want to wire-off the unit test via #if because I would then be shipping something different than that which was tested. From an enterprise application point of view, this is different.  I would have no problem including the unit tests within their respective project as production code

The winds of change are blowing

The essence of ALT.NET, or at least the essence that people made use of, was that it was a venue for improving one’s skills.  There has always been an undercurrent of other agendas there; but they never really took root. The problem with the ALT.NET moniker was it isolates it from most of the industry–it was an island of .NET practitioners.  This basically flicked its thumb at the other communities–other communities that propagated some of the guidance that ALT.NET was trying to proliferate. In the very spirit of continuous improvement it seems that ALT.NET is attempting to evolve and the … Continue reading The winds of change are blowing