i'm getting confused on how to approach the access modifiers of subclasses. Why isn't there an access modifier that only allows the current class and it's subclasses access to the member? It seems many people think that protected does this, but protected also allows access by other classes in the same package. contrived example: Say there is a base class called Vehicle. It has a member variable called numWheels. Subclasses of Vehicle should be able to set the number of wheels, but other classes should be able to get the number of wheels, but not set it. How should this be handled?
In example 1, public access to numWheels obviously isn't correct. However, default package access to numWheels would allow any other class in the package to change the number of wheels that Car has. Same with protected. This means that if class Road (or Bicycle or Moped, etc) was in the same package, it could change the number of wheels on a car! The next thought is to have numWheels marked private, and then make a protected setNumWheels(int) method. But, this puts the code at same logical point as before: classes within the same package can call the protected methods. so, what is the solution? how do we allow only the subclasses access to a member variable or function? hopefully this is clear and i'm not missing something obvious here... thanks, Jon
use the [CODE] tags - it makes it much easier for people to help you.
I don't know of any access level that allows what you are asking. My code uses protected and a "gentleman's agreement" to not touch the eprotected members of other classes' code in the same package. This doesn't help if the code you dealing with isn't a gentleman, however.... Perhaps someone can explain the benefits of package-access? It seems kind of silly to me, and seems as though it can cause some problems.
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
By the way, in your example, I would make numWheels private and write the accessor methods. You of course would have to change the subclass constructor, but this is just good OO practice. (Even in the class that declares the variable, I use the get and set methods to modify the value. This was any refactoring is easily accomplished.)
Perhaps someone can explain the benefits of package-access? It seems kind of silly to me, and seems as though it can cause some problems. I've always had the same feelings on the subject. I never use package-private access and rarely (if ever) use protected access for instance variables in favor of protected mutators instead. As for the problem, you can make all of your subclasses inner classes of the super and then make all your instance variables private. Of course that sort of architechture usually requires factory methods to instantiate the correct subclass.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Morris was wonderfully correct! Now my doubt is: Can we have a subclass as an inner class of the parent class?
Ahetuki, the Constant.
Joined: Jan 30, 2002
Can we have a subclass as an inner class of the parent class? Sure thing. The real problem is getting an instance of the inner class from outside. That's why I said you usually use factory methods in such an architechture. Here's an example:
[ May 30, 2003: Message edited by: Michael Morris ]
Joined: May 29, 2003
That was kool, Michael! Instead of using the Factory pattern we could have used the State pattern too. Am I correct? :roll:
Joined: Jan 30, 2002
Instead of using the Factory pattern we could have used the State pattern too. Am I correct? You could use a State pattern but it is a Behavioral Pattern instead of a Creational Pattern. If you have a single object that needs to change subclasses dynamically then the State Pattern would be the choice and you could use the inner subclass technique above.