1)& 2) Actually, I was refering to the same 'helper' classes - perhaps I could have been more clear here. I was simply refering to any class that you may define to be used by another class (ergo, a 'helper' class - not a term I expect to be adopted anytime soon but it seemed like a good idea at the time). Now, pretend that you have a publically available class in a package that you want and expect folks to instantiate and use. Now, consider that this class uses a little class you wrote called "DeleteAll Directories.java". Chances are you don't want anyone to access or use this class in any way. The most effective way of hiding it from everything else (i.e. other classes in the package, etc) is to make it a private inner class within the class that is designed to use this Delete... class. Now this Delete.. classes' functioality is strictly controlled by its enclosing class and there's no risk of another class using Delete... to wipe out you file system.
3) Breaking code (in an OO sense - again not a technical term) refers to the effect of causing class X to fail by altering class Y because class Y relied on some functionality of X. This can be minimized by only allowing the two classes to interact through clearly defined public methods. That way, you can change the functionality behind the public method and the calling class is still happy (this is the concept behind deprecated classes in that Java api). Now what if the calling class sneaks in and starts using some little method buried in the class (that you accidenetally declared as public)? Later you might alter the classes functionality but, like a responsible programmer, make sure that the public methods still act like they are supposed to so everyone is happy. But, when you altered the functionality, you renamed or deleted or whatever the supposedly hidden little method. Now, the class that snuck in and started using this method will break. It's like a fan. You build a fan so that it is perfectly safe - and you're instruction manual tell folks how to use the fan in a safe manner (this is like the public methods). But someone (for whatever reason) figures out that you can stick your finger in a small hole where the electical chord comes out and ouch! (this is a loop hole
you should have sealed). Now they sue you because you should have designed the fan to prevent this.
As I mentioned before, this relates to Object coupling, which can be an interesting topic when you designing classes for re-use, etc. I hope this helps.
Sean