According to Wikipedia, a kludge (or, alternatively, kluge) is a clumsy or inelegant solution to a problem or difficulty. In engineering, a kludge is a workaround, typically using unrelated parts cobbled together. Especially in computer programs, a kludge is often used to fix an unanticipated problem in an earlier kludge; this is essentially a kind of cruft.
When I first stumbled upon the concept of anonymous methods in C# 2.0 the first thing I thought of was …jeez it’s just another name for GOTO! I’ve since changed my mind. Have any of you ever used the Gosub… Return programming construct from way back in the GW-Basic days? I’m dating myself but in a former life I had the responsibility of maintaining a servo controller program that ran a servo motor (a DC motor that is capable of moving in programmed increments forward and backward) for a plant that made flour tortillas. (yes – for Taco Bell no less!) But I digress. This particular brand of “Servo Basic” as it was called did not have the ability to address function calls. It was all done with line numbers. The program started at 10 and ended at the highest line number. The only way to program a function in this version of basic was to use the Gosub… Return construct. For instance “Gosub 100” would jump to line 100 in the program and start executing code until a “Return” statement was hit then control would return to the line after the calling “Gosub” statement. It was all very archaic but very versatile when it was all you had.
Now I tell you that story so I can tell you this one: I was happily coding one fine day when I encountered a problem that I needed to solve and it occurred to me that a Gosub… Return would be perfect here! It was a function with lots of values passed in that needed to perform the same processing multiple times but I didn’t want to pass all that data around on the stack. This, my friends, is the perfect case for an anonymous method. You can define an anonymous method anywhere inside a function and when you call the method, it has the same scope as the code that defined the method. The example here uses a SqlDataReader to populate an object. The reader may or may not have some columns in it. Since the only way to determine the columns in the reader is to use the GetSchemaTable() function and look at the results, I wrote an anonymous method to perform the search and was able to use the search to check for the existence of the questionable columns.
Notice the placement of the definition within the function. It is defined after the definition of the ReaderSchema DataTable. The executing code in the function has scope at the point of definition and so it “knows” about the DataTable. The syntax is a little funny but makes sense once you work through it. The name of the anonymous method is “HasColumn” and can now be called from anywhere in the function after its definition. It returns a boolean and accepts a string as designated by the delegate it is based upon.
Now I could have simply put the HasColum() in its own function and passed the table in to it along with the column name I’m searching for but then I wouldn’t have this totally cool use of an anonymous method, now would I? However, the question remains: elegance or kludge?