4

Neither g++ nor javac emit warnings when the parameters to non-private methods are of private types (e.g., private nested classes). Such methods cannot be used by clients, but they can appear as part of a class's public API.

In C++, putting such methods into the public section of a class Foo, for example, could allow other classes to access these methods without explicitly being listed as friends inside class Foo (so long as they can access the private types used as parameters).

But in general, would it be bad style to not explicitly make such methods private, or can this just be ignored? (since clients can't use it anyway, what's the big deal)

wattostudios
  • 8,666
  • 13
  • 43
  • 57
ManRow
  • 1,563
  • 4
  • 21
  • 40

2 Answers2

4

This is allowed and might be required.

While you might not be allowed to create a variable of the private type; it might be return by a function. This would allow data to be transfered around the system without being persistent in parts of the system that have no reason to hold a reference to it.

This idiom is not common but is allowed.

Brett Walker
  • 3,566
  • 1
  • 18
  • 36
  • There is definitely a case to be made for returning private types as generic Object instances and then passing those instances around through the system. However, at least in Java, a method requiring such a type as a parameter cannot actually be called by external code (except possibly through Reflection). Instead the method needs to accept its parameter as an Object, and then internally cast to the actual type. – aroth Jul 31 '11 at 09:40
  • I just tried it: "w.foo( w.qux( ) );" where qux() returns a private inner class of w. This is called from another class. It works, somewhat to my surprise. Using Java 6. – S.L. Barth is on codidact.com Jul 31 '11 at 09:54
  • Ah, I see what you did there. Clever. But it won't work if you do like `Object qux = w.qux();` followed later by `w.foo(qux);`. So in essence you cannot hold onto the result of `w.qux()` to reuse later, you have to call it whenever you want to use it. – aroth Jul 31 '11 at 10:39
  • Thanks for the compliment, @aroth. I agree with your comment; you have to call `w.qux()` whenever you want to use it. This makes the "Replace Query with Temp" refactoring unusable; which is why I consider this bad style. Like I said, I was a little surprised that it worked at all. – S.L. Barth is on codidact.com Aug 01 '11 at 07:31
3

Stylistically I have to imagine that having these methods as part of the public API would be considered bad style. Do you really want to see methods that you cannot actually call popping up in your IDE's auto-complete dialog when working with a library? I don't think so.

As for why there are no compiler warnings, in most (perhaps all?) object-oriented languages (and certainly in Java) user-defined Object types are simply passed to methods using pointers. So no knowledge about the actual type is needed in order to pass a reference to one as a function parameter, just knowledge about pointers. And as far as the compiler cares, everyone has knowledge about how to create a pointer, so it has no basis for saying "you can't actually call this externally". At the very least you could call it with a value of null.

aroth
  • 54,026
  • 20
  • 135
  • 176
  • The lack of warnings, at least for C++, is because there is no way for the compiler to tell if a type is strictly private; to warn at all, it would have to rely on a very smart linker (that makes a lot of assumptions). – Alex Churchill Jul 31 '11 at 09:37
  • +1 Even those this idiom has valid uses, it's probably bad style unless specifically intended for such – ManRow Jul 31 '11 at 09:58