C# .NET
NUndoManager project started
Since I miss the amazing undo manager from Apples Cocoa Framework, I started to implement my own version of an undo manager, using the same recording techniques.
The so called NUndoManager is the first .NET 3.5 undo manager, recording lambda expressions of methods reverting the state of an object. Additionally NUndoManager groups single operations for undoing at once. Reverted undo operations are automatically to the redo stack.
The project is hosted here. Have a look or join the project if you want to add your own ideas.
Model view presenter - make your live easier
The MVC (Model View Controller) patter is a well known object pattern for GUI abstraction, which is taught on every it school. But many programing language don’t support the programmer to use this pattern from scratch.
For example Java, or C# .NET are based on a inheritance topology, the IDE’s create subclasses of the GUI components, resulting in huge source files, which are mixed up with everything. Not to mention that there is no compatibility to other GUI components, e.g. ASP .NET.
Apple with it’s Objective-C / Cocoa framework made a good step in the right direction, the programmer is forced to use the MVC pattern, since the GUI is described in so called NIB files. A controller class contains the code. The NIB file can theoretically be changed without changing the controller.
Also .NET 3.5 has a good answer to this technology, the windows presentation foundation. The GUI is described in XAML files, which are linked to classes. The XAML file could also be exchanged without changing the source code.
These technologies are based on the MVC patter, which still has a string connection between view and model. Further the controller has direct references to the controls within the view. If we want to change a windows forms view with a ASP .NET view, or change the model, the MVL pattern is not flexible enough. This is where the MVP pattern starts to unfold its strength.
The MVP, or more precisely the passive model view pattern is based on three simple interfaces; Model, View and Presenter. View and model are independent entities, only the presenter links the three parts together.
Passive Model View Presenter pattern
Compared to the MVC pattern, the presenter has no direct connection to the GUI controls of the view and the view does not know the model.
The presenter can observe the view and the model, if any changes happens within the model, the presenter gets notified and tells the view what to do. The same procedure happens, if any user interaction happens on the view; The presenter gets notified and has to handle the interaction.
In this case, we can easy implement the view in ASP .NET, Windows Forms, WPF etc. and run it with the same model and presenter.
In some cases, we need a container view, which can maintain any sub views. For this, we extend the passive view pattern with a sub view. The presenter of the container only knows the presenter of the sub view. Sub views are added by adding the presenter of the sub view to the presenter of the container view, model and view are not referenced by the container view presenter.
Since the container view needs no know the sub view, the presenter forwards the sub view to its own view. With this MVP pattern and IoC (Inversion of Control) it’s also possible to use different technologies to implement the views with only one restriction: All views need to be compatible among each other.
MVP - Sub View
The most nice advantage at all is, that we can use dependency injection to create our object structure. To describe this technology would be beyond the scope of this article, but I can provide you some links:
How to check whether a class implements an interface
If we work with objects, it is not difficult to determine if a class implements an interface. This can be done with the is keyword.
But it gets difficult if we work with reflection. The type object of a class, contains a method called IsSubclassOf, but if we try to use it with an interface it returns false in any case and if we try to get all implemented interfaces and search the one we need, we’ll have to much work with this simple issue.
So how can we do this in a very easy way? I found the answer here. To shorten this long description, I’ll give you the answer right here:
typeof(IFoo).IsAssignableFrom(bar.GetType()); typeof(IFoo).IsAssignableFrom(typeof(BarClass));
The method IsAssignableFrom checks whether the type can be assigned from another. It takes a type objects as an argument an returns true if the type can be assigned.
Check nullable types
C# provides a feature for object-relationship mapping. Since a date time field on the database can be empty but the DateTime type in C# can not be set to null, there is a solution called nullable types.
The syntax for is:
DateTime? date;
The problem is, the type of this object is not DateTime, so how it’s possible to check a nullable type?
It’s quite easy since all nullable types are of the type Nullable<>. To compare the previous variable date you can use following code:
date.GetType() == typeof(Nullable)
Interfaces with explicit methods
Have you already been in a situation, where you are forced to extend a class and can not inherit from another class anymore, but you would like to make a proper structure? Usually interfaces are used in this situations, but its quite boring to implement it twice or three times exactly in the same way. Since .NET 3.5 there is a solution for this problem - Extension Methods.
Lets have a look on this solution. First you make the interface:
pubic interface IFoo
{
...
}
Then you create the extension method:
pubic static class IFooExtension
{
public static void DoSomething(this IFoo foo)
{
...
}
}
Next you create an implementation of the interface:
pubic class Foo : IFoo
{
...
}
And finally, you can use it:
Foo foo = new Foo(); foo.DoSomething();