Saturday, January 10, 2009
Bikes
Well it looks like I shan't be riding on the road any more. We've decided the best thing to do, that keeps us both happy, is to drive to the station and change the KTM for a small dirt bike of some sort.
I quite fancy a Scorpa Long Ride though don't know if I could make it road legal.
I quite fancy a Scorpa Long Ride though don't know if I could make it road legal.
Friday, January 09, 2009
Bang!
I was a bit sore and stiff this morning but all my gear did its job. My knees are sore - I think my armour moved but hands, hips, arm and shoulder are all fine, though I can see the marks from where I hit the ground.
The handlebar snapped on the bike when it hit the ground and the impact with the car smashed the petrol tank and broke the fairing on the left hand side. The right hand side just has scratches on the crash guards so they did there job.
The bike has now been shipped off to Premier Bikes for a quote for repair. The tanks are expensive but if nothing else is bend it shouldn't be a write off.
The woman involved as admitted it liability so the insurance companies and solicitors can sort it out between them.
Sue, unsurprisingly, now wants me to stop riding the bike. Regardless of how I feel about that, the cost of parking a car at Woking is very expensive.
Wednesday, January 07, 2009
instanceof or getClass?
During a code review at work today, we diverged and started talking about whether you should use instanceof or getClass to compare types in the equals function of a class (well anything is better than doing code reviews).
Suppose we have a class A:
All simple enough so far so decare and compare a couple of instances of these classes:
A a = new A();
a.i =10;
B b = new B();
b.i = 10;
b.j= 99;
What do the .equals methods now return?
a.equals(b) returns false
b.equals(a) return false
In both cases, getClass() is returning the runtime type which is different for A and B so equals returns false. This makes sense but violates Liskov substitution principle because if you replace so instances of A in your application with B your equals methods will suddenly start to fail.
So we can change the equals methods to look like:
If we re-write equals for both A and B to use instanceof we'll get:
a.equals(b) returns true (because b is an instance of a) but
b.equals(a) returns false (because a is not an instance of b)
which isn't symetric and therefore not really an improvement on the first case. So basically you're stuffed unless you avoid inheritance where you have an equals method or go for something much more complicated, eg as described here. Frankly I just use the first option of avoiding inheritance and get on with something more useful instead.
Suppose we have a class A:
and a class B which derives from A:
public class A {
public int i;
public boolean equals(Object other) {
if ( this.getClass() == other.getClass() {
A o = (A) other;
if ( this.i == o.i ) {
return true;
}
}
return false;
}
}
public class B: A {
public class B {
public int j;
public boolean equals(Object other) {
if ( this.getClass() == other.getClass() {
B o = (B) other;
if ( this.j == o.j && super.equals(other) ) {
return true;
}
}
return false;
}
}
All simple enough so far so decare and compare a couple of instances of these classes:
A a = new A();
a.i =10;
B b = new B();
b.i = 10;
b.j= 99;
What do the .equals methods now return?
a.equals(b) returns false
b.equals(a) return false
In both cases, getClass() is returning the runtime type which is different for A and B so equals returns false. This makes sense but violates Liskov substitution principle because if you replace so instances of A in your application with B your equals methods will suddenly start to fail.
So we can change the equals methods to look like:
public boolean equals(Object other) {
if ( other instanceof this {
A o = (A) other;
if ( this.i == o.i ) {
return true;
}
}
return false;
}
If we re-write equals for both A and B to use instanceof we'll get:
a.equals(b) returns true (because b is an instance of a) but
b.equals(a) returns false (because a is not an instance of b)
which isn't symetric and therefore not really an improvement on the first case. So basically you're stuffed unless you avoid inheritance where you have an equals method or go for something much more complicated, eg as described here. Frankly I just use the first option of avoiding inheritance and get on with something more useful instead.
Labels: equals, getClass, instanceof, java, lsp

