摘要：不可变类是指其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例的时候就提供，并在对象的整个生命周期（lifetime）内固定不变。Java 平台类库中包含许多不可变的类，其中有 String、基本类型的包装类、BigInteger 和 BigDecimal。存在不可变的类有许多理由：不 阅读全文

摘要：对于公有类（类可以在它所在的包之外进行访问），必须通过get、set方法来访问成员变量 对于包级私有、私有嵌套类，直接暴露它的数据域并没有本质错误。 阅读全文

摘要：区分一个组件设计得好不好，取决于它对于外部的其他组件而言，是否隐藏了其内部数据和其他实现细节。设计良好的组件会隐藏所有的实现细节，把 API 与实现清晰地隔离开来。然后，组件之间只会通过 API 进行通信，一个模块不需要知道其他模块的内部工作情况。这个概念被称为信息隐藏（information hi 阅读全文

摘要：1. 什么时候应该让类实现 Comparable 接口 Comparable 接口是一个泛型接口，代码如下： public interface Comparable<T> { int compareTo(T t); } 类实现 Comparable 接口，就表明它的实例具有内在的排序关系，比如按照字 阅读全文

摘要：1. Object 中对 clone 接口的规范 clone 方法的通用约定是非常弱的，下面是来自 Object 规范中的约定内容： 创建和返回该对象的一个拷贝。这个 “拷贝” 的精确含义取决于该对象的类。一般的含义是，对于任何对象 x，有： x.clone() != x; // true x.cl 阅读全文

摘要：1. hashCode 的基本约定 每一个覆盖了 equals 方法的类中，都必须覆盖 hashCode 方法。如果不这样做的话，就会违反 hashCode 的通用约定，从而导致该类无法结合所有基于散列的集合一起正常运作，这类集合包括 HashMap 和 HashSet。下面是约定内容： 在同一个应 阅读全文

摘要：1. 为什么要始终覆盖 toString 遵守 toString 约定并不像遵守 equals 和 hashCode 的约定那么重要。但是，提供好的 toString 方法可以使类用起来更加舒适，使用这个类的系统也更易于调试。 2. 覆盖 toString 时的约定 在实际应用中，toString 阅读全文

摘要：1. 实现高质量 equals 方法的诀窍 使用 == 操作符检查 ”参数是否为这个对象的引用“。如果是，则返回 true。这只是一种性能优化。引用相同，则必定相等，无需进行后续对值的比较。 使用 instanceof 操作检查 ”参数是否为正确的类型“。如果不是，则返回 false。一般来说，所谓 阅读全文

摘要：非空性（Non-Nullity）—— 所有的对象都不能等于 null。 实际上覆写 equals 时不需要显式地检查类型，因为在 instanceof 执行该判断， public boolean equals(Object o) { if (!(o instanceof MyType)) { // 阅读全文

摘要：equals 约定的第四个要求是：如果两个对象相等，它们必须始终保持相等，除非它们中有一个对象（或者两个都）被修改了。换句话说，可变对象在不同的时候可以与不同的对象相等，而不可变对象则不会这样。当你在写一个类的时候，应该仔细考虑它是否应该是不可变的。不论类是否是不可变的，都不要使equals方法依赖 阅读全文

摘要：1. 传递性要求 equals约定的第三个要求是，如果 x eq y，y eq z，则 x eq z。 我们很容易在无意识的情况下违反这条约定。特别是 “值” 类组件的超类中，子类对超类 equals 行为的扩展导致 equals 函数的传递性问题。 public class Point { pri 阅读全文

摘要：任何两个对象对于 “它们是否相等” 问题必须保持一致。与第一个要求不同，若无意中违反这一条，这种情形倒是不难想象。例如，下面的类，它实现了一个不区分大小写的字符串。字符串由 toString 保存，但在 equals 操作中被忽略。 /** * 覆写 Object 的 equals 方法时, 必须满 阅读全文

摘要：1. 不需要覆盖 equals 方法的情况 覆盖 equals 方法看起来很简单，但是有许多覆盖方式会导致错误，并且后果非常严重。最容易避免这类问题的办法就是不覆盖 equals 方法，在这种情况下，类的每个实例都只与其自身相等。以下情况不需要覆盖 equals 方法： 类的每个实例本质上都是唯一的 阅读全文

摘要：1. 使用 try-finally 关闭资源的缺点 Java 类库中包括许多必须通过调用 close 方法来手工关闭的资源。例如，InputStream、OutputStream 和 java.sql.Connection。客户端经常会忽略资源的关闭，造成严重的性能浪费。虽然这其中的许多资源都有终结 阅读全文

摘要：在 Java 程序中，应尽量避免使用终结方法（finalizer），因为它通常是不可预测的，也是很危险的，一般情况下是不必要的。清除方法没有终结方法那么危险，但仍然是不可预测、运行缓慢、一般情况也是不必要的。注意清除方法需要实现AutoCloseable接口 1. 终结方法和清除方法的缺点 终结方法 阅读全文

摘要：1. 消除因对象自己管理内存导致的内存泄漏 在支持垃圾回收的语言中，内存泄漏是非常隐蔽的（“无意识的对象保持”）。如果一个对象引用被无意识地保留起来了，那么垃圾回收机制不会处理这个对象，而且也不会处理被这个对象引用的所有其他对象。即使只有少量的几个对象引用被无意识地保留下来，也会有许许多多地对象被排 阅读全文

摘要：一般来说，最好能重用单个对象，而不是在每次需要的时候就创建一个相同功能的新对象。 如果对象始终是不可变的，则它始终可以被重用。 1. 对于某些不可变对象 如 String 类型的变量 String s = new String("Hello"); // DON'T DO THIS 上面的语句每次执行 阅读全文

摘要：有些类会依赖一个或多个底层资源。 虽然依赖注入极大地提升了灵活性和可测试性，但会导致大型项目凌乱不堪，因为这些项目通常包含上千个依赖。 最好使用一些依赖注入框架如Dagger、Guice、Spring 来解决该问题 阅读全文

摘要：有时我们会编写一些只含静态方法的一些工具类，我们不希望使用这些类的人创建该类的实例对象。例如, java.lang.Math、java.util.Arryas。此时, 我们可以将该类的构造器私有化。 此外, 有时我们希望用户只能从工厂方法得到实例对象，也可以将该类的构造器私有化。 public cl 阅读全文

摘要：1. 构造单例的第一种方法：公有域方法 优点： 直接获取静态变量，简单 缺点： 享有特权的客户端可以借助 AccessibleObject.setAccessible方法，通过反射机制调用私有构造器。如果需要抵御这种攻击，可以修改构造器，让它在被要求创建第二个实例的时候抛出异常 public cla 阅读全文