I'm in the process of writing a C# Wicket implementation in order to deepen my understanding of C# and Wicket. One of the issues we're running into is that Wicket makes heavy use of anonymous inner classes, and C# has no anonymous inner classes.
So, for example, in Wicket, you define a Link like this:
Link link = new Link("id") {
@Override
void onClick() {
setResponsePage(...);
}
};
Since Link is an abstract class, it forces the implementor to implement an onClick method.
However, in C#, since there are no anonymous inner classes, there is no way to do this. As an alternative, you could use events like this:
var link = new Link("id");
link.Click += (sender, eventArgs) => setResponsePage(...);
Of course, there are a couple of drawbacks with this. First of all, there can be multiple Click handlers, which might not be cool. It also does not force the implementor to add a Click handler.
Another option might be to just have a closure property like this:
var link = new Link("id");
link.Click = () => setResponsePage(...);
This solves the problem of having many handlers, but still doesn't force the implementor to add the handler.
So, my question is, how do you emulate something like this in idiomatic C#?
This is what I would do:
Retain Link as an abstract class, use a Factory to instantiate it and pass in your closure / anonymous method as a parameter for the Factory's build method. This way, you can keep your original design with Link as an abstract class, forcing implementation through the factory, and still hiding any concrete trace of Link inside the factory.
Here is some example code:
EDIT: Actually, This may be a little closer to what you want:
The beauty is it uses an init block, allowing you to declare as many optional implementations of actions within the Link class as you want.
Here's the relevant Link class (With sealed Builder inner class).
This is close to what you're looking for, but I think we can take it a step further with optional named arguments, a C# 4.0 feature. Let's look at the example declaration of Link with optional named arguments:
Why is this cool? Let's look at the new Link class:
Inside the static class Builder, there is a factory method Build that takes in 1 required parameter (The ID) and 3 optional parameters, OnClick, OnFoo and OnBar. If they are not assigned, the factory method gives them a default implementation.
So in your constructor's parameter arguments for Link, you are only required to implement the methods that you need, otherwise they will use the default action, which could be nothing.
The drawback, however, is in the final example, the Link class is not abstract. But it cannot be instantiated outside of the scope of the Link class, because its constructor is private (Forcing the usage of the Builder class to instantiate Link).
You could also move the optional parameters into Link's constructor directly, avoiding the need for a factory altogether.
I started this before @meatthew's good answer - I would do almost exactly the same except - except that I would start with an abstract base class - so that if you did not want to go the route of an anonymous implementation you would be free to do that too.
You can make the delegate be part of the constructor of the Link class. This way the user will have to add it.
Then you create an instance this way: