Design Guidelines: Pure Functions & Private Static

If y is a function of x then x is called domain (independent variable) and y is called range (dependent variable).

y = f (x)

As we know from our calculus courses that vertical line test could be used to determine if there exists a function. It ensures that for a single domain value (x), there exists a unique range value (y)i.e. classic function is Single Valued. The function should always evaluate the same value no matter how many times we use the function i.e the function is Stateless. It is perfectly possible for two domain variables (x) to have the same range value (y) e.g. Identity function.

In modern programming languages, the concept of function has been adopted in a modified way. This pushes us to discuss why we have used "modified way" here. In order to make life easier for developers some of the classic function restrictions were relaxed by classic programming languages when they introduced concepts like Global Variables and multiple parameters. Object Oriented programming languages attempted to limit a few things but they started calling it method. The method has accessibility to all the instance and type members of the same type. It also has visibility of most members of the parent type in an inheritence relationship.

There is certainly no doubt that the life of a regular programmer developing simple application is a lot easier now. But advancement in technology which provided us the flexibility to have multiple flows of execution even within the same process. They multiple flows of execution were named as Threads and the concept was termed as Multi-threading. Now the method can be CALLED by multiple threads at the same time. It is possible that two or more threads are executing the same method simultaneously. Since we are using the instance members directly in the method's code, any change in the member would be reflected for the other which might cause unexpected result for the other threads. The problem happens just because that our methods are not free from side effects. They have a defined purpose to evaluate some result and as a side effect they can use / modify instance members. This is a given feature of Object Oriented Programming technology. Modern programming languages provide various synchronization techniques (such as locks) to avoid ending up in an unexpected state.

Side effects are lies. Your function promises to do one thing, but it also does hidden things. Sometimes it will make unexpected changes to the variables of its own class. Sometimes it will make them to the parameters passed into the function or to system global. In either case they are devious and damaging mistrusts that often result in strange temporal couplings and order dependencies. [Robert C. Martin - Clean Code: Chapter 4 - Functions]

The synchronization techniques really help us avoiding the side effect related issues of multi-threading. But the issue is that they help us fight with the symptoms and not the actual cause. The cause is unnecessarily relaxing the limitations of functions for the ease of development. There are several things to consider but we can start with avoiding use of any instance level member as much as possible in our methods. Doing that would definitely help us in avoiding the side effects. We will be making less use of synchronization techniques. Not only the performance of our code is better but the code is more naturally organic and readable. It is also quicker to program.

Oliver Sturm has a number of suggestions regarding defining pure functions. We are discussing one of the suggestions in this post. i.e.

Define thou's private methods as static.

Basically using the static modifier with a method is a reminder to the compiler to check whether any instance member is accessed in the method. If it is so, then it issues a compiler error stating the problem. This can serve as a warning to the developer making any change to the code later on. All the future refactoring attempts would also be considering the static nature of the method in mind.

The following is a type called CoffeeCard. This card can be used to pay for the coffee so that you don't need to carry cash to the coffee shop as long as you are maintaining enough balance. The type allows us to manage card balance. It allows us to add balance and charge for the coffee for a certain balance. We can check balance anytime by calling GetBalance() on the type. AddBalance() and ChargeCard() utilizes private methods to update balance and push the changes o the database.


As suggested above, let's update the private methods to static.


As soon as we change the method to static, the JIT compiler starts complaining about the use of _balance field, which is an instance member. As we know that any instance member from the same type cannot be used directly in a static method of the same type.



Basically the solution of this problem is easier than we think. We just need to change the signatures of private methods to accept the balance as a parameter. Since we need to update the _balance field after the operation, we can return the calculation result which can be used by the caller of these methods to update the instance member [_balance field]. Since these are our private methods, we don't even need to worry about outside world while refactoring them as it's none of their business how we implement functionality within our type. As long as we are not changing the behaviors of instance, we should be good which, in this case, we are not.


Let's see how we can use these methods in the public methods of CoffeeCard type.


Now our private methods are thread safe, they are deterministic with no side effects, they are context free. The biggest of all achievements, they are thread safe.

Does the method really belong to this type?
Resharper's suggestion is mainly because of the idea, "Since this method is not using any instance member, it is not an instance member itself and we should rather be specifying it as a type's member". In C#, we assign type membership using static. If it were VB, we would have specified the methods as Shared.

