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?
Scenario: You go to an ATM machine, swipe in using your atm card, and ask for your bank balance.
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?
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. Continue reading
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.
With webbased apps, the developers can innovate new features and bug fixes, and painlessly deploy them. Because deployment is painless, it’s easier to have shorter release cycles. And in my opinion, this stimulates more innovation. So users get to wake up to new features more often. So much more fun 🙂
Which is why I like online feed readers.
This is not about SOAP vs REST. Nor am I an authority on SOAP. It’s just that I’ve been through enough pain with SOAP and I have gotten past the need to rant. This post is about where I believe SOAP went wrong.Soap stands for Simple Object Access Protocol, we know. They tell us it is simple. But they also tell us it is an object access protocol. I think that the latter contradicts the former.Now if SOAP could drop the object from it’s name, it would simplify things a lot. In fact we would get Simple Access Protocol, which is HTTP. What’s wrong with using HTTP instead of SOAP? This is an invalid question, to be answered in a few days.An object access protocol involves serializing messages and sending them to a remote object listening over a network. The object responds to those messages in some appropriate way. Everyone has his own ideas and views about how messages should be serialized. Yes. Every platform.