Expression Trees III - Partial Methods

This is the third part of our discussion regarding expression trees. In the previous post we discussed about textual representation of expression trees [http://www.shujaat.net/2012/06/expression-trees-ii-textual.html]. In this post we will be discussing the support of partial methods with expression trees.

Partial Classes help us in distributing the definition of a class. All these definitions are combined at compile time and a type is constructed by adding the bits from all these partial implementations. They have greatly improved the usage of code generation tools. Those of you who have experienced the pain, of there code being lost just because the code is re-generated, could understand the relief provided by this feature. It is also a great feature which can be used during refactoring. We can add new behaviors to a new partial implementation. Then we can gracefully retire the previous implementation altogether. The problem happens when want these partial types using each others code. Since partial types can not span more than one assembly, this seems alright.

Even with all of their limitations, partial methods really help during refactoring. We can distribute the declaration and definition of these partial methods across these partial types. We don't even need to provide a definition and that would still compile the code fine. That is why there are so many limitations for this type of methods so that there are no unnecessary expectations.

Let's assume that we are working on a complex architecture with many different systems interacting. The overall architecture is provided to support various business process across the organization. Now there is a change in business process for whatever reasons. It might be new or updated regulations from a regulatory body. Now we need to change the behavior we provide data to regulatory body. Or there might be any other reasons for changes in one of your system. In order to provide a seamless change, we add partial types to already existing types and provide extra requirements to this new type. Since other systems still need data from the overall-type so we use methods of older partial type in the new partial type. Now the overall-type is supporting new interfaces for its client. And it is generating data in older fashion by reusing methods from the older implementation. One of the way to do it is by introducing partial methods declaration in the new partial type. We can provide definition of these partial methods in other partial type. In a twisted kind of way this would also serve OPEN / CLOSE principle of object oriented design.

Now the bad news, we can not use partial methods (with only defining partial method declaration) in our expression trees. Who doesn't like coffee...Bloody coffee-phobics. Now we are implementing Coffee card and using a partial method declaration in the following type.


This seems alright. But if there is no definition of this partial method. Then the compiler starts shouting.

If we still want to use this then we can provide a implementing partial method declaration of the same partial method and the compiler would have no issues. Basically this would ensure the compiler that the method would actually be available when the expression will be evaluated i.e. run-time. Let's add another part of the partial type and see the issue being fixed.


Now the compiler should be happy!

Download


Zindabad!