After you have updated the method to be static, just ask this question to yourself: Does this method really belong to this type? If the answer is Yes then you are done here. Smile and move ahead. But if the answer is No then we should continue on the road of design improvement. It seems that you were keeping this functionality here. It happens when Single Responsibility Principle is avoided. If this is some code which goes above and beyond the type's responsibility then we can move this to some other type. We might introduce new types and move this functionality there. Doing this would also improve our unit testing as we will be adding this functionality in public methods of the other type and hence we can unit test that.

If we want to add a new type (class), then we need to decide where we need to add this. We keep the visibility of the type to as the minimum. This depends on the the other types which might need the functionality of this new type. The choice of access modifier of a type is an important decision. Keeping all the types as public is exposing yourself to the infinite number of ways the types can be used. If we don't see that any client would be using our type from outside the assembly, we should never be making it public. If the new type is not expected to be used outside this scope of the class it is refactored from then it would make more sense to be keeping this class nested in the original class as follows:


Here we have kept the BalanceCalculator's access domain as private. This is allowed for a nested class in C#. Since we don't think that the class can be used by any code outside the parent class so it seemed like the best decision. The refactoring also made us realize that adding the balance and charging cards is not just an arithmetic operation. We might also need to consider the effect of any on-going promotion and discount.

Resharper Support
Resharper also provides support to suggest about the members which can be declared static. For our case, the suggestion can appear as follows:



This is definitely a configuration option and we can change the severity of resharper option to a value other than suggestion as well.



FxCop Rule CA1822
FxCop Rule CA1822 also suggests marking those methods as static which have no reference to any instance member.

http://msdn.microsoft.com/en-us/library/ms245046.aspx

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!

Expression Trees II - Textual Representation

As we all know that C# does not support Eval Mechanism i.e. the capability of evaluating a language expression at runtime. The languages, which support this feature, can parse string representation of an expression. They can evaluate the expression and return the result.

Modern languages can vary in the strength of support of eval mechanism. The above is javascript code using eval. It not only supports language elements (Math.pow) but it also has used variables from outside the scope of expression (x & y) which is a very strong support of the mechanism. The above code would result value as 300.

In order to support the eval mechanism, a framework must support runtime parsing of expressions and generation of executable code based on this parsing. For interpreted languages, it is a very trivial task. Compiled languages can use JIT compilation support to provide similar features. C# does not support eval mechanism as in the above example as it does not support string based expressions. Expression Tree is closest to the eval mechanism as it allows us to be creating dynamic expression (at runtime). It then allows us to create executable code based on this expression, cache them and reuse them during the life time of the application.

