Decorator Revisited

I learned a few things about my decorator implementation last week from awhile back: 1) make sure your tests are good tests and 2) you cannot decorate methods called in a class called by other decorated methods (aside from using local Funcs for method implementations, which I will describe in another post).

First things first, how did I catch the mistake? These were my tests, including the one that caught the issue:

I was only receiving the start and end events and no others. To fix my mistakes, I ended up with two interfaces from my original interface so that I could appropriately apply my decorators:

However, this is now getting ridiculous. Nevertheless, deadlines were coming up, and I persevered. You’ll have noticed also that my api changed slightly. Instead of passing in the path and calling a static method on SpreadsheetDocument, I’m now passing in the SpreadsheetDocument. Much nicer for testing, especially since .Rows() is already my own extension method. I also have a public property for the item loader on the detail loader. I’m not thoroughly impressed, but it works.

Once I updated my tests:

and my implementations (note that my FakeDetailLoader became the implementation of FakeDetailItemLoader and DetailLoader is no longer an ugly abstract base class):

Maybe you can now see why it’s taken me awhile to post this. It wasn’t difficult, but it sure was tedious, and a little ugly. I’m not sure it was worth it for this simple demo, and I wasn’t sure on my project. I was later proved right, however, when we kept receiving increasingly complex requirements. Decorator to the rescue!

Advertisements