This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Why private classes, or package access modifier Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Why private classes, or package access modifier" Watch "Why private classes, or package access modifier" New topic
Author

Why private classes, or package access modifier

Costa lamona
Ranch Hand

Joined: Sep 24, 2006
Posts: 102
HI


There is things that I don't well understand in OO design, all that things can be under one subject "WHO CAN GUARANTEE ??"

- No one (including my self) will not need to extend final class.
- No one will need to "reuse" the private class outside the package.
- A method modified with package access modifier will not be used outside its package( I did not ever understand that modifier )

Thanks (THIS IS GURRANTEE)


SCJP 5
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
These modifiers allow a designer use the compiler to enforce his decisions. The designer of String had some very good reasons you should not extend String. You might really, really want to extend String, but he shut the door on you. It sounds cold, but our reasons and wishes just don't matter, his decision stands.

So you learn some workarounds. In some places you can wrap an instance of a final class or compose an instance into something bigger. In some places you can't.

How do you avoid taking options off the table that other people might need later? That's part of the art of design. There are some guidelines or rules you can use, but it's a skilled gamble a lot of times regarding what will change, what won't change, what cannot change over time.

It's also a balancing act whether you want to enforce your design or just suggest a direction for future coders. Some times, as with String, it's critical to prevent someone else from compromising the whole system, and other times you figure if somebody misuses a class the result won't work and they'll figure it out quickly enough.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
These modifiers allow a designer use the compiler to enforce his decisions.


That's one use, which is especially useful for publicized, safety critical API.

Another one is to communicate which API is used by the outside. I know that a private method cannot probably be used by others, so I can easily change it. So, while using more restrictive access modifiers makes a system less useful for the outside, it also makes the system more flexible in the inside.

Used for internal API, it can also serve as a communication tool to both the team and the compiler. For example, Eclipse flags private members as unused if they aren't used from anywhere inside the class, which makes it easy to get rid of dead code (or to find some nasty bug, if the method was supposed to be called). That's much harder to do with non-private members.

It's a balance, and one that isn't trivial to achieve. Being both a vivid user and provider of thirdparty libraries, there has been more than one occasion where I thought either

"Damn, if they just didn't make that private, my life would have been so much easier," or

"Ouch, what drove them to call *that* method? They were never supposed to do that - if we just had made it private..."


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I know that a private method cannot probably be used by others

Until you let something such as Hibernate into your system, which flagrantly breaks the rules and accesses private methods directly. Suddenly you are no longer free to refactor private methods just in case they are implicitly used by something else.

Bleh.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Costa lamona
Ranch Hand

Joined: Sep 24, 2006
Posts: 102
Thanks .............That was helpfull, Is design patterns is the appropriate place to study this things
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Frank Carver:
I know that a private method cannot probably be used by others

Until you let something such as Hibernate into your system, which flagrantly breaks the rules and accesses private methods directly.


Only if you tell it to, as far as I know?

Suddenly you are no longer free to refactor private methods just in case they are implicitly used by something else.

Bleh.


Well, not a big problem when the people who write the code are the same who write the hibernate mapping. Even less of a problem when you have tests for the mapping. Both sound like a good idea to me, anyway.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Pretty much all the Hibernate tutorials I have seen recommend a private no-args constructor solely for the use of Hibernate. Eclipse flags this as having no users, and I routinely delete such things (just as I routinely delete commented-out code).

With Hibernate in the system I catch myself thinking twice before removing unused methods which leads both to my time/concentration being wasted, and the code remaining cluttered with warnings and potentially unused code.

Do you not see this problem with your use of Hibernate?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Frankly, I didn't notice that the constructor was allowed to be private. I always make them public...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why private classes, or package access modifier
 
Similar Threads
JQPlus??
doubt in protected access specifier
what is right....and why???
Default access
Making top level class Protected