类的设计技巧，这是 Java 核心技术中，作者说明的，我这里搬运一下。
因为觉得这个会优化代码的好坏，所以单独搬运一章，如果不想看的，直接跳过这个章吧。
| Point（要点） | 描述说明 |
| 一定要保证数据私有 |
A、这是最重要的；绝对不要破坏封装性。 B、虽然有时候，需要编写访问器和更改器，但是最好还是保持实例域的私有性；C、D 两点是告诉我们为什么要保护数据私有。 C、因为很多惨痛的经验告诉我们，数据的表示形式很可能会改变，但它们的使用方式却不会经常发生变化。 D、数据保持私有时，它们的表示形式的变化不会对类的使用者产生影响，即使出现Bug 也易于检查。 |
| 一定要对数据初始化 |
A、Java 不对局部变量进行初始化，但是会对对象的实例域进行初始化。 B、最好不要依赖系统的默认值，而是应该显式地初始化所有的数据。 C、可以直接设置默认值，或者在所有构造器中设置默认值。 |
| 不要在类中使用过多的基本类型 |
A、也就是说，用其他的类代替多个相关的基本类型的使用。 例如，Customer 类有以下的实例域： private String street; private String city; private String state; private int zip; private String name; .... 上面的实例域 street、city、zip、state 我们可以直接用 Address 类去替换掉它。这样做的好处是，很容易处理地址的变化，如，需要增加对国际地址的处理。 这一点要个人去分析，然后绝对是否提取出来；考验能力。 |
| 不是所有的域，都需要独立的域访问器和域更改器 |
A、像雇员的薪金这种是可能变化的，才是需要的访问器和更改器。 B、像雇员的雇用日期，这种不需要更改器，访问器需要。 C、其他一下域，就只能在 该类/该对象 中进行 访问和修改，不要给到外部的，就不需要访问器或者更改器，这一点也是需要个人去分析。 |
| 将职责过多的类进行分解 |
A、这点就更加考验个人能力，因为什么是 "过多的职责"，这点挺模糊不清的。 B、我的建议是，太过复杂的，能抽取出来的，还有抽取出来的好处，比如上面的，不要在类中使用过多的基本类型中的例子；这样的就可以分解一下。 C、但是对于 上面 那点，Java 核心技术的作者，提到不要 矫枉过正；也就是例如：一个复制的类，我们可以把它分解为两个清晰的类，你却要把它分成8个，10个那样。 D、这一点，是真的很考验个人能力；我个人建议是，每个类的职责只要比较很清晰，就不太需要分离，要是分离，分离出来的类只是都要承担 三个以上的职责。 |
| 类名和方法名能够体现它们的职责 |
A、这样的好处是，看到它们的名字，我们就大概知道它是干嘛用的。 B、对于类名，良好的命名习惯是采用一个名词（如：Order）、前面有形容词修饰的的名称（如：RushOrder）或动名词修饰的名称（如：BillingOrder）。 C、对于方法来说，习惯是访问器是 小写的 get 开头（如：getSalary），更改器是小写的 set 开头（setSalary）。 |
| 优秀使用不可变的类 |
A、书上举例的是 LocalDate 类以及 java.time 包中的其他类时不可变的；没有方法能够修改对象的状态。 B、你可能会对 A 点产生疑问，没有方法修改对象的状态 咩意思啊？ 然后翻了一下书，找了 plusDay 的方法，说这不是嘛。然而书上说了，plusDay 不是更改对象，而且返回一个状态修改过的 新对象；没错 新的 （<— _ <—）。 C、书上说，更改对象的问题在于，如果多个线程试图同时更新一个对象，就会发生并发更改；结果如何是不可预料的。如果类是不可变的，就可以安全地在多个线程间共享其对象。 D、我不会多线程，也不理解多线程，我只需要记住有上面情况先，学完多线程再回来理解吧。 E、作者说到，但并不是所有类都应当不可变的，例如：你给 张三 加薪，调用完raiseSalary方法后，就返回一个 新的张三 对象，这样好奇怪。 F、没错，还是那句，考验个人能力的时候到了 。
|
有了解过 Java 的同学，应该都知道，传说中的《阿里巴巴Java开发手册》是阿里内部Java工程师所遵循的开发规范，涵盖编程规约、单元测试规约、异常日志规约、MySQL规约、工程规约、安全规约等，这是近万名阿里Java技术精英的经验总结，并经历了多次大规模一线实战检验及完善。
意思就是自己去查吧，一些前人踏过的坑，如何避免。