Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why private classes, or package access modifier

 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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..."
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks .............That was helpfull, Is design patterns is the appropriate place to study this things
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Frankly, I didn't notice that the constructor was allowed to be private. I always make them public...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic