Question

Example:

class IGui{
  protected:
  virtual bool OnClicked(){return false;}
  virtual bool OnHover(){return false;}
  virtual bool OnScrollBarChange(){return false;}
  virtual bool OnTextChange(){return false;}

  ...

}

class IGuiButton: public IGui{
  protected:

  virtual bool OnClicked() = 0;
  virtual bool OnHover(){
    do stuff
    return true;}
  ...
}

The point is having a commom interface for all gui types that can be (where not all virtuals need to be overridden), and then provide a lite specialization for a button, but for the button, theres must be a override for the OnClicked..

Also, I think I should make the ones a button shouldnt override private( so use private inheritance, and use that fancy “using Base::Method;” for making the specific ones protected?

Answer 1

There are multiple sides to the question. The first one is actually a quite interesting question:

Can a derived class have a pure virtual method that is not pure in the base?

The answer is yes, it can. With the expected (if you expected this to work) semantics: a type derived from the intermediate type must implement the virtual function not to be an abstract type. This leads to a curious circumstance, where the base is not abstract, but the derived type is… which will be surprising. Just for this, I would avoid this in a design.

Should you mark as private the members that deriving types should not override?

No, there is no reason or advantage to do that. Whether the member function is public, protected or private derived classes can override it. Any code that can call the functions through the base type will still be able to call it by casting to base. This leads to another strange thing in your design. The base class is filled with protected virtual functions, which means that they are accessible only by the derived type. This does not define an interface and cannot be used as such. If a function/class takes a reference to a IGui, or a IGuiButton it will not be able to do much, as there is no public interface. That basically means that noone will be able to call any of the events –unless you are also abusing friendship to provide access to the event handler, but you should avoid it.

So what is a proper design?

There are different alternatives. I’d recommend that before creating your own square wheel you look at those wheels that were invented in the past: look at different graphical frameworks and libraries and try to understand why they decided to design them as such. Look at the differences and try to determine what advantages/disadvantages they bring and which option matches your problem. UI is a domain where there is a lot of prior art, and chances are you will not design from scratch anything better than people in the field have done in the past –you might do it, but it is much easier to fall in the same pitfalls everyone else felt before.