1

I am using bada and refer to the tutorial here, which begins:

    class MainForm:
       public Osp::Ui::Controls::Form,
       public Osp::Ui::IActionEventListener,
       public Osp::Ui::ITouchEventListener
    {

I am running code where I recently removed the public specifier to cut down on my public API. You'll see that the functions implementing those interfaces where all also declared publicly, for which I saw no need and made private. I would do this without hesitation when implementing my own interfaces when those interfaces may provide more access than I would wish regular clients of my concrete class to receive.

What is the reason for making them public, what am I missing?

I guess it is advocated to aid extensibility, but for a dev making apps not libraries I would challenge this wisdom.

John
  • 6,433
  • 7
  • 47
  • 82
  • I found the first answer by Disch, at http://www.cplusplus.com/forum/beginner/12899/ made a lot of sense. – John Jan 21 '12 at 10:40
  • 1
    I don't see anything there that "advocates" public inheritance; I would guess that the author just didn't think about whether or not they needed to be public. It's certainly a good idea to make them private (along with the overrides of the functions they define), if they're only intended to be used internally. – Mike Seymour Jan 21 '12 at 11:17
  • @Mike Good point, I was being a little overzealous with my housekeeping and should have reworded "advocated" to "used freely", I should have read up more but thought it the perfect topic for SO. – John Jan 21 '12 at 11:35

2 Answers2

4

If Form, IActionEventListener and ITouchEventListener already support many usable methods, in most cases why hide them? On the contrary: if you hide them and in the future someone will need them, it will be harder for you to maintain the class because you'll need to provide them again.

If you need to hide the parent's methods, there's another way to do this: instead of inheriting, enclose the "parent" as a field in your new class.

In some languages such as C#, public inheritance is the only option.

Ilya Kogan
  • 21,995
  • 15
  • 85
  • 141
  • I need to implement the interfaces so I can pass the whole object to classes/functions requiring those interfaces. Interestingly they still accept it even if it privately implements those interfaces. I got this composition not extension argument before here, but this time I feel it an unworkable solution. – John Jan 21 '12 at 10:19
  • Is it wrong that functions requiring those interfaces accept objects of classes which implement them privately? BTW Only Form supports many usable methods. The others offer very restricted extenstion. – John Jan 21 '12 at 10:25
  • @john there is no problem to implement "interface" privately simply because the concept of interface does not exist in C++. If you want to use these **base classes** as it they were real interfaces you have to implement them publicly. – log0 Jan 21 '12 at 10:41
  • @Ugo I can use them as _real_ interfaces within the class though, see my first comment on own question. – John Jan 21 '12 at 10:55
  • The `Listener` interfaces define functions that are only intended to be called by whatever you register the `Listener` with, not by general users of the class; therefore, it would be better to hide them. Private inheritance is usually more convenient than containment, when the "parent" is an abstract class. – Mike Seymour Jan 21 '12 at 11:24
0

For me private inheritance of "interfaces" is a non sens.

The interface of an object is its set of public methods. As llya said, if you want to use the functionalities provided by a class internally, use object composition. If you want to provide a subset of the interface, then either compose or simply declare a more restrictive interface.

If the "interface" and the functions taking object from this interface are in a third party library then its means that the developers wanted to force you to implement every methods, so you have to provide them.

log0
  • 10,489
  • 4
  • 28
  • 62
  • On second thoughts that doesn't seem so unworkable. Impractical though to have to declare separate classes to implement those interfaces and gain access to the important data in `Form`. Now if I had understood that `private` inheritence still permits members to pass itself of as an object completely implementing that interface and all its associated `public` members I might have answered my own question. – John Jan 21 '12 at 10:33
  • @John I think you misunderstood the concept. Real interfaces dos not exist in C++, so this "I" in front of the name of these base classes is just a way to tell you to provide public implementation of any public methods in Isomething. – log0 Jan 21 '12 at 10:48
  • saying real interfaces do not exist is a bit like saying threading doesn't exist. Extensions exist which people widely use to provide the equivalent functionality. I challenge you to define how my interface is any less _real_ than the concept you define. – John Jan 21 '12 at 10:59
  • @John it just cannot be an interface if you don't inherit publicly. But you can do something else if you want :) .... take a look at how interfaces work in C# for instance.... or actually any other language providing interface. – log0 Jan 21 '12 at 11:13
  • @John something else not supported in c++. In c# if you pass an interface to a function any method not in the interface is discarded, there is no easy way to do this in C++. – log0 Jan 21 '12 at 11:15
  • 1
    Private inheritance makes perfect sense in cases like this, where the class needs to register itself, via an abstract interface, with an "observer"-style mechanism. Only the class member that performs that registration needs to know about the inheritance; therefore, there's no need for it to be public. – Mike Seymour Jan 21 '12 at 11:26
  • @Mike Seymou if one day you have to pass your Form to a function taking a `Osp::Ui::IActionEventListener`, it won't work. – log0 Jan 21 '12 at 11:43
  • @Ugo: True, but you wouldn't have to do that, any more than you would have to pass it to a function taking any interface that it doesn't implement at all. It's implementing the interface so it can register *itself* with something that requires that interface. There's no reason for anything else to use that inheritance relationship; and no reason to make it public just in case someone decides they want to abuse it. – Mike Seymour Jan 21 '12 at 11:49