In the previous post [http://www.shujaat.net/2012/05/expression-trees-part-i.html], we discussed how we can create delegate based on an expression. The delegate allows us to run the code represented by the source expression. On the other hand, Expression can also provide its textual representation. This can not only serve logging but we can also use it for UI consumption. Let's use one of the expression introduced in previous post and write it on the console.

This would result in the following output:

Although this seems very promising but it has limited support for more complex expressions including BlockExpression and LambdaExpression.

Zindabad!

If Type Implements Interface == true - Part II

This post is the continuation of the last post where we discussed how to check whether a type implements some interface. you can find this discussion here [http://www.shujaat.net/2012/06/if-type-implements-interface-true.html].

In this post we will continue this discussion by introducing Type.GetInterfaceMap(). System.Type provides this type to provide the mapping between interface and type's method. We can determine what type's method implement which interface one. This mapping can be used by framework developers to do amazing things.

Let's start by discussing how we can use this to determine whether a type implements the specified interface. We introduce this method which accepts the type and interfaceType as parameters. The method returns true if the type actually implements the interface and false otherwise.


Let's use this method as follows:


Here we are checking whether the type Student implements IStudent and ICalculator<int> interface. Definitely the first statement is true and the other one is false. Let's run this and see if the result is as expected.

Basically Type.GetInterfaceMap doesn't return boolean, it returns System.Reflection.InterfaceMapping structure type if the type actually implements the interface. In case the type doesn't implement that, it just throws an ArgumentException. We are catching the exception in our code and returning false in this case.

As discussed above, the main purpose of availability of this method in System.Type is to determine the interface methods and their corresponding methods in target type. Let's print this mapping for the provided type and an interface.


Let's use this for Calculator<int> and ICalculator<int>.


This would result in the following output:

Type Casting
In this method, we do an explicit cast into the interface type. Obviously, the type of interface must be known at compile time. If the object's type doesn't implement the specified interface or it does not inherit from the type specified type then it would result in Invalid Cast Exception. Obviously, this method wouldn't be recommended for a production code. Please see this msdn article for type casting and conversion [http://msdn.microsoft.com/en-us/library/ms173105.aspx].


Zindabad!!!

If Type Implements Interface == true - Part I

How to check if a type implements certain interface. .net framework provides various options to do just that. In this post we will be discussing these options and their limitations, if any.

Type.IsAssignableFrom
This method is provided in System.Type to verify whether a reference of a given type can be assigned an instance of a specified type. As we know that polymorphism support in object oriented programming languages allow an instance of a certain type to be assigned to a reference of another type if that another type is either a parent in the inheritence hierarchy or an interface which the type implements. This method is to check just that. Let's suppose we have an interface IStudent with a contract as follows:


Now we implement this interface with a type, named Student, as follows:


Let's use Type.IsAssignableFrom to find out to check the type assignment for these types.


Let's run the above code and see if it behaves as expected.

As stated earlier, Type.IsAssignable can also be used to see the possible polymorphic behavior for inhertitence relationship between types. Let's add another class SpecialStudent which inherits from Student.

We can do the similar check for type assignment check between Student and SpecialStudent.


Running the above code yields the following output:

In the following example, we are using Type.IsAssignableFrom to scan all the assemblies in the current App Domain to find out the types which implements a particular interface. The interface type is passed as an argument to the method.


Let's use the above method to determine the types implementing IStudent interface. In the following code we are displaying all the implementing types on the console.


When we run the above code, it yields the following output.

It prints Student and SpecialStudent types. Additionally it prints IStudent as IsAssignableFrom would return true in that case too. We can just check if the other type is itself not interface.


Which just prints Student and SpecialStudent on the screen getting rid of IStudent.

Type.GetInterfaces()
This method provides list of all the interfaces that the specified type implements. In order to check whether the type implements our required interface, we can get this list from Type and check if our required interface is in there.


We can use the above method as follows:


Since we have the list of all the interfaces as System.Type objects, we can determine other interesting things about the interfaces. In the following example, we are determining whether the interface is generic, and we are interested in the type arguments.


Type.FindInterfaces()
As we discussed above, Type.GetInterfaces returns all the interfaces implemented by a type. We can later filter it with any filter criteria which is desired. System.Type.FindInterfaces is to make this filtering easier by just returning those interfaces implemented by a certain type which fulfills a certain criteria.

This ensures that all the interfaces that the type implements must pass through this filter criteria. Actually the filter method is called for each interface that the type implements. In the following example, we are expecting a certain type passed as argument. We need to check if the type implements an interface passed as the other argument.


Since we are just interested in checking whether a type implements a certain interface or not, that is why, the expression is very simple. Basically the .net framework giving us each interface implemented by type, one by one, to decide whether to include that in the resulting list or not. If we need to include this then the filter expression should return true, false otherwise. We can also return true all the time and get the same result as Type.GetInterfaces().

Type.GetInterface()
This method is to get the type of an interface implemented by a certain type. We just need to pass the interface name as string argument. The following example expects the type and the expected interface type as the parameters. It the uses Type.GetInterface() to determine if the type implements the specified interface. It uses both Type.Name and Type.FullName to run this test.


Let's use this method to test whether Student type implements IStudent and see the output.


This would result in the following output (which is as expected):

Let's use this to test if Calculator<int> implements ICalculator<int>


Let's run this and see the output. Please notice that using full name with generic type would not get the specified interface.

There is another overload of the same method [Type.GetInterface()] which allows a case-insensitive match for the string passed as the interface name.

is Operator
This is the easiest option to check the type of a certain object. The expression would yield true if the object is of the exact type or a child type as the specified type. This would also yield true if the object is of type which implements the interface. In the following example, we are creating Student and SpecialStudent instances. Since SpecialStudent inherits from Student which implements IStudent interface. The relationship can be seen in the following hierarchy:

Based the above hierarchy please see the expectations in the code below specified as the comments following the statements.


Which can be verified by the following output: