java代码重构优化经验,java方法重构

Java代码如何优化

1. 尽量在合适的场合使用单例

使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：

第一，控制资源的使用，通过线程同步来控制资源的并发访问;

第二，控制实例的产生，以达到节约资源的目的;

第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。

2. 尽量避免随意使用静态变量

要知道，当某个对象被定义为stataic变量所引用，那么gc通常是不会回收这个对象所占有的内存

3. 尽量避免过多过常的创建Java对象

尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度的重用对象，最好能用基本的数据类型或数组来替代对象。

4. 尽量使用final修饰符

带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String.为String类指定final防止了使用者覆盖length()方法。另外，如果一个类是final的，则该类所有方法都是final的。Java编译器会寻找机会内联(inline)所有的final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50%.

5. 尽量使用局部变量

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中，速度较快。其他变量，如静态变量、实例变量等，都在堆(Heap)中创建，速度较慢。

6. 尽量处理好包装类型和基本类型两者的使用场所

虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的，基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。

在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。

7. 慎用synchronized,尽量减小synchronize的方法

都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法被调用时，直接会把当前对象锁 了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方法尽量小，并且应尽量使用方法同步代替代码块同步。

8. 尽量使用StringBuilder和StringBuffer进行字符串连接

这个就不多讲了。

9. 尽量不要使用finalize方法

实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。

10. 尽量使用基本数据类型代替对象

String str = "hello";

上面这种方式会创建一个"hello"字符串，而且JVM的字符缓存池还会缓存这个字符串;

String str = new String("hello");

此时程序除创建字符串外，str所引用的String对象底层还包含一个char[]数组，这个char[]数组依次存放了h,e,l,l,o

11. 单线程应尽量使用HashMap、ArrayList

HashTable、Vector等使用了同步机制，降低了性能。

12. 尽量合理的创建HashMap

当你要创建一个比较大的hashMap时，充分利用另一个构造函数

public HashMap(int initialCapacity, float loadFactor)

避免HashMap多次进行了hash重构，扩容是一件很耗费性能的事，在默认中initialCapacity只有16,而loadFactor是 0.75,需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable,Vectors也是一样的道理。

13. 尽量减少对变量的重复计算

并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。

14. 尽量避免不必要的创建

15. 尽量在finally块中释放资源

程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。

16. 尽量使用移位来代替'a/b'的操作

"/"是一个代价很高的操作，使用移位的操作将会更快和更有效

17.尽量使用移位来代替'a*b'的操作

同样的，对于'*'操作，使用移位的操作将会更快和更有效

18. 尽量确定StringBuffer的容量

StringBuffer 的构造器会创建一个默认大小(通常是16)的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再 丢弃旧的数组。在大多数情况下，你可以在创建 StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。

19. 尽量早释放无用对象的引用

大部分时，方法局部引用变量所引用的对象 会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null.

20. 尽量避免使用二维数组

二维数据占用的内存空间比一维数组多得多，大概10倍以上。

21. 尽量避免使用split

除非是必须的，否则应该避免使用split,split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需 要频繁的调用split,可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果。

22. ArrayList LinkedList

一 个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList,ArrayList优于LinkedList,LinkedList还要移动指 针，添加删除的操作LinkedList优于ArrayList,ArrayList还要移动数据，不过这是理论性分析，事实未必如此，重要的是理解好2 者得数据结构，对症下药。

23. 尽量使用System.arraycopy ()代替通过来循环复制数组

System.arraycopy() 要比通过循环来复制数组快的多

24. 尽量缓存经常使用的对象

尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降，推荐可以使用一些第三方的开源工具，如EhCache,Oscache进行缓存，他们基本都实现了FIFO/FLU等缓存算法。

25. 尽量避免非常大的内存分配

有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。

26. 慎用异常

当创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。

如 果您创建一个 Exception ,就得付出代价。好在捕获异常开销不大，因此可以使用 try-catch 将核心内容包起来。从技术上讲，您甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作--尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就 抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。

(1)。 用Boolean.valueOf(boolean b)代替new Boolean()

