在类和接口中，讲讲你对封装的理解？
- 一个组件的好坏，在于该组件在于其他组件交互时，隐藏其内部数据和其他实现细节的程度，封装的程度越高，该组件越好。
- 一个好的组件，会隐藏它所有的实现细节，清晰地使API和实现隔离。
- 组件之间的沟通，仅仅通过它们的API，而不会牵涉到内部的细节。
- 合理使用 access control机制，包括public,protected,package-private,private
- 对于类和接口：能package-private,就不要 public; 能private static nested class,就不要package-private;
- 公有类的实例field不要是public
- 一个类不应该有public static final array field，也不能有返回这个field的存取器
- 合理利用java9的module system
- 遵守拇指规则：使每个类或成员尽可能的inaccessible
对于top-level的类和接口，一共有哪些access levels？
- 两种：package-private 和 public
对于成员(fields, methods, nested classes, nested interfaces)，一共有哪些access levels？
- 四种：private,package-private,protected,public
fields, methods, nested classes默认的access levels 是什么？
interface members默认的access levels 是什么？
怎么解决array field 的access levels 问题？
- make the public array private and add a public immutable list
private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
- make the array private and add a public method that returns a copy of a private array
private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() {
return PRIVATE_VALUES.clone();
}
public classes 为什么不应该暴露mutable fields？
- 破坏封装的好处
- 应该把fields设为private,然后提供公有的 get, set 方法
- 如果一个类是package-private或者private nested class，则可以暴露其fields
immutable class的好处和缺点？
- 相对于mutable classes，更容易 design, implement, 以及 use
- 不易于产生error，更加安全
- Immutable objects are simple
- Immutable objects 天生线程安全
- Immutable objects 提供failure atomicity
- 缺点是：对于每个不同的value, immutable classes需要创建一个separate object
Java平台库包含哪些immutable classes？
- String；boxed primitive classes；BigInteger 以及 BigDecimal
实现一个immutable class，应该遵守哪几点？
- 不要提供能修改对象状态的methods
- 确保你的类不能被继承
- 设置所有的 fields为final
- 设置所有的 fields为private
- 对于任何可变的组件，确保你的独有访问权限
相对于继承，为什么更赞同使用组合？
- 类的继承(一个类继承另一个类)，适合在package内使用，即由同一个程序员控制；也合适于特殊设计并且约定好文档；
- 跨package之间的继承危险性很大，它破坏了封装。
- 继承仅仅使用于"is-a"的亲属关系，同时要考虑跨package的问题
- 组合能避免上述继承的所有缺点，组合是：给你的新类一个private field,该field引用一个 instance of the existing class。
为什么相对于抽象类，优先使用接口？
- 一个类只能继承一个抽象类，却可以实现多个接口
- 已经存在的类能很容易的实现一个新的接口
- 接口天生适合定义混合体
怎么合理利用接口和抽象类？
- 提供一个 abstract skeletal implementation class to go with an interface，这是设计模式中的Template Method。
java8中接口中的默认方法的优缺点？
- 可以在已存在的接口中添加新的方法，而基本不影响程序的编译
- 添加默认方法，不能总是维护每个已经实现的不变性
- 由于默认方法的存在，一个接口的已有实现可能编译通过，但运行失败。
为什么说接口只应该用于定义types?
不要写标签类(含switch)，而去写类层次
相对于非静态成员类，为什么优先使用静态成员类？
- 非静态成员类的每个实例都有一个对其包裹类实例的引用，存储这个引用既费时间又费空间。
- 因为上述的引用，由于包裹类实例的保留，影响GC，可能造成内存泄漏。
不要在一个源文件中写多个top-level的类或者接口，否则容易形成恼人的Bug。
网友评论