Prakash Rai wrote:
If you have a genuine case where it makes sense to implement one method and not the other, then that means your interface is badly designed, and it should be split so the methods are in more than one interface. That way you can implement only the ones that make sense.
I did't understand ...
Well, I was trying to understand why you might want to do this. In cases where you might want to, it might well be a problem with your design. Here's a very artificial example to try and explain what I meant.
Let's say you were modelling cars, and you had an interface to define some of the behaviour.
So you've got a few concrete classes like this:
Now let's say we wanted to introduce an electric car. We've got a
CarLike interface - great, let's use that! Oh, but the
fillWithPetrol method doesn't make sense. So we want to implement
CarLike without implementing that method.
You could use Winston's suggestion, and have
fillWithPetrol throw an exception. But that doesn't stop people trying to fill it with petrol. It just stops them succeeding. A better design is to segregate the interface.
And the problem is solved! By changing our interface design we get the effect we want without having to worry about not implementing abstract methods.