0

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?

coolharsh55
  • 1,179
  • 4
  • 12
  • 27
  • 2
    Access has nothing to do with names. –  May 07 '14 at 15:23
  • package access works based on package names, right? – coolharsh55 May 07 '14 at 15:25
  • more info on similar problem: https://stackoverflow.com/questions/18494938/difference-between-protected-and-package-private-access-modifiers-in-java – coolharsh55 May 07 '14 at 15:38
  • A) Prefer composition over inheritence. You should probably have all your classes stand alone and delegate to another class rather than inheriting in any but the most trivial cases. They should all implement the same interface though. You would use this interface in methods that previously took the parent/base class as a parameter. B) Why prevent your users from extending your classes? This is the kind of decision that makes people think OO is bad--because someone arbitrarily (and usually deliberately) limited their flexibility. – Bill K May 07 '14 at 16:24
  • the inheritance is a very important part of the design because it allows creating more forms of the base class type. I cannot restrict or prevent or prefer not to have inheritance as it is not what I'm trying to design – coolharsh55 May 09 '14 at 11:49

3 Answers3

1

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.

awksp
  • 11,764
  • 4
  • 37
  • 44
1

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

Community
  • 1
  • 1
Honza Zidek
  • 9,204
  • 4
  • 72
  • 118
  • that design pattern restricts using the classes in other ways, it does not work the way I want it to work. And also, having mutual working classes is not the requirement here. – coolharsh55 May 09 '14 at 11:47
  • although initially skeptical, I've managed to get the solution using the friend function. Thank you :) – coolharsh55 May 13 '14 at 18:22
  • It was my pleasure :) To help you as well as to learn this nice trick in Java :) – Honza Zidek May 13 '14 at 18:26
0

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.

PDStat
  • 5,513
  • 10
  • 51
  • 86