java.lang.Class doesn’t define equals(), TDD and programming by contract
I wanted to avoid using if (o instanceof getClass()) and just compare if (o.getClass() getClass()). More of a style thing than any fear of instanceof being slow, and I know there won’t be any subclasses.
A quick look for information comparing classes didn’t reveal if it was safe to do this. I wondered if the same class came in through two different class loaders would be . I could test it myself, but it’s just easier to use instanceof.
I think it’s a symptom of our mindset when we’re writing documentation. We write for the common case. Unit testing encourages us to thing of the error and edge conditions up front. Maybe we should document them too.
Programming by contract style would make us be explicit about what we pass in as arguments, and exactly what we can get back. I’ve seens lots of documentation that doesn’t tell me what functions return when something goes wrong. My test cases make me think about this and I’d like to know the same information about the code I’m calling.
Naturally, as soon as I look for an example, I can’t find a good one. The doc for java.io.PrintStream.println(Object) doesn’t say what it will print if you pass it a null. (If you follow the links in the description you can find out, which makes it a poor example.) I’m sure we’ve all seen these sort of things.
Even if the language doesn’t support programming by contract, the documentation should.