Talk:Empty method over-rides

I was just looking for people's opinions of this. Obviously empty methods are in general an indication of bad design, but they are tempting. What can be done instead? Are there situations where empty methods are okay? Would it be appropriate if the empty method threw an exception? This would still probably cause us to discard polymorphism, because we would have to check the instance type. What solutions are there that would allow us to maintain polymorphism? What principles or maxims are relevant here? --Aidan Bebbington 04:15, 1 August 2009 (UTC)

One discussion [1] resulted in a solution where the empty method throws an exception. This seems like complete rubbish to me because then clients of that class must use the instanceof operator or similar, and so polymorphism is lost. --Aidan 06:22, 1 August 2009 (UTC)

I would probably argue that empty methods are bad because they indicate that there might be a problem with your inheritance hierarchy. If you are using an empty method you should probably ask yourself why you don't want to implement it and if you should be using inheritance the way you are. I don't really like the idea of throwing an exception in an empty method. Kind of seems like the easy way out. As far as design principles go, Avoid no-op overrides probably applies here as well as Refused bequest smell. --Janina Voigt

Ah, that's what I was looking for! How did I miss that? --Aidan 09:44, 1 August 2009 (UTC)