C# 3.0 Implicitly variable types

I have previously posted about C# 3.0 new features.

The good side for
var p = new Point(1,2) is the we don't have to write that much redundant code. (like Point p = new Point(1,2))

The bad side:
The compiler won't implicitly convert to: IPoint p = new Point(2,3).
The usage of p as concrete class will lead to a lot of "concrete-class-dependency" and, eventualy, to bad design.

It is a pitty that syntax is used as a crotch to enrich the language. Look at Lisp, Smalltalk and Ruby, to see how easy is to enrich the language and to create DSLs. (ruby sample: rake, and this article)

Another entry on Code Quality

I see "broken windows" every day.

Bill Venners blogs about it here.

Andy Hunt observes the psychological impact:

If you walk into a project that's in shambles—with bugs all over, a build that doesn't quite work—you're not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?

Singleton as anti-pattern

In 99% of the cases the singleton pattern is used as a global variable.

But as I said before, the singleton 's main problem is that it violates the Single Responsability Principle: we have a factory + an object.

But in some object-oriented languages (ruby, Smalltalk), classes are object-factories.
In these each object has it's own responsability. Clean: the class is a factory, the object is "... its responsability".

In a way, "singleton" is an antipattern, because of the language limitations.
In C++/java/C# you need to hide the constructor, and offer a static "getInstance()",
in ruby/smalltalk you need to overwrite the new message/method.

In c++/java/c# you wonder: "why can I instantiate objects from other classes, but not from this one", in ruby/smalltalk the API usage is uniform and clean.

Working Effectively with Legacy Code II

James Robertson blogs about a Michael Feather's talk here.
A 2nd entry here, about another topic.

Michael Feather's puts the finger on the wound:

"Utility classes" - ones with all static (Class) methods are a problem as well. Bottom line, the methods aren't where they belong. Preserve signatures, but create the appropriate methods in the appropriate classes.

More fun with ruby

Jim Weirich's presentation on Dependency Injection (in ruby).
If you are a ruby newbie, read Jim's guide for Java programmers.

And the cherry on the cake: Jim's presentation on continuations.
For more continuation goodies, see Sam Ruby's explanation, RubyGarden #1, RubyGarden #2 and IDEA Programmer's one. (or Bruce Tate article)

You might also check Seaside(Smalltalk), Borges(ruby) and DarkSide(Io) implementations. (no link, just google for them).

Reaction to James Gossling's rant about scripting languages

Very nice put together here.

Object-Oriented

Maybe object-oriented does not mean an object based system like Smalltalk.
Maybe it means "in that direction".
When I say "my window is north-oriented", it does not mean that my windows is at the North Pole, but, somehow, strangely, points to that spot.

Maybe that's why we accept so many non-object imperfections: we are just staying at the window seeking for the real thing.

A Case against Static Calls

I don't like static calls. Why?
You cannot mock them.
You cannot apply "Inversion of Control", specifying the class (role A) as a collaborator of the user (role B), in the user's constructor.

A static function belongs to a class, and a class is not an object (in the most enterprise- object-oriented languages). This function represents a responsability which you cannot isolate, or replace (mock). This makes the testing/maintainance harder than it should be.

In an OO world, each responsability should be materialized by an object, see the Single Responsability Principle. But a class is not an object, so you cannot treat it as a an object.

The problem is that in some languages there is no uniform access, there is a discrimination between a class and an object, therefore they must be accesed in different ways.

Another issue is that a static method does not use the instance fields/methods of the class. A static method does not belong to the object, but to the class. If the class defines the behaviour of its objects, but a static method does not belong to the objects, then it should be defined somewhere else.

That's why the singleton is an anti-pattern: the class defines the object's behaviour (responsability 1), and it's creation/life-cycle (responsability 2).
A lot of other examples we can find in Michael C. Feathers book "Working Effectively With Legacy Code", where he suggests breaking the dependencies gradually: first make a method static, then move it to another class.

Closures "quote"

I found an interesting quote on lesscode.org, which expresses fully my hesitation (wondering):

Anyone that really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.

Actually a lot (all !?) the things I love about Ruby come from Smalltalk (and Lisp, but Smalltalk is closer to ruby, being an OO environment): closures, named arguments (ok is a hack in ruby, but is going to be solved), continuations.
I saw a post that exception handling in Smalltalk is a library !!! Isn't that a pure thoght !?

My biggest discomfort with Smalltalk is the image-based environment.
On one side, image environment is what I need: when I develop in java, I am not looking for files, but for classes. (I do type/function navigation).
On the other side, ruby is so lightweight: you write a script, and you can check-it in, take with you, etc. In Smalltalk, I need to extract the code from the image in a text file, do some stuff, and then reintegrate it elsewhere.

hmmmm, ruby or Smalltalk, where should I digg deeper?