公共访问修饰符是否会限制更改代码的灵活性?如果是这样,请举例说明

时间:2009-10-28 10:34:05

标签: java

公共访问修饰符是否会限制更改代码的灵活性?如果是这样,请提供一些示例..

4 个答案:

答案 0 :(得分:0)

如果您可以访问源代码,修饰符不能限制您的灵活性,因为您可以更改修饰符。

如果您无法访问源代码,则无法扩展或覆盖标记为final的任何类或方法,如果您的类位于原始包之外,则无法访问任何标记为private的方法,或默认(不使用修饰符),如果你的类在原始包之外,而不是扩展原始类

答案 1 :(得分:0)

来自谷歌搜索你的问题的前两个答案几乎说明了一切

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

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

现在我的观点:我认为添加一个好的做法是默认启动私有,并且如果类被扩展则升级到受保护是很有价值的。当您想要授予对来自不同包的类的访问权时,请公开。

但是,没有什么可以阻止你向所有成员公开声明。这恰恰相反,增加了你的灵活性;需要注意的是你牺牲了安全感。例如,如果第三方在同一个类路径中将您自己的类与您的类一起加载,并且您的类中的所有成员都是公共的,则它们可以轻松地修改类的状态。许多其他例子。

因此,除非您完全不关心安全性,否则在需要时升级修饰符。

答案 2 :(得分:0)

是的,公共访问修饰符绝对限制了在OOP中使用encapuslation功能更改代码的灵活性。让我试着用一个例子来解释。如您所知,可以从任何类访问公共访问修饰符的范围,而不管它们属于哪个包。这导致了面向对象的糟糕设计。

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
   }
}

上面的例子是Bad OO设计,应该避免通过为实例变量提供私有或受保护的访问修饰符的良好实践,并通过Java bean兼容的访问器方法进行访问采取形式

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

在返回或修改值之前提供检查和/或验证的位置。

希望这有助于!!

答案 3 :(得分:0)

毫无疑问,当你的OO设计规定它应该有更多限制访问时,宣布某个类或成员是公开的是一个坏主意。

但这会限制你的灵活性吗?我会说是的。

由于这是作业,我不打算为你解释答案......或者给你一些可以剪切和粘贴的例子。但是考虑一下Java规则来覆盖子类中的成员。具体来说,请考虑在更改方法访问权限方面您可以做什么和不可以做什么。