CODEWITHSUNDEEP
javaclassoopdesign-patternspackage
coolharsh55
coolharsh55

Reputation: 1199

design of Java classes and packages

I have a context class -> prototype.context -> which apps can create objects of, but cannot extend. The system developer can however extend the classes to more types. The package of system classes would be prototype.system and prototype.dbengine . These classes should have full access to context objects, but other classes should not.

If I keep the fields in context class as package access, these classes cannot access it, because they are from a different package. So how should I name the packages so that the classes are available to other developers, and also have full access to system classes?

Upvotes: 0

Views: 103

Answers (3)

Honza Zidek
Honza Zidek

Reputation: 20465

What you want is actually a simulation of the C++ friend-class feature. A nice trick is described here: https://stackoverflow.com/a/18634125/2886891

Upvotes: 1

awksp
awksp

Reputation: 11877

If you absolutely have to use package-private access and/or cannot use protected, then really the only option you have short of using public is to stick everything into the same package.

This is because in Java, "subpackages" don't really exist -- for example, java.util is an entirely different package than java.util.concurrent; thus, whether java.util.concurrent is called that or java.concurrent doesn't make a difference from the standpoint of access scope. In either case, classes in java.util.concurrent won't be able to access package-private members from java.util. The naming is only for convenience, and doesn't indicate any actual hierarchy.

Thus, no matter how you name your packages, you won't be able to access package-private members from another package.

Upvotes: 1

PDStat
PDStat

Reputation: 5855

Have the system and dbengine classes extend the necessary classes in context and set fields/methods that the system and dbengine classes need to protected.

Upvotes: 0

Related Questions