Now that we have anonymous methods and anonymous types, how about extending this with anonymous interface implementations in C# The actual scenario I am thinking of is for WPF code. As discussed by John Gossman back at the PDC in his talk on writing Microsoft Expression, you can data bind your buttons etc. to IComand typed properties of your data objects. The end result is that your data objects look something like,
public class MyTextEditingModel
{
public bool IsTextSelected { get {...}}
public void MakeTextBold() {...}
public void MakeTextItalic() {...}
public void MakeTextUnderline() {...}
public ICommand BoldCommand
{
get
{
return new BoldCommandImplementation(this);
}
}
public ICommand ItalicCommand {...}
public ICommand UnderlineCommand {...}
}
But then you have to define a new class for every command. ie.
private
class BoldCommandImplementation : ICommand
{
MyTextEditingModel parent;
public BoldCommandImplementation(MyTextEditingModel parent)
{
this.parent = parent;
}
public bool CanExecute(object parameter)
{
return parent.IsTextSelected;
}
public void Execute(object parameter)
{
parent.MakeTextBold();
}etc.
}
This then starts to get messy with lots of extra classes you didn't really need, the need to pass around references to the parent class that actually does the work, and the implementation of the command being separated in the code file from the actual property that accesses them and the code that does the work.
Every time I code this what I really feel I should be typing is,
public class MyTextEditingModel
{
public bool IsTextSelected { get {...}}
public void MakeTextBold() {...}
public void MakeTextItalic() {...}
public void MakeTextUnderline() {...}
public ICommand BoldCommand
{
public bool CanExecute(object parameter)
{
return IsTextSelected;
}
public void Execute(object parameter)
{
MakeTextBold();
}etc.
}
public ICommand ItalicCommand {...}
public ICommand UnderlineCommand {...}
}
Of course, the C# compiler will just be generating code such as that in the first examples, with a class that implements ICommand, and passing of the 'parent' field into this. As a programmer though this shouldn't worry me, just as long as my code is nice and neat!
Just my thoughts on the matter, and I'd be interested to hear what other people have to think for/against constructs like this in a future version of C#.
Andrew Wilkinson
Anonymous Interface Implementations
tmike
Thanks Keith for the great suggestion. It will tidy up the code nicely (I hate unelegant code!). You still have to pass around a 'parent' unfortunately. This is something that anonymous methods do an excellent job of avoiding, automatically ensuring that anything that was required in the anonymous method was passed in without you having to worry about it as a programmer. All the same, your suggestion should work fine with the current version of LINQ - I have to confess that I've not tried it as I tried once to install LINQ and it failed with my version of Visual C# Express so I decided to put off using it until it is more "finished".
Thanks for the ideas though...
Andrew
Katu
That's a neat method. I like it! I'm quite looking forward to all the LINQ constructs becoming incorporated into a release version of C#. I have to say though, it will take a while before I get used to seeing lambda expressions in code.
Thanks again for all the ideas,
Andrew
sinha37834
Lambdas are your friends...
The syntax is different from delegates and anonymous delegates -- it's more generalized -- but that allows us to use the same syntax to represent both delegate methods and expression tree construction.
David Veeneman
Perhaps you should try creating a class that accepts Func<MyTextEditingModel, object, bool> and Action<object> delegates in the constructor and stores them in private members. Then define the CanExecute and Execute commands to call those delegates if they're non-null.
Something like:
public class TestCommand: ICommand { private Func<MyTextEditingModel, object, bool> _canExecuteDelegate; private Action<object> _executeDelegate; private MyTextEditingModel _parent; public TextCommand(MyTextEditingModel parent, Func<MyTextEditingModel, object, bool> canExecuteDelegate, Action<object> executeDelegate) { this._parent = parent; this._canExecuteDelegate= canExecuteDelegate; this._executeDelegate= executeDelegate; } public bool CanExecute(object parameter) { if (this._canExecute != null) { return _canExecute(this._parent, parameter); } } public void Execute(object parameter) { if (this._executeDelegate!= null) { _executeDelegate(parameter); } } }... then instantiate ...
public ICommand BoldCommand = new TextCommand(this, (parent, parameter) => parent.IsTextSelected, delegate(object parameter) => { MakeTextBold(); })... or something like that. Let me know if it works...
lionbrian
It's only passing around a parent because that's what you had going around. If your commands were such that they always had the same parent, you could just pull the parent reference in the constructor or at point-of-use.
If not, you could create a factory that took a delegate, bound it with a previously-known parent as before, and returned a command:
private ICommand CreateCommand(Func<object, bool> canExecuteDelegate, Action<object> executeDelegate) { return new TextCommand(this, canExecuteDelegate, executeDelegate); }