NOthingyoumissed » c#

Hey, I Think I’ve Invented a New Pattern

togakangaroo — Sun, 17 Jan 2010 07:58:12 +0000

Ok maybe not totally new, I am sure that its just a projection of something I once noticed subcionscioiusly in a F# project. But in the C# space, I’ve yet to see something quite like it.

The problem is that programs are complicated. I don’t tend to help the issue. In a flash I don’t hesitate to layer on additional complexity with domain models, frameworks, and complex infrastructures. Entities, sevices, repositories and aggregate roots – they’re the tools that we reach for all too often. That is not to say that Domain Driven Design is a poor paradigm – I’m a big fan – it’s just not always necessary.

Take for example a typical scenario. You are given an integer which uniquely identifies a customer and are asked to generate a report of all their orders, export it to a pdf file and return as a Stream. My first impulse is to start with the customer and order objects, identify the bounded context, figure out the aggregate roots, start writing data access mapping code, and so on. If I’m lucky, I only do this for a few hours before hearing the voice of an incorporeal Ted Neward yelling at me to STOP. I was not asked to build a domain model, I do not need to keep track of state, there is no validation, or (much) business logic. The problems that DDD is intended to solve are simply not present here. I need to do one thing and one thing only, map an integer to a Stream!

And yes, I do realize that this is exactly what the CQRS guys have been harping on for years.

My Solution:

Each of my last few projects has contained a very simple interface.

public IMapper {
  OUTPUT_TYPE Map(INPUT_TYPE obj);
}

Get it? Put in an integer, get back a Stream, what could be simpler? Ok, maybe that’s too simple. Any change at all would require modifying the implementation. This is all that icky procedural programming stuff. What about reusability, encapsulation, separation of concerns, and our other OO goodies? Fortunately, we don’t have to give these up. All we have to do is introduce a couple of obvious seams. We no longer transform an integer directly to a Stream. Instead we:

Take the id and map it to a DataSet that contains the report data.
Map a DataSet to the appropriate fully built Crystal Reports ReportDocument.
Map a ReportDocument to a MemoryStream of a pdf file.

IMapper _dataProvider;
IMapper _reportGenerator;
IMapper _pdfReportExporter;

public Stream GetCustomerReport(int customerId) {
  return _pdfReportExporter.Map(
           _reportGenerator.Map(
             _dataProvider.Map(customerId)));
}

Pretty nice huh? Well not that nice. If you’re a naming perfectionist like I this should make you shiver. When it comes to maintainability, good intention-revealing namespace, class, and method names are worth a million unit tests and n-tier architectures. Forget requirements docs and self-documenting code, proper naming is the number one tool for communicating our intent.

I lecture my team on this constantly and yet I allow myself the use of the the term “Map”?! A generic term that could indicate anything except (unless you’re a cartographer) a concept from your ubiquitous langauge. I should be ashamed.

We want to keep our generic IMapper interface though, it’s so slick, allows us to write minimal code and you you could easily imagine it coming in handy. For example, perhaps as the domain itself becomes more complicated, it becomes useful to break our IMapper down further.
1. The integer is get mapped to a Customer entity.
2. This gets mapped to a ReportSpecification.
3. The ReportSpecification is evaluated and mapped to a StoredProcedureInvocation
4. The procedure is executed and finally returns our DataSet.

You could imagine all sorts of neat little tricks you could play with our IoC container – we could have it automatically link transforms together or subsitute out implemenations. Simply by knowing that all these components transform one object to another we could configure automatic caching, deferred execution proxies, and so on. All things that are made far easier because all transformations are achieved via IMapper.Map.

What we really need is a way to introduce aliases for the Map() method. Preferably ones that depend on the input and output type. So why sit there scratching our heads? C# is a flexible enough language, let’s just let’s do that thing that I just said.

public CustomerOrderReportGenerator : IMapper {
  public ReportDocument Map(DataSet data) {
    // implementation
  }
}
public partial static class AliasExtensions {
  public static ReportDocument GenerateReportFrom(this IMapper mapper, DataSet ds) {
    return mapper.Map(ds); }
}

And now we have aliases:

  _pdfReportExporter.Export(
    _reportGenerator.GenerateReportFrom(
      _dataProvider.GetOrderDataFor(customerId)));

The poor readability of this bothers me. The LISPers among us might not mind reading backwards through a stack of nested parentheses but as a fan of fluent interfaces I’d like to see my code read as close to natural english as possible.

Same trick, now featuring double dispatch!

public partial static class AliasExtensions {
  public static ReportDocument ComposeIntoReportUsing(this DataSet ds, IMapper mapper) {
    return mapper.Map(ds); }
}

Allows us to do:

  return _dataProvider
    .GetOrderDataFor(customerId)
    .ComposeIntoReportUsing(_reportGenerator)
    .ToStreamUsing(_pdfReportExporter);

And there you have it. Nice, fluent, and composable.

What do you guys think? Aliased Maps a good name?

Error Handling and the Message Repackaging Anti-Pattern

togakangaroo — Fri, 16 Jan 2009 23:28:10 +0000

I currently have an interesting responsibility at work. I am functioning as the manager and single-point-of-contact for a team in India working on imporving the codebase for one of our more important ASP.Net sites. I know what you’re thinkin. Did I say interesting? I meant infuriating. At the very least I should get a good “Lessons Learned” post out of this.

Overall the experience hasn’t been too bad though. I’ve been managing to maintain a decent rapport with their project manager and team lead, deadlines have been missed, but no more than I secretly expected, and overall they seem like fairly competent guys. Their work isn’t innovative, Agile, testable, or well factored, but its decent enough.

Except for the exceptions.

Browsing one of their recent commits to our SVN lately (ok, so technically speaking they couldn’t figure out Subversion so they ftp-ed and I did the commit for them) I was shocked to discover the following error-handling anti-pattern repeated 41 times!

try {
  // Do Stuff
}
catch(Exception ex) {
  throw new Exception(ex.Message);
}

Do I get to name it? Let’s call it the message repackaging anti-pattern. And in case you’re not already reeling from this, the following is a mildly edited-down version of the letter I sent (Notice the eschewed profanity. I believe a not insignificant achievement.)

Dear Team,

While looking through some of your committed code I noticed quite a few (a quick search shows 41) places where you have code of the following form.

try {
 // ...
}
catch(Exception ex) {
 throw new Exception(ex.Message);
}

Let me be absolutely clear: This is the worst possible way of handling exceptions!

Let’s go over why:

Not doing anything inside the exception. If nothing happens within the catch block then what purpose does it serve? I have seen people prepare their code like this in anticipation of going back and adding logging at some later date. Although this is not necessarily the best logging solution, it is acceptable when you actually implement the code! However, preparing your method like this in anticipation of some future date does nothing but make the code difficult to read. It’s not like it is that hard to go back later and add a try…catch block; if you’re using a refactoring tool like CodeRush it is literally four keystrokes.
Catching the base Exception. Not every exception can have something be done about it. The canonical example is an OutOfMemoryException or one implying the database might be down. Is there anything to do in this case other than drop the user to an error page? I would even go so far as to say that most exceptions fall in this category – you just can’t do anything about them. I strongly encourage you to read Stop Catching Exceptions for a more in depth discussion.
Treating the message as if it were the most important thing. Exceptions usually carry a heck of a lot more information than just their message. They carry their type and a StackTrace and a list of any inner exceptions. Many specializations of the Exception base have even more information specific to that type of error. Out of all that information, the message is arguably the least important – for debugging I would take a StackTrace over a message any day. But by creating an exception off of the message you are effectively stripping out all this useful stuff! If for some reason, you must create a new exception, at least use the constructor overload that includes the original error as an InnerException: new Exception(”I don’t know why I’m creating this”, ex);
Why create a new Exception object at all? You already have a perfectly valid exception object. It is a simple matter to do:
try { // ... } catch(Exception ex) { // Log or otherwise handle the exception throw; // Same as throw ex; }

So in conclusion

Don’t catch an exception if you aren’t going to do anything with it.
Try to catch exceptions at the appropriate level and for the appropriate task. (logging inside private methods is probably unnecessary)
Do not create a new exception, throw the old one.

Please take this as healthy constructive criticism. I hope that you agree with me on these points and that we can take care of this issue properly from now on.

A bit harsh perhaps, but I feel like for all the reasons above the immensity of this mistake cannot be overstated. If you are doing this in your code STOP NOW and apologize to the maintenance gods! You might even need to sacrifice a goat to appease them. It’s that bad.

In any case, the recent commit has only 38 instances of this error. So at least we’re getting better!