包装类的内存占用是很恐怖的，它是基本类型内存占用的N倍(N2)，同时new一个对象也是性能的消耗。

(2)。 用Integer.valueOf(int i)代替new Integer()

和Boolean类似，java开发中使用Integer封装int的场合也非常多，并且通常用int表示的数值都非常小。SUN SDK中对Integer的实例化进行了优化，Integer类缓存了-128到127这256个状态的Integer,如果使用 Integer.valueOf(int i)，传入的int范围正好在此内，就返回静态实例。这样如果我们使用Integer.valueOf代替new Integer的话也将大大降低内存的占用。

(3)。 用StringBuffer的append方法代替"+"进行字符串相加。

这个已经被N多人说过N次了，这个就不多说了。

(4)。 避免过深的类层次结构和过深的方法调用。

因为这两者都是非常占用内存的(特别是方法调用更是堆栈空间的消耗大户)。

(5)。 变量只有在用到它的时候才定义和实例化。

这是初学者最容易犯的错，合理的使用变量，并且只有在用到它的时候才定义和实例化，能有效的避免内存空间和执行性能上的浪费，从而提高了代码的效率。

(6)。 避免在循环体中声明创建对象，即使该对象占用内存空间不大。

这种情况在我们的实际应用中经常遇到，而且我们很容易犯类似的错误

采用上面的第二种编写方式，仅在内存中保存一份对该对象的引用，而不像上面的第一种编写方式中代码会在内存中产生大量的对象引用，浪费大量的内存空间，而且增大了垃圾回收的负荷。因此在循环体中声明创建对象的编写方式应该尽量避免。

(7)。 如果if判断中多个条件用'||'或者''连接，请将出现频率最高的条件放在表达式最前面。

这个小技巧往往能有效的提高程序的性能，尤其是当if判断放在循环体里面时，效果更明显。

1.JVM管理两种类型的内存：堆内存(heap)，栈内存(stack)，堆内在主要用来存储程序在运行时创建或实例化的对象与变量。而栈内存则是用来存储程序代码中声明为静态(static)(或非静态)的方法。

2.JVM中对象的生命周期，创建阶段，应用阶段，不可视阶段，不可到达阶段，可收集阶段，终结阶段，释放阶段

3.避免在循环体中创建对象，即使该对象点用内存空间不大。

4.软引用的主要特点是具有较强的引用功能。只有当内存不够的时候，才回收这类内存，因此在内存足够的时候，它们通常不被回收。它可以用于实现一些常用资源的缓存，实现Cache的功能

5.弱引用对象与Soft引用对象最大不同就在于：GC在进行回收时，需要通过算法检查是否回收Soft引用对象，而对于Weak引用对象，GC总是进行回收。

6.共享静态变量存储空间

7.有时候我们为了提高系统性能，避免重复耗时的操作，希望能够重用一些创建完成的对象，利用对象池实现。类似JDBC连接池。

8.瞬间值，序列化对象大变量时，如果此大变量又没有用途，则使用transient声明，不序列化此变量。同时网络传输中也不传输。

9.不要提前创建对象

10 .(1)最基本的建议就是尽早释放无用对象的引用

A a = new A();

a = null; //当使用对象a之后主动将其设置为空

(2)尽量少用finalize函数。

(3) 如果需要使用经常用到的图片展，可以使用软引用。

(4) 注意集合数据类型，包括数组，树等数据，这些数据结构对GC来说，回收更为复杂，

(5) 尽量避免在类的默认构造器中创建，初始化大量的对象，防止在调用其自类的构造器时造成不必要的内存资源浪费。

(6) 尽量避免强制系统做垃圾内存回收。

(7) 尽量避免显式申请数组空间。

(8) 尽量在合适的场景下使用对象池技术以提高系统性能，缩减系统内存开销。

11.当做数组拷贝操作时，采用System.arraycopy()方法完成拷贝操作要比采用循环的办法完成数组拷贝操作效率高

12. 尽量避免在循环体中调用方法，因为方法调用是比较昂贵的。

13. 尽量避免在循环体中使用try-catch 块，最好在循环体外使用try--catch块以提高系统性能。

14. 在多重循环中，如果有可能，尽量将最长的循环放在最内层，最短的循环放在最外层，以减少循环层间的变换次数。

15. 在需要线程安全的情况下，使用List list = Collections.synchronizedList(new ArrayList());

16. 如果预知长度，就设置ArrayList的长度。

17. ArrayList 与 LinkedList 选择，熟悉底层的实现原理，选择适当的容器。

18. 字符串累加采用StringBuffer.

19. 系统I/O优化，采用缓冲和压缩技术。优化性能。

20. 避免在类在构造器的初始化其他类

21 尽量避免在构造中对静态变量做赋值操作

22. 不要在类的构造器中创建类的实例

23. 组合优化继承

24. 最好通过Class.forname() 动态的装载类

25. JSP优化，采用out 对象中的print方法代替println()方法

26 .采用ServletOutputStream 对象代替JSPWriter对象

27. 采用适当的值初始化out 对象缓冲区的大小

28. 尽量采用forward()方法重定向新的JSP

29. 利用线程池技术处理客户请求

30.Servlet优化

(1) 通过init()方法来缓存一些静态数据以提高应用性能。

(2) 用print() 方法取代println()方法。

(3) 用ServletOutputStream 取代 PrintWriter.

(4) 尽量缩小同步代码数量

31. 改善Servlet应用性能的方法

(1)不要使用SingleThreadModel

(2)使用线程池ThreadPool

32. EJB优化

实体EJB:

(1)实体EJB中常用数据缓存与释放

(2)采用延迟加载的方式装载关联数据

(3)尽可能地应用CMP类型实体EJB

(4)直接采用JDBC技术处理大型数据

33. 优化JDBC连接

(1)设置合适的预取行值

(2)采用连接池技术

(3)全合理应用事务

(4)选择合适的事务隔离层与及时关闭连接对象

34. PreparedStatemetn只编译解析一次，而Statement每次都编译解析。

35. 尽可能地做批处理更新

36. 通过采用合适的getXXX方法提高系统性能

37. 采用设计模式。

相关问答

Q1: java中什么是代码重构，什么时候需要代码重构

代码重构（英语：Code refactoring）重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。

软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。

java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：

1、去除已知bug。

2、提高程序运行效率。

3、增加新的功能。

重构举例：（简化代码、提升效率）

重构前：

if(list != null list.size() 0){

for(int i = 0; i list.size(); i++){

//skip...

}

}

重构后

if(list != null){

for(int i = 0, len = list.size(); i len; i++){

//skip...

}

}

何时着手重构（Refactoring）

新官上任三把火，开始一个全新??、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。

开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢？"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。

Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是"队伍变形"的强烈信号：

·代码中存在重复的代码

中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。

程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。

·过大的类和过长的方法

过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。

·牵一毛而需要动全身的修改

当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。

·类之间需要过多的通讯

A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。

·过度耦合的信息链

"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。

·各立山头干革命

如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。

·不完美的设计

在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。

每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。

·缺少必要的注释

虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。

曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。

Q2: 常见代码重构技巧（非常实用）

1_代码重构漫画.jpeg

项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。

造成这样的原因往往有以下几点：

对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。

重构一书的作者Martin Fowler对重构的定义：

根据重构的规模可以大致分为大型重构和小型重构：

大型重构 ：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。

小型重构 ：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。

2_代码常见问题.png

代码重复

方法过长

过大的类

逻辑分散

严重的情结依恋

数据泥团/基本类型偏执

不合理的继承体系

过多的条件判断

过长的参数列

临时变量过多

令人迷惑的暂时字段

纯数据类

不恰当的命名

过多的注释

3_代码质量如何衡量.jpg

代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。

4_SOLID原则.png

一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。

开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。

很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。

子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

子类可以扩展父类的功能，但不能改变父类原有的功能

调用方不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

一个对象应该对其他对象保持最少的了解

尽量使用合成/聚合的方式，而不是使用继承。

单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。

image.png

模块结构说明

代码开发要遵守各层的规范，并注意层级之间的依赖关系。

多个方法代码重复、方法中代码过长或者方法中的语句不在一个抽象层级。

方法是代码复用的最小粒度，方法过长不利于复用，可读性低，提炼方法往往是重构工作的第一步。

意图导向编程 ：把处理某件事的流程和具体做事的实现方式分开。

将函数放进一个单独对象中，如此一来局部变量就变成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。

方法参数比较多时，将参数封装为参数对象

任何有返回值的方法，都不应该有副作用

临时变量仅使用一次或者取值逻辑成本很低的情况下

将复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途

把复杂的条件表达式拆分成多个条件表达式，减少嵌套。嵌套了好几层的if - then-else语句，转换为多个if语句

当出现大量类型检查和判断时，if else（或switch）语句的体积会比较臃肿，这无疑降低了代码的可读性。 另外，if else（或switch）本身就是一个“变化点”，当需要扩展新的类型时，我们不得不追加if else（或switch）语句块，以及相应的逻辑，这无疑降低了程序的可扩展性，也违反了面向对象的开闭原则。

非正常业务状态的处理，使用抛出异常的方式代替返回错误码

某一段代码需要对程序状态做出某种假设，以断言明确表现这种假设。

当使用一个方法返回的对象时，而这个对象可能为空，这个时候需要对这个对象进行操作前，需要进行判空，否则就会报空指针。当这种判断频繁的出现在各处代码之中，就会影响代码的美观程度和可读性，甚至增加Bug的几率。

空引用的问题在Java中无法避免，但可以通过代码编程技巧（引入空对象）来改善这一问题。

根据单一职责原则，一个类应该有明确的责任边界。但在实际工作中，类会不断的扩展。当给某个类添加一项新责任时，你会觉得不值得分离出一个单独的类。于是，随着责任不断增加，这个类包含了大量的数据和函数，逻辑复杂不易理解。

此时你需要考虑将哪些部分分离到一个单独的类中，可以依据高内聚低耦合的原则。如果某些数据和方法总是一起出现，或者某些数据经常同时变化，这就表明它们应该放到一个类中。另一种信号是类的子类化方式：如果你发现子类化只影响类的部分特性，或者类的特性需要以不同方式来子类化，这就意味着你需要分解原来的类。

继承使实现代码重用的有力手段，但这并非总是完成这项工作的最佳工具，使用不当会导致软件变得很脆弱。与方法调用不同的是，继承打破了封装性。子类依赖于其父类中特定功能的实现细节，如果父类的实现随着发行版本的不同而变化，子类可能会遭到破坏，即使他的代码完全没有改变。

举例说明，假设有一个程序使用HashSet，为了调优该程序的性能，需要统计HashSet自从它创建以来添加了多少个元素。为了提供该功能，我们编写一个HashSet的变体。

通过在新的类中增加一个私有域，它引用现有类的一个实例，这种设计被称为组合，因为现有的类变成了新类的一个组件。这样得到的类将会非常稳固，它不依赖现有类的实现细节。即使现有的类添加了新的方法，也不会影响新的类。许多设计模式使用就是这种套路，比如代理模式、装饰者模式

继承与组合如何取舍

Java提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。自从Java8为接口增加缺省方法（default method），这两种机制都允许为实例方法提供实现。主要区别在于，为了实现由抽象类定义的类型，类必须称为抽象类的一个子类。因为Java只允许单继承，所以用抽象类作为类型定义受到了限制。

接口相比于抽象类的优势：

接口虽然提供了缺省方法，但接口仍有有以下局限性：

接口缺省方法的设计目的和优势在于：

为了接口的演化

可以减少第三方工具类的创建

可以避免创建基类

由于接口的局限性和设计目的的不同，接口并不能完全替换抽象类。但是通过对接口提供一个抽象的骨架实现类，可以把接口和抽象类的优点结合起来。 接口负责定义类型，或许还提供一些缺省方法，而骨架实现类则负责实现除基本类型接口方法之外，剩下的非基本类型接口方法。扩展骨架实现占了实现接口之外的大部分工作。这就是模板方法（Template Method）设计模式。

Image [5].png

接口Protocol：定义了RPC协议层两个主要的方法，export暴露服务和refer引用服务

