2

After 1000s of privates in private it occurred to me that it may not be needed

public class Outer {

    private static class Inner { // you may drop static
        private void innerMethod() {}
    }
}

Is there any case that dropping private from innerMethod() would make a difference in encapsulation (or use, by Outer for instance) ? Think also reflection
If not is it recommended to drop it or keep it vis a vis coding style ?

I'd say no and drop but not sure really.

EDIT : just realized that the way I do it is certainly wrong - at least for Inner's fields - declaring those fields private and then using them in the outer class - as this generates ("synthetic") accessors in the bytecode - which is at least bloat. Great - so now I am even more interested to have an account on the security implications of declaring those (Inner's fields, methods used in Outer) package private (or public as @JBNizet says in the comments)

Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
  • Even if it doesn't make a difference, I usually make the methods that are intended to be called from the enclosing class public, and the other privates. Not sure if it's a standard practice though. – JB Nizet Jul 21 '13 at 13:18
  • @JBNizet: `Outer` has access to everything - no ? I would make them and private anyway - one modifier less – Mr_and_Mrs_D Jul 21 '13 at 13:20
  • 1
    Yes, hence the part "even if it doesn't make a difference". – JB Nizet Jul 21 '13 at 13:23
  • @JBNizet: why not package private ? why public ? – Mr_and_Mrs_D Jul 21 '13 at 16:08
  • 2
    Good question. Probably because if I refactored the inner class to a top-level classes, these methods would, most of the time, become public and not package-private. And also because I've always found the lack of a keyword for package-private a mistake: you never know if the developer intended to make it package-private, or if he was too lazy to even think about accessibility and neglected to specify a keyword. – JB Nizet Jul 21 '13 at 16:13
  • see also : http://stackoverflow.com/questions/219574/large-inner-classes-and-private-variables?rq=1 – Mr_and_Mrs_D Oct 30 '13 at 18:07

1 Answers1

5

The answer depends on how you currently use inner classes.

My philosophy for inner classes is to reduce the burden of refactoring. I maintain encapsulation of inner classes: private methods and fields of the inner class are not accessed from the outer class even though they can be. The point of inner classes, then, is to reduce its scope to only the containing class. That way, if later an inner class can be reused elsewhere, it requires almost no work (and a trivial amount of work for non-static inner classes) to move it into its own file.

Whether or not the above is your style will affect the following reasons for dropping or keeping the private around methods/fields.

The reasons for dropping private are:

  • The outer class has access to private members and methods of inner classes, meaning such fields/methods aren't really encapsulated
  • Less to type

The reasons against dropping private are:

  • Making the methods of an inner classes private serves as documentation: the outer class shouldn't use these methods
  • If private is kept, it makes it much easier to promote an inner class to its own file
  • If private is dropped, there are two styles for public inner classes and private inner classes: more for the programmer to think about
  • If private is dropped and the inner class was made public, suddenly everyone who has access to the outer file has access to the inner class's private data

Given the above style, I think the case against dropping is stronger.

kuporific
  • 10,053
  • 3
  • 42
  • 46
  • Valid points - _what worries me most though is what (if anything) could be done from outside_. Also "Making the methods of an inner classes private serves as documentation: outer class shouldn't use these methods" --> the way I do it it uses them - your way, if Inner is made outer the methods used by the Outer would suddenly become package-private anyway (not "accessible to everyone" except if you made them public). I think you need to sum your points up a bit 2 and 4 is the same. – Mr_and_Mrs_D Jul 21 '13 at 14:18
  • @Mr_and_Mrs_D Also good point; I've made some edits (and will continue to do so). In my style, I would not call the `private` methods of an inner class. My main argument is that omitting `private` (or calling `private` methods) makes refactoring harder, and I'll try to make that more clear. – kuporific Jul 21 '13 at 14:36
  • Hmm - needs rethinking - please consider the security implications - maybe this is the real reason and not refactoring ? see : http://stackoverflow.com/a/5559064/281545. I mean the method is not private anymore - it is package private – Mr_and_Mrs_D Oct 17 '13 at 15:55