Hiding a base function so it is not accessible

[Mike]

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

From MSDN:
"A derived type can hide an inherited member by defining a new member
with the same signature. This might be done to make a previously
public member private or to define new behavior for an inherited
method that is marked as final."

http://msdn2.microsoft.com/en-us/library/exe76ct6(VS.71).aspx

 

[cfps.Christian]

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

From MSDN:
"A derived type can hide an inherited member by defining a new member
with the same signature. This might be done to make a previously
public member private or to define new behavior for an inherited
method that is marked as final."

http://msdn2.microsoft.com/en-us/library/exe76ct6(VS.71).aspx

Base:
public void DoSomething()
{}

Derived:
private new string DoSomething()
{ return ""; }

its either that or new private string -
The term as I know its used in VB is shadowing methods

 

[Mike]

Using "new" does not do it. Perhaps it appears to work for you because
you also changed the return type from void to string?

 

[Jon Skeet [C# MVP]]

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

You can't. You can create a new method which hides the old method, but
anyone calling "base.Foo()" will still get the old method.

If you don't want to inherit the functionality of a class, don't
derive from it. See Liskov's Substitution Principle:
http://en.wikipedia.org/wiki/Liskov_substitution_principle


Jon

 

[Mike]

Thanks Jon, but why does the MSDN say it's possible?

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

 

[Armin Zingler]

Thanks Jon, but why does the MSDN say it's possible?

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code.

The benefit is that it only contains the public members that you want to
offer to the class user - if you want it bullet proof. In addition, the code
doesn't have to be redundant/duplicated because the new class is a
proxy/wrapper delegating all calls to an internal instance of the class that
you are currently deriving from.

A general rule: If an object reference is made available, everything can be
done to the object. If you don't want this, either don't pass the reference,
or only pass a wrapper object.

There is a function in the base class that
has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another
approach
I have overlooked?

The question is, whether it is forbidden to call the base class' function
when accessing an instance of the derived class. If it is, see above.
Otherwise, if you want an /additional/ function without parameters, you can
add an overloaded method in the derived class.

By definition, inheritance means "inherit everything". "Inherit almost
everything" is not possible.


Armin

 

[James Crosswell]

Thanks Jon, but why does the MSDN say it's possible?

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

You don't need to get rid of the old method then - simply oveload it
with your new method.

As for the philosophical discussion, if you were able to remove methods
from classes that you inherited from then .NET wouldn't be able to
support polymorphism... which is a pretty big price to pay for the
fairly rare case in which you'd want to do what you were suggesting.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

 

[Jon Skeet [C# MVP]]

Thanks Jon, but why does the MSDN say it's possible?

Basically it's badly written.

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

Create a parameterless overload of the method which then calls the one
that takes parameters.

You should ask yourself what should happen if someone calls the method
with a *different* set of parameters though. If you can't handle that,
then you shouldn't be deriving from the class.

Note that you don't always need to reimplement the same functionality
with redundant code, however - use aggregation instead of derivation,
i.e. create an instance of the other class "inside" your class, rather
than deriving from it. Sometimes that won't work, but often it will.

Jon

 

[Mike]

Thanks for the info. Yes, overloading is needed but I never want the
old method called outside my class because passing the wrong values
will cause problems. I am not really talking about removing the
function, just changing it from public to private. For now, I have
overridden the function I want to hide so it throws an exception when
called. Not pretty, but it keeps anyone from using it.

Thanks.

 

[Jon Skeet [C# MVP]]

Thanks for the info. Yes, overloading is needed but I never want the
old method called outside my class because passing the wrong values
will cause problems.

In other words, someone who has a reference to an instance of your
class and wants to treat it as an instance of the more general class
won't be able to, right?

That's breaking the substitution principle. Sometimes it's pragmatic
to do so, but it's worth being aware of it and avoiding it wherever
possible.

Jon

 

[Scott Roberts]

Also, I would tend to disagree with the "don't derive from it"

approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

As others have said, you can simply overload the method. There typically
isn't a problem with users of your class calling the base method (if they
know the parameters). If you absolutely don't want users of your class to
call the base method, override that method and have it either call the
method w/o parameters or throw an exception. You can also add the "Obsolete"
attribute to the overridden method so that users of your class will get a
compiler warning if they try to use it.

Example:

[Obsolete("Use the generic NewObject<T> call for maximum efficiency.")]
public PersistentObject NewObject(Type objectType, object aKey)

 

[Mike]

Ahh, but you don't inherit everything. If I have a constructor in my
base class that takes parameters, my derived class is not required to
have a constructor with the same parameters. The derived class can
have a constructor with no parameters while passing hard coded values
to the base constructor. That is basically what I want to do with my
member function.

 

[Armin Zingler]

Ahh, but you don't inherit everything. If I have a constructor in my
base class that takes parameters, my derived class is not required
to have a constructor with the same parameters. The derived class
can
have a constructor with no parameters while passing hard coded
values to the base constructor. That is basically what I want to do
with my member function.

No, constructors are not inherited because constructors determine how you
can create an instance of the class.


Armin