Overloading function access in derived classes?

[Jon2029]

Is there any way to overload the access type of a member function in a derived class such that is can not be accessed by a pointer to the base class other than merely overloading the function with nothing in it?

For instance,

class base
{
public int getNumber();
}

class derived : public base
{
private int getNumber();
}

such that

base* mDerived = new derived();
mDerived->getNumber();

would produce some kind of compiler error

The only ways I can think to get this effect would be to overload the function with nothing in the body, but this is bad form. Is there a way to make a compiler error occur when the overloaded function is called?

[simo110]

What is your meaning?

base* mDerived = new derived();
mDerived->getNumber();

mDerived->getNumber();
It can only read the member function which lied in base!

Last,overload is the concept in the same field!

[Zaita]

I think you need to look at the protected access specifier.

Also, that isn't technically an overload because the base function isn't declared as virtual

[Jon2029]

Ok, so here's more of what I want to do. I have a big class with many member functions. I am using that class as a part of another object, and I want that object to be able to send an object that controls the instance of the big class.

The controller would be a pointer to the controlled object (or some cast of it) that would make some functions, such as disconnect() in this case, unaccessable through this new pointer. In this way, the user can call all of the methods that do not hinder the object from working as intended inside the bigger class.

so basically, it's like this:

class bigObject()
{
getSomething();
setSomething();
disconnect();
...
}

class bigObjectController : public bigObject
{
some way to hinder the user from calling disconnect()
}


class otherThing()
{
bigObject* instance;
bigObjectController getController()
{
return dynamic_cast <bigObjectController*> instance;
}
}

[simo110]

It looks like your design has some problem!
You should fix your design!

[Duthomhas]

You can increase, but not decrease, visibility.

If you want a derived class to disallow calling an ancestor method, you can always override it and throw an exception or something.

But doing that is indicative of a design flaw...

Are you trying to implement the Model-View-Controller pattern?

[Jeff HS]

If you dont want derived classes to have access to that function just make it private in the base class or make it virtual and override it in the derived class and when someone uses it you warn them saying its not implemented(by throwing exceptions or w/e) but yeah thats really ugly.
You could use a proxy class too. Using your code example:

class bigObject()
{
public:
   Something getSomething();
   void setSomething();
   void disconnect();
//...
}

class BigObject_Proxy{
private:
   bigObject m_bigObject; //i prefer a pointer correctly allocated.
public:
   Something getSomething(){return m_bigObject.getSomething();}
   void setSomething(){m_bigObject.setSomething();}
}

class bigObjectController : public BigObject_Proxy
{
//no disconnect()
}

edit: added code tags

Jeff

[Jon2029]

Ok, sounds good. I suppose I will go with making the proxy object. Really, I was just looking for an easier way to, instead of defining every function the user CAN use, to instead define what they can not use, but perhaps that's me just being lazy. Either way, the derived class will always be able to be deleted, which is something that should not happen, so a controller object with a pointer pointing to bigObject seems like the only way to go.

Sounds good, thanks everyone

[Zaita]

Jon2029: as others have mentioned. It seems like you have a design flaw in your code somewhere.

Perhaps you want to extend the level of your Parent-Child relationship to include more than just 2 levels. So you have Class->Inhert->Inhert->etc.

This will allow you to better define the relationship.

Proxy objects are really a bad idea. They create ALOT of added maintenance and headaches. Trust me on this, I have worked on a large system where everything was proxyed and the task of doing work on this was very difficult.

[Jeff HS]

I disagree with proxy class being a bad idea.
Using _only_ proxy class on a project is though.
Use only when\if necessary.

[Zaita]

Proxy class is usually indicative of bad design. You need to re-think the solution to your problem first IMO.

In this case, he is trying to create multiple different children that each inherit from the parent differently. He needs to expand his Family-Tree and redesign it to better suit the problem.

[Jeff HS]

Proxy classes (AKA handles) is far from being a indicative of a bad design. again to only use proxy objects on a project is, if all he wants is a way to use selected functions he can just make handle to that object he could even do it in a more polymorphic\generic way with templates.

[satm2008]

The above proxy is a bad idea.
The proxy needs to be modified (added/deleted) every time something added/deleted in BigObject class and a base class pointer to bigObject would not be able to point (in terms of polymorphism) to bigObjectController as bigObjectController inherits from BigObjectProxy which is in fact a composite class of BigObject.

Hmmm it is not a recommended design.

Check it out. Good luck :)