This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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 )
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
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
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.
Thanks .............That was helpfull, Is design patterns is the appropriate place to study this things
Joined: Jul 11, 2001
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.
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.
Joined: Jan 07, 1999
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?
Joined: Jul 11, 2001
Frankly, I didn't notice that the constructor was allowed to be private. I always make them public...