• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Private Inner Class - TIJ

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thinking in Java - Bruce Eckel p370

Thus, the private inner class provides a way for the class designer to completely prevent any type-coding dependencies and to completely hide details about implementation. In addition, extension of an interface is useless from the client programmer�s perspective since the client programmer cannot access any additional methods that aren�t part of the public interface class.


Can anyone pls. explain the concept behind these sentences? Any simpler examples?
------------------
~James Baud
Talk, does not cook rice. - Chinese Proverb
[This message has been edited by James Baud (edited January 15, 2001).]
 
author
Posts: 621
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Thus, the private inner class provides a way for the class designer to completely prevent any type-coding dependencies and to completely hide details about implementation."
I believe that this is refering to the object-oriented concepts of code hiding and object coupling. If you create an object that has a few public interfaces that other objects can call, you really only want them to be able to see these methods and not the inner workings of the class. Like driving a car - most people know about the gas peddle and the steering wheel but really don't need to know about the mechanics of how they work in order to drive. Now, if you object requires some helper classes, you can define them as private inner classes to prevent anyone form being able to extend, call methods on, etc. these helper classes. This helps contain the functionality of your object such that it's inner mechanicas are completely hidden. As well, since no one can use these inner classes, you don't have to worry about someone creating new objects that are highly coupled with your object. You only want other objects to relate to your object via it's public interfaces and if someone extends one of you helper classes and then you go and change the functionality of your object, you risk breaking the code that has subversively latched on to your object (because it is now highly coupled). I hope this helps clear things up a bit.
Sean
 
James Baud
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your response Sean. They come as bits and pieces, like in jigsaw puzzle, slowly revealing the whole picture...
Begging your indulgence w/ a few more questions please :
1) "If your object requires some helper classes, you can define them as private inner classes to prevent anyone form being able to extend,.." - Am I right in presuming here that this helper class is not the same as the helper class being denoted in "If someone extends one of you helper classes.."?
2) How do you then decide when to define an inner class as opposed to an ordinary (top-level? class that has public accessor methods to access private members?
3) I've encountered the phrase breaking code somewhere but did not quite get what it meant. Can you explain a little more?
------------------
~James Baud
Talk, does not cook rice. - Chinese Proverb
 
Sean MacLean
author
Posts: 621
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
James Baud
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sean - Thanks for your replies, they did HELP.
------------------
~James Baud
Talk, does not cook rice. - Chinese Proverb
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,
Take a look at the source to the java.util collection classes. For example, look at HashMap.java to see how HashMap.iterator() is implemented. HashMap.iterator() returns an instance of a HashMap.HashIterator, which is a private inner class that implements the Iterator interface. You wouldn't know that unless you looked at the source, because the signature of iterator() is that it returns some object that implements Iterator, but you don't care about the true class of the object. That's the beauty of interfaces for you! The details of the implementation of HashIterator are completely hidden from the user of the HashMap, who only needs to know that whatever is being returned from HashMap.iterator() fulfills the contract of an Iterator.
reply
    Bookmark Topic Watch Topic
  • New Topic