Will public access modifiers limits flexibility in changing code?If so give some examples..

Question

Will public access modifiers limits flexibility in changing code?If so give some examples..

Answer 1

If you can access the source code the modifiers can not limit your flexibility because you can change the modifiers.

If you can not access the source code you cannot extend or override any class or method marked final, you cannot access any method marked private, or default (without modifier) if your class is outside of the origin package, or protected if your class is outside of the origin package and not extends the original class

Answer 2

The first two answers from googling your question pretty much say it all

java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

www.java-samples.com/showtutorial.php?tutorialid=655

Now my perspective: I guess it is valuable to add that it is good practice to start with private by default and escalate to protected when if the class is extended; and public when you want to grant access to classes from different packages.

However, there is nothing stopping you from giving all members a public declaration. This does quite the opposite and increases your flexibility; with the caveat being that you sacrifice security. For example, if a 3rd party loads their own classes together with yours in the same classpath, and all the members in your class are public, they are easily able to modify the state of your classes. Numerous other examples.

So, unless you are absolutely unconcerned about security, escalate modifiers as and when needed.

Answer 3

Yes definitely public access modifiers limits flexibility in changing code with encapuslation feature in OOP . let me try explaining with an example . As you know the scope of the public access modifier can be accessed from any of the classes regardless of the package which they belong to . which results in Bad Object oriented design.

package com.app.access;

public class  Car{
  public int wheels;
  public int lights;
  //  Method for how wheels rotate
 // Method for how lights on
}

public class TestCar{
  public static void main(String [] args) {

      Car c = new Car();
      c.wheels = -5; // Legal but bad 00 because we know it cannot have a negative value
   }
}

Above example is Bad OO design which should be avoid by making a good practice providing private or protected access modifier to the instance variable and access through the Java bean compliant accessor methods take the form

get<propertyName> or for booleans is<propertyName> and set<propertyName>

provide a place to check and/or validate before returning or modifying a value.

Hope this Helps !!

Answer 4

There is no doubt that it is a bad idea to declare some class or member to be public when your OO design dictates that it should have more restricted access.

But does this limit your flexibility? I'd say yes.

Since this is homework, I'm not going to spell out the answer for you ... or give you examples that you can cut and paste. But consider Java's rules for overriding members in a subclass. Specifically, consider what you can and cannot do in terms of changing the access on the method.