抽象类AbstractProtocol：封装了暴露服务之后的Exporter和引用服务之后的Invoker实例，并实现了服务销毁的逻辑

具体实现类XxxProtocol：实现export暴露服务和refer引用服务具体逻辑

由于为了保持Java代码的兼容性，支持和原生态类型转换，并使用擦除机制实现的泛型。但是使用原生态类型就会失去泛型的优势，会受到编译器警告。

每一条警告都表示可能在运行时抛出ClassCastException异常。要尽最大的努力去消除这些警告。如果无法消除但是可以证明引起警告的代码是安全的，就可以在尽可能小的范围中，使用＠SuppressWarnings("unchecked")注解来禁止警告，但是要把禁止的原因记录下来。

参数化类型不支持协变的，即对于任何两个不同的类型Type1和Type2而言，List既不是List的子类型，也不是它的超类。为了解决这个问题，提高灵活性，Java提供了一种特殊的参数化类型，称作有限制的通配符类型，即List? extends E和List? super E。使用原则是producer-extends，consumer-super（PECS）。如果即是生产者，又是消费者，就没有必要使用通配符了。

还有一种特殊的无限制通配符List?，表示某种类型但不确定。常用作泛型的引用，不可向其添加除Null以外的任何对象。

嵌套类（nested class）是指定义在另一个类的内部的类。 嵌套类存在的目的只是为了它的外部类提供服务，如果其他的环境也会用到的话，应该成为一个顶层类（top-level class）。 嵌套类有四种：静态成员类（static member class）、非静态成员类（nonstatic member class）、匿名类（anonymous class）和 局部类（local class）。除了第一种之外，其他三种都称为内部类（inner class）。

总而言之，这四种嵌套类都有自己的用途。假设这个嵌套类属于一个方法的内部，如果只需要在一个地方创建实例，并且已经有了一个预置的类型可以说明这个类的特征，就要把它做成匿名类。如果一个嵌套类需要在单个方法之外仍然可见，或者它太长了，不适合放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的，否则就做成静态的。

通过对常见场景的代码逻辑进行抽象封装，形成相应的模板工具类，可以大大减少重复代码，专注于业务逻辑，提高代码质量。

面向对象编程相对于面向过程，多了实例化这一步，而对象的创建必须要指定具体类型。我们常见的做法是“哪里用到，就在哪里创建”，使用实例和创建实例的是同一段代码。这似乎使代码更具有可读性，但是某些情况下造成了不必要的耦合。

对于顶层的（非嵌套的）类和接口，只有两种的访问级别：包级私有的（没有public修饰）和公有的（public修饰）。

对于成员（实例/域、方法、嵌套类和嵌套接口）由四种的访问级别，可访问性如下递增：

正确地使用这些修饰符对于实现信息隐藏是非常关键的，原则就是：尽可能地使每个类和成员不被外界访问（私有或包级私有）。这样好处就是在以后的发行版本中，可以对它进行修改、替换或者删除，而无须担心会影响现有的客户端程序。

不可变类是指其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例时提供，并在对象的整个生命周期内固定不变。不可变类好处就是简单易用、线程安全、可自由共享而不容易出错。Java平台类库中包含许多不可变的类，比如String、基本类型包装类、BigDecimal等。

为了使类成为不可变，要遵循下面五条规则：

可变性最小化的一些建议：

TDD的最终目标是整洁可用的代码（clean code that works）。大多数的开发者大部分时间无法得到整洁可用的代码。办法是分而治之。首先解决目标中的“可用”问题，然后再解决“代码的整洁”问题。这与体系结构驱动（architecture-driven）的开发相反。

采用TDD另一个好处就是让我们拥有一套伴随代码产生的详尽的自动化测试集。将来无论出于任何原因（需求、重构、性能改进）需要对代码进行维护时，在这套测试集的驱动下工作，我们代码将会一直是健壮的。

Image [6].png

添加一个测试 - 运行所有测试并检查测试结果 - 编写代码以通过测试 - 运行所有测试且全部通过 - 重构代码，以消除重复设计，优化设计结构

作者：VectorJin