Test driven development and type safety

This post will not go into how tests are written. There are many excellent guides to test driven development on the net. I might post some links for this later. On to business…

Code won’t compile unless our objects talk to eachother as the compiler expects.

Take the example of the ATM from my last post. The ATM object has two responsibilities: login, getBalance. The compiler can ensure that a user object only invokes getBalance and login. That is called type safety. If we try to invoke some responsibility of the ATM object such as showStatement, which it does not have in the example, the compiler will scream and wail like a spoiled child. You will be forced to remove the offending line of code. What can go wrong now?

data hiding, encapsulation

Scenario: You go to an ATM machine, swipe in using your atm card, and ask for your bank balance.

c# 2.0 is nice, but there’s feature creep too

Feature creep killed C++ for me and for many people. It also killed Perl for us in the same way. So I when I looked up the new features on C# 2.0, the first thing on my mind was feature creep. And sadly I saw it.

I like the way they’ve done gererics. I like the new iterator features. I like the new containers, these are very cool! I like anonymous functions. I suspect that I won’t use it too heavily, but I believe that the feature is needed. In the case of iterators and anonymous functions, I appreciate the syntax. They’ve taken care to keep the syntax intuitive and consistent with the C# look and feel.

But I don’t take to partial classes so well. I see in it a striking resemblance to the #include keyword in C and C++. To my mind it would only help when you need to split up a large class into multiple files. When would you need to do this?

what is a object?

I thought I’d put down some ideas here now and in the future about this. I’ve been meaning to put this down somewhere for a long time, so why not here.This is for people looking to understand object orientation in a light different from the traditional approach.

how I would chatter to services

In a previous post, I said that we need to do away with object access protocols.There are two reason why I think that this is essential.

Firstly, we must recognize that network based services behave differently from objects. They suffer from different constraints. For example, it is not possible to “instantiate” a new instance of a network based service whenever the client acquires a “new” object of the service type. And there are other obvious differences; such as the expense of making method calls over a network as compared to making method calls on objects residing in local memory. Considering these sharp differences, it makes sense to me to treat “the service” as a different kind of animal altogether.

The second reason is the complexity of an all inclusive message format.