views:

231

answers:

4

Is there way for a class to 'remove' methods that it has inherited?

eg. If I don't want my class to have a ToString() method can I do something so that it is no longer available?

+8  A: 

You can throw a NotSupportedException, mark it as Obsolete and use EditorBrowsable:

[EditorBrowsable( EditorBrowsableState.Never )]
[Obsolete( "...", false )]
void YourMethod()
{
    throw new NotSupportedException( "..." );
}

EDIT:
As pointed out by others: I describe a way to "disable" methods, but you have to think about carefully, where you want to use this. Especially throwing exceptions can be a very dangerous thing.

tanascius
@tanascius: If you get Exception arguement from Obsolete property, your code will be good;-)
Svisstack
@Svisstack: No, that are two different strings ^^ Maybe they should differ, because the *obsolete* message is for a developer, while the *exception* message could reache a user? Well, probably not - at least it shouldn't.
tanascius
@tanascius: ok, you defended;-)
Svisstack
+1  A: 

Short awnser, NO as all classes inherit from object and object has this method.

BartoszAdamczewski
+15  A: 

No - this would violate Liskov's Substitution Principle. You should always be able to use an instance of a subtype as if it were an instance of a supertype.

Don't forget that a caller may only be aware of your type "as" the base type or an interface. Consider this code:

object foo = new TypeWithToStringRemoved();
foo.ToString();

That would have to compile, wouldn't it? Now what would you expect to happen at execution time?

Now for ToString, GetHashCode, Equals and GetType there's no way to avoid having them in the first place - but usually if there are methods you want to "remove" from a base type, that suggests you shouldn't be inheriting from it in the first place. Personally I find the role of inheritance is somewhat overplayed in object oriented programming: where it's useful it's really useful, but generally I prefer composition over inheritance, and interfaces as a form of abstraction rather than base classes.

Jon Skeet
You are completely right - it is especially dangerous to make the `ToString()` method throwing an exception. There are a lot more *hidden* usages of `ToString()` than the one you showed (calling it directly).
tanascius
But surly you could use the `new` modifier to hide an inherited member (and throw a NotSupportedException, like tanascius suggested), without breaking any principles or throwing unexpected exceptions.
Allon Guralnek
@Allon: It will be always unexpected, when a `ToString()` call throws an exception ...
tanascius
@tanascius, I'm not specifically talking about `ToString()`. Say you have a `Ball` class which has a virtual `Bounce()` method that uses a virtual `BounceHeight` property to work. If you created a `ConcreteBall` class, you could override the `BounceHeight` property and return 0 while `new`-ing the `Bounce()` method and throwing a `NotSupportedException`. So that if you are using a `Ball` reference to a `ConcreteBall` object, `Bounce()` will not throw but will have no effect (as expected) while calling `Bounce()` on a reference to `ConcreteBall` will throw and be informative (as expected).
Allon Guralnek
@Allon ConcreteBall should still be able to bounce. The effect of calling the method is just that nothing occurs. If ConcreteBall could not bounce, then why is it a ball in the first place? Calling Bounce() on ConcreteBall isn't really an exceptional case either.
smack0007
@Allon: In my experience, that sort of behaviour is very confusing. It leads to changes which *look* harmless ("make variable more general") breaking code. Not a good idea, IMO.
Jon Skeet
I meant ConcreteBall as opposed to RubberBall, not ConcereteBall as opposed to AbstractBall - I only now realized the possible confusion, sorry for that. Anyway, I was just taking a page from the design of the `Stream` class, where `Seek` (and other methods and properties) can throw a `NotSupportedException` if the concrete implementation does not support it. Jon, I agree that generally this is not the best idea (for Stream, I would have gone for ISeekableStream, IWriteableStream, etc), but my main point is that I don't believe the answer to the OP's question is a straight up 'No'.
Allon Guralnek
+1  A: 

As others pointed out, you can't "remove" the a method, but if you feel it has wronged you in some way you can hide it (in your class).

From documentation:

class Base
{
   public static void F() {}
}
class Derived: Base
{
   new private static void F() {}   // Hides Base.F in Derived only
}
class MoreDerived: Derived
{
   static void G() { F(); }         // Invokes Base.F
}
R0MANARMY