Tuesday, January 18, 2011

When descission makers are clueless

It's a well known fact that you don't have to know anything to make a descision. Not knowing anything really speeds up the process of descisions and in some cases the descisions are just as good. In some cases they come with a price of being worthless or even disasterous.

When you don't know about what you are to descide upon a common aproach is to seek advice by somebody that know something about the subject.

Clueless descissions are most destructive when done in higher management because the consequences are often bigger. This includes politicians that are elected to make descissions. In Denmark there have rescently been some bad examples of such descissions regarding IT.

  1. Descissions about open document standards. Politicians kept OOXML in the loop although there was a better alternative that was more open at that time.
  2. NemId was chosen as the new authentication for citizens of Denmark when communicating with the goverment. (about taxes and stuff). I have used it and its work nicely from the end users point of view. The problem with the solution is that is uses certificates with public/private keys...  The private keys are placed on a centralized server. They have broken basic security principles and I think that is a problem.
  3. Rejsekortet is a new way of paying for public transportation. To do this they implemented their own encryption algorithm. The system has not been put into production yet, but the encryption algoritm has already been broken.
  4. Digital elections. Computers can be used for almost anything else. Elections part of a democratic proccess is not part of what computers can be used for. Pure electronic elections don't support recounting of votes and tampering with all votes can't be guarenteed. Elections of less importance, with truely trustworthy third parties can be implemented. Everybody has a interest in a democratic election and there is no trustworthy part that can ensure that the votes are not tampered with. It has been decided by politicians that electronic elections will be tried out.

Dynamic method binding

One of the added features to C# 4.0 was dynamic objects. It gives late binding to C# so everything doesn't have to checked at compile time. In some cases this makes it a lot easier to use reflection as you don't have to use any of the .net API's to do so. You can act directly on the object as if you had the type at hand. All you need to know is the footprint of what you need to access. Most examples emphasize how this can be used when integrating with other technologies like old com objects etc, but I have been looking for usages outside that scope. One is ofcourse reflection, another one is dynamic method binding that I will try and explain.

Basic OO with cats and dogs.



I create the traditionel object structure to support me explain what I mean. Animal is a pure abstract concept, Cat is an Animal and so is Dog.

Make the animals make som noise
I have created a MakeSound method that operates on the interface and one for each of the classes. As there is no general sound that will match any animal I just print ????? to the screen when in the context of Animal.
What I want is to have a list of animals containing cats and dogs and then call the MakeSound for each animal in the list.
As in C# < 4.0
The big question is what method is actually called. The answer is that the method binding is done at compile time, the best match is the method that takes the interface as a parameter. All the objects are treated as of type Animal. This is the way it has always worked in C# and it should therefore be no surprise if you have been in a similar situation. The output is as follows.

Result of program with static method binding

Use of var keyword

With C# 3.5 the var keyword was introduced. One might think that this changed the way this would work as the programmer no longer defines the type and the framework should therefore be able to select a better method implementation automatically. The answer is that the var is just a way to have the compiler derive the type instead of the programmer. This is all done at compile time and the best match will therefore still be the method that operates on the interface.

Handle the objects as dynamic instead
The dynamic keyword was introduced with C# 4.0 and this changes the possibilities when writing code like this. When treating every object in the list as a dynamic object, the compiler won't bind to any method but will leave it to the runtime to make the connection. This means that the type of every object is considered and handled on its own and the items in the list won't nescesarily result in the same method being called. This can be very usefull when iterating tree structures etc. The downside is that you will have no intellisense and no compile time validation when writing the code.

As the best methods are now called, the output will be cat and dog specific.

Output when treating the objects as dynamic
This can definately clean up some of my code. I might write a comment along with the code so that people in the future can figure out my intentions.

Related posts:
Wrapping objects with interfaces
Dynamic duck typing in .Net 3.5