I wonder if it's okay (not considered bad practice) to have public members in package private class. I tend to add public keyword to members of my default visibility classes to indicate that such members are part of the classes API.
I do it only for readability, since in this case public members have essentially the same visibility as members without any access modifiers (i.e. package visibility). Is that correct?
Example:
class ModuleImplementationClass {
private int fieldA;
private String fieldB;
private void someClassInternalMethod() {
// impl
}
public int doSth() {
// method that will be called by other classes in the package
}
}
I do it only for readability, since in this case public members have essentially the same visibility as members without any access modifiers (i.e. package visibility). Is that correct?
Well that depends. Not if you're overriding existing methods (e.g. toString()) or implementing an interface.
If you don't want the method to be used from outside the package, make it package private. If you're happy for it to be used from anywhere, make it public. Or another way to think about it: design your method access so that if someone changed just the class access to make it a public class, you wouldn't want to change the method access too.
Related
I wonder if it's okay (not considered bad practice) to have public members in package private class. I tend to add public keyword to members of my default visibility classes to indicate that such members are part of the classes API.
I do it only for readability, since in this case public members have essentially the same visibility as members without any access modifiers (i.e. package visibility). Is that correct?
Example:
class ModuleImplementationClass {
private int fieldA;
private String fieldB;
private void someClassInternalMethod() {
// impl
}
public int doSth() {
// method that will be called by other classes in the package
}
}
I do it only for readability, since in this case public members have essentially the same visibility as members without any access modifiers (i.e. package visibility). Is that correct?
Well that depends. Not if you're overriding existing methods (e.g. toString()) or implementing an interface.
If you don't want the method to be used from outside the package, make it package private. If you're happy for it to be used from anywhere, make it public. Or another way to think about it: design your method access so that if someone changed just the class access to make it a public class, you wouldn't want to change the method access too.
public class A
{
public static void main(String args[])
{
}
}
class B
{
private static void call
{
int x=9;
String name ="hello";
}
}
Can anyone please tell me how to access class B private method fields in class A and print them in class A.
Thank u..
You can access private fields and methods in other classes, but the whole point is that you're not supposed to. They're private.
So the correct thing to do is make them available to other classes by making them public. In the case of fields (rather than methods), you might do that with accessor methods.
But, if you really had to access private fields or methods, you can do it via java.lang.reflect.
// Calling the static `call` method of `B` even though it's private:
Method m = B.class.getMethod("call");
m.setAccessible(true);
m.invoke(null);
But again, you shouldn't do this without a really good reason. Fix the design instead.
We Should Not try to access directly the private members of a class in another class. This will altogether violate the rule of Access Modifiers. Moreover if you really want to access, you can make use of Reflection API provided.
Generally, in order to get the private class variables, you can create public setters and getters in order to access then outside that class.
By design you cannot. Revise the class so the method you want to call is visible to A.
That said, you can use reflection to access methods, fields etc inside B, but you cannot easily just do it with "B.call()" which most likely is what you would like to do.
I have seen users in SO saying that protected fields are bad, because it can introduce problems as the code grows. Please refer to the following code.
public class Car {
private String modelName;
private int yearReleased;
//getters and setters
}
If the Car class is extended by a class named ToyotaCar
public class ToyotaCar extends Car{
// Toyota specific stuff
}
I want my ToyotaCar object to have a modelName and yearReleased fields. And that is why I decided to extend from Car class. But private members are not inherited by the subclass (even though I could access those fields using a public getter and setter). Now my confusion is whether I should make the fileds in the Car class to protected instead of private. But people say that introduces problems.
Does it mean no matter what class you write always, make the fields private?
If so on what instances the protected keyword is used? is it only for methods which we are planning to use in our subclasses?
You nailed it yourself: a good practice is to make everything 'private' by default. Then, your specific design may require for example to be able to use some attributes or (preferably) some methods inside a subclass. In that situation, you'll need to move them toward 'protected' - but only in that situation.
Remember that using the accessors (getters & setters) is perfectly ok, and can be done without breaking encapsulation.
If there is a strict urgency(due to a specific design/pattern) of changing the fields from the subclass, then you should go declaring your class fields as protected.
If not so, then generally the better approach is to perform the same
using a public/protected member method in the parent class updating
those private fields in the parent class and then, calling that
public/protected member method from your child class' object.
This way you can achieve the implementation by calling parent's class member method from the child class' object to update those parent class' private fields.
Protected keyword for declaring the variables is used to make those instance variables visible for all the other classes in the same package and also the class[sub class] which will extends the super class involving those protected variables.
of course,you can declare the variables with private or protected modifiers.But when you declare the variable as private then you can able to hide variable such that other classes are not able to access it directly and on the other hand if you declare the variable with the protected then you are making the variable to access it directly without using any getter methods,which is against to OOP principle.
So from my opinion, Since Car is the super class of all the other class like ToyotaCar and so on.Declare the variables in your super class as private and in sub class make use of getter and setters methods to read and write depending upon your need. By doing that you are adhere to OOP principles.
Hope this helps.
Thanks
I know that subclass has no access to private field other than with public setter/getter of super-class. I do not have any experience with object-oriented languages so far. Should I make all fields private and just use public method to access them in sub-classes, or make them protected and use the freely in subclasses and package?
Make them protected. This is the sole purpose why this keyword exists!
In OOP there is a feature encapsulation and encapsulation strongly suggest us to hide data from the outer world. And you can hide data by making field/property/variable private.
And for accessing the private variable use some public getter method.
it depends on your needs. If you need access to subclass as well as the same package, make it protected.
Here are the general rules:
private: class access only.
protected: package access and also derived classes.
default: same package only.
public: anyone can access it.
A subclass does not inherit the private members of its parent class. However, if the superclass has public or protected methods for accessing its private fields, these can also be used by the subclass.
A nested class has access to all the private members of its enclosing
class—both fields and methods. Therefore, a public or protected nested
class inherited by a subclass has indirect access to all of the
private members of the superclass.
See the Java Tutorial
I have a private inner class implementing a private inner interface. I usually omit the private modifier inside private inner classes to make the code cleaner. Unfortunately, in this situation I get "can't reduce visibility error", even though I'm not actually reducing visibility.
public class Foo {
private interface IBar{
void foo();
}
private static class Bar implements IBar{
#Override
public void foo() { // Must be public :(
}
}
}
I presume there is no way to work around this?
All methods of an interface are public and abstract. That is the rule.
Only making them public makes sense because they are to be implemented by implementing classes which may be from different packages.
and even if it is an inner interface, it still is interface So rules do not change.
All methods on an interface must be declared public. Not specifying an access modifier on the foo method causes it to be assigned package protected access by default. Since package protected is less accessible than public the code is reducing the accessibility of the foo method.
All methods of an inteface are public and abstract. If you don't define any modifier then by default it is public and abstract.
The general rule of override is you can't reduce the method visibility. In side a class if you don't define any modifier then by default it will be default and default is less visible then public. So here it must be public