盘点 10 个代码重构的小技巧

约定不等于承诺〃 2022-12-11 06:28 166阅读 0赞

##  ##

点击上方“java大数据修炼之道”，选择“设为星标”

# 优质文章和精品资源, 第一时间送达 #

###  ###

![format_png][]![format_png 1][]

##  ##

来源：https://urlify.cn/yme6Vz

**上一篇：**[Java开发必须掌握的 20+ 种 Spring 常用注解][Java_ 20_ _ Spring]

本次我们抛开 JAVA 虚拟机源码这些相对底层的东西，LZ 来与各位探讨一下几个代码重构的小技巧，这些内容部分来自于书籍当中，部分来自于 LZ 维护项目当中的一些实践经验。如果猿友们曾经用过这种手法，也不妨参与到文章的留言当中，将你的小心得、小体会共享与他人，也可以拿来冲击 LZ 自己定义的排行榜，LZ 不甚欢迎。

重构的手法有很多种，相对而言，一篇文章的涵盖量自然是无法提到所有，LZ 这里也只能提出一些平时会经常使用的一些手法，像一些比较高端的手法，各位有兴趣的可以去找一些专门的书籍涉猎。

另外还有一点，由于 LZ 是做 JAVA 开发的，因此部分重构小技巧可能与 JAVA 语言，或者说与面向对象的语言息息相关，不过大多数技巧，无论是面向过程的语言，还是面向对象的语言，都是可以相互通用的。

废话不多说，我们来看看实用重构技巧的排行榜吧。

**No.1**

## **重复代码的提炼**    ##

重复代码是重构收效最大的手法之一，进行这项重构的原因不需要多说。它有很多很明显的好处，比如总代码量大大减少，维护方便，代码条理更加清晰易读。

它的重点就在于寻找代码当中完成某项子功能的重复代码，找到以后请毫不犹豫将它移动到合适的方法当中，并存放在合适的类当中。

#### **小实例** ####

class BadExample {
    
        public void someMethod1(){
            //code
            System.out.println("重复代码");/* 重复代码块 */
            //code
        }
    
        public void someMethod2(){
            //code
            System.out.println("重复代码");/* 重复代码块 */
            //code
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public void someMethod1(){
            //code
            someMethod3();
            //code
        }
    
        public void someMethod2(){
            //code
            someMethod3();
            //code
        }
    
        public void someMethod3(){
            System.out.println("重复代码");/* 重复代码块 */
        }
    
    }

**No.2**

## **冗长方法的分割** ##

有关冗长方法的分割，其实有时候与重复代码的提炼是有着不可分割的关系的，往往在我们提炼重复代码的过程中，就不知不觉的完成了对某一个超长方法的分割。倘若在你提炼了大部分的重复代码之后，某一些冗长方法依然留存，此时就要静下心来专门处理这些冗长方法了。

这其中有一点是值得注意的，由于我们在分割一个大方法时，大部分都是针对其中的一些子功能分割，因此我们需要给每一个子功能起一个恰到好处的方法名，这很重要。可以说，能否给方法起一个好名字，有时候能体现出一个程序猿的大致水准。

#### **小实例** ####

class BadExample {
    
        public void someMethod(){
            //function[1]
            //function[2]
            //function[3]
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public void someMethod(){
            function1();
            function2();
            function3();
        }
    
        private void function1(){
            //function[1]
        }
    
        private void function2(){
            //function[2]
        }
    
        private void function3(){
            //function[3]
        }
    
    }

**No.3**

## **嵌套条件分支的优化（1）**    ##

大量的嵌套条件分支是很容易让人望而却步的代码，我们应该极力避免这种代码的出现。尽管结构化原则一直在说一个函数只能有一个出口，但是在这么大量的嵌套条件分支下，让我们忘了这所谓的规则吧。

有一个专业名词叫卫语句，可以治疗这种恐怖的嵌套条件语句。它的核心思想是，将不满足某些条件的情况放在方法前面，并及时跳出方法，以免对后面的判断造成影响。经过这项手术的代码看起来会非常的清晰，下面 LZ 就给各位举一个经典的例子，各位可以自行评判一下这两种方式，哪个让你看起来更清晰一点。

#### **小实例** ####

class BadExample {
    
        public void someMethod(Object A,Object B){
            if (A != null) {
                if (B != null) {
                    //code[1]
                }else {
                    //code[3]
                }
            }else {
                //code[2]
            }
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public void someMethod(Object A,Object B){
            if (A == null) {
                //code[2]
                return;
            }
            if (B == null) {
                //code[3]
                return;
            }
            //code[1]
        }
    
    }

**No.4**

## **嵌套条件分支的优化（2）** ##

此处所说的嵌套条件分支与上面的有些许不同，它无法使用卫语句进行优化，而应该是将条件分支合并，以此来达到代码清晰的目的。由这两条也可以看出，嵌套条件分支在编码当中应当尽量避免，它会大大降低代码的可读性。

下面请尚且不明觉厉的猿友看下面这个典型的小例子。

#### **小实例** ####

class BadExample {
    
        public void someMethod(Object A,Object B){
            if (A != null) {
                if (B != null) {
                    //code
                }
            }
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public void someMethod(Object A,Object B){
            if (A != null && B != null) {
                //code
            }
        }
    
    }

**No.5**

## **去掉一次性的临时变量**    ##

生活当中我们都经常用一次性筷子，这无疑是对树木的摧残。然而在程序当中，一次性的临时变量不仅是对性能上小小的摧残，更是对代码可读性的亵渎。因此我们有必要对一些一次性的临时变量进行手术。

#### **小实例** ####

class BadExample {
    
        private int i;
    
        public int someMethod(){
            int temp = getVariable();
            return temp * 100;
        }
    
        public int getVariable(){
            return i;
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        private int i;
    
        public int someMethod(){
            return getVariable() * 100;
        }
    
        public int getVariable(){
            return i;
        }
    
    }

**No.6**

## **消除过长参数列表** ##

对于一些传递了大批参数的方法，对于追求代码整洁的程序猿来说，是无法接受的。我们可以尝试将这些参数封装成一个对象传递给方法，从而去除过长的参数列表。大部分情况下，当你尝试寻找这样一个对象的时候，它往往已经存在了，因此绝大多数情况下，我们并不需要做多余的工作。

#### **小实例** ####

class BadExample {
    
        public void someMethod(int i,int j,int k,int l,int m,int n){
            //code
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public void someMethod(Data data){
            //code
        }
    
    }
    
    class Data{
    
        private int i;
        private int j;
        private int k;
        private int l;
        private int m;
        private int n;
    
    　　//getter&&setter
    
    }

**No.7**

## **提取类或继承体系中的常量**    ##

这项重构的目的是为了消除一些魔数或者是字符串常量等等，魔数所带来的弊端自不用说，它会让人对程序的意图产生迷惑。而对于字符串等类型的常量的消除，更多的好处在于维护时的方便。因为我们只需要修改一个常量，就可以完成对程序中所有使用该常量的代码的修改。

顺便提一句，与此类情况类似并且最常见的，就是 Action 基类中，对于 INPUT、LIST、SUCCESS 等这些常量的提取。

#### **小实例** ####

class BadExample {
    
        public void someMethod1(){
            send("您的操作已成功！");
        }
    
        public void someMethod2(){
            send("您的操作已成功！");
        }
    
        public void someMethod3(){
            send("您的操作已成功！");
        }
    
        private void send(String message){
            //code
        }
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        protected static final String SUCCESS_MESSAGE = "您的操作已成功！";
    
        public void someMethod1(){
            send(SUCCESS_MESSAGE);
        }
    
        public void someMethod2(){
            send(SUCCESS_MESSAGE);
        }
    
        public void someMethod3(){
            send(SUCCESS_MESSAGE);
        }
    
        private void send(String message){
            //code
        }
    
    }

**No.8**

## **让类提供应该提供的方法** ##

很多时候，我们经常会操作一个类的大部分属性，从而得到一个最终我们想要的结果。这种时候，我们应该让这个类做它该做的事情，而不应该让我们替它做。而且大部分时候，这个过程最终会成为重复代码的根源。

#### **小实例** ####

class BadExample {
    
        public int someMethod(Data data){
            int i = data.getI();
            int j = data.getJ();
            int k = data.getK();
            return i * j * k;
        }
    
        public static class Data{
    
            private int i;
            private int j;
            private int k;
    
            public Data(int i, int j, int k) {
                super();
                this.i = i;
                this.j = j;
                this.k = k;
            }
    
            public int getI() {
                return i;
            }
    
            public int getJ() {
                return j;
            }
    
            public int getK() {
                return k;
            }
    
        }
    
    }
    
    /* ---------------------分割线---------------------- */
    
    class GoodExample {
    
        public int someMethod(Data data){
            return data.getResult();
        }
    
        public static class Data{
    
            private int i;
            private int j;
            private int k;
    
            public Data(int i, int j, int k) {
                super();
                this.i = i;
                this.j = j;
                this.k = k;
            }
    
            public int getI() {
                return i;
            }
    
            public int getJ() {
                return j;
            }
    
            public int getK() {
                return k;
            }
    
            public int getResult(){
                return i * j * k;
            }
    
        }
    
    }

**No.9**

## **拆分冗长的类** ##

这项技巧其实也是属于非常实用的一个技巧，只不过由于它的难度相对较高，因此被 LZ 排在了后面。针对这个技巧，LZ 很难像上面的技巧一样，给出一个即简单又很容易说明问题的小例子，因为它已经不仅仅是小手段了。

大部分时候，我们拆分一个类的关注点应该主要集中在类的属性上面。拆分出来的两批属性应该在逻辑上是可以分离的，并且在代码当中，这两批属性的使用也都分别集中于某一些方法当中。如果实在有一些属性同时存在于拆分后的两批方法内部，那么可以通过参数传递的方式解决这种依赖。

类的拆分是一个相对较大的工程，毕竟一个大类往往在程序中已经被很多类所使用着，因此这项重构的难度相当之大，一定要谨慎，并做好足够的测试。

**No.10**

## **提取继承体系中重复的属性与方法到父类**    ##

这项技巧大部分时候需要足够的判断力，很多时候，这其实是在向模板方法模式迈进的过程。它的实例 LZ 这里无法给出，原因是因为它的小实例会毫无意义，无非就是子类有一样的属性或者方法，然后删除子类的重复属性或方法放到父类当中。

往往这一类重构都不会是小工程，因此这一项重构与第九种类似，都需要足够的谨慎与测试。而且需要在你足够确认，这些提取到父类中的属性或方法，应该是子类的共性的时候，才可以使用这项技巧。

##     ##

**结束语**

由于 LZ 目前的工作就是维护一个相对古老的项目，因此上面这十种手法，LZ 几乎都已经一一尝试过了，可喜的是效果都还不错。

限于最后两种与实际情况的联系太过紧密，因此 LZ 无法给出简单的实例，不过后面两种毕竟不是常用的重构手法，因此也算是可以接受了。不过不常用不代表不重要，各位猿友还是要知道这一点的。另外 LZ 还要说的是，上面的实例只是手法的一种简单展示，实际应用当中，代码的结构可能是千奇百怪，但却万变不离其宗。因此只要抓住每种手法的核心，就不难从这些乱军丛中安然穿过。

好了，本次的小分享到此结束，各位猿友如果觉得有所收获，可以推荐一下鼓励下 LZ，顺便也让更多的人看到。这样的话，或许我们每一个接手的项目代码，都不至于十分的糟糕了，也算是给像 LZ 这样的项目维护者一条生路吧。

*  ####  ####
    
    ![format_png 2][]
    
    \-- < End > --
 *  ####  ####
    
    **最近热文推荐：**
    
    1、[建议收藏 | Redis 使用 10 个小技巧][_ Redis _ 10]  
    
    
    2、[面试必问的一致性Hash在负载均衡中的应用][Hash]
    
    3、[项目中常用的19条MySQL优化][19_MySQL]
    
    4、[单怼多线程，60道面试题，你能答上几个？（附答案）][60]
    
    5、[这21 个刁钻的HashMap 面试题，我把阿里面试官吊打了！][21 _HashMap]
    
    6、[Java开发必须掌握的 20+ 种 Spring 常用注解][Java_ 20_ _ Spring]  
    
    
    7、[老要求用java将word转为PDF，这么搞？][java_word_PDF]  
    
    
    8、[Redis分布式锁没用明白，搞出了大故障…][Redis]
    
    9、[程序员面试 10 大潜规则，千万不要踩坑！][10]  
    
    
    10、[*【收藏了】10分钟读懂进程线程、同步异步、阻塞非阻塞、并发并行*][10 1]
 *  #### **看完本文有收获？请转发分享给更多有需要的人** ####
 *  ####  ####
    
    关注 java大数据修炼之道
    
    **![format_png 3][]**每天学习java技术，你想学的Java知识这里都有！**![format_png 3][]**
    
    ![format_png 4][]
    
    微信扫描二维码，关注我的公众号
    
    写留言
 *  ####  ####
    
    如果对你有帮助,请点个"在看 ![format_png 5][]",谢谢 ![format_png 6][]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy80dlpIaWI2a0RxaGV5dHNqMkFmMnhXWVZpYnlYRE1rbW5aZkNYb2liM2lhUWtTcGxmUGJRdWRXdGFONWwxTzUyc3JWYlZaV2pRWWN0UXl1NXNMSkpmZHBPaWJnLzY0MA?x-oss-process=image/format,png
[format_png 1]: /images/20221123/63d7eba87d784f80a1feff4911fc5f0f.png
[Java_ 20_ _ Spring]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22d67ccb5a471b0eb2969ac654b6d01b0c93d9c317164658f0486d5420f585c12599c56bd&idx=1&mid=2247492523&scene=21&sn=0c62a1d6bd02b85bc027d607286199b0#wechat_redirect
[format_png 2]: /images/20221123/3f1abce8bf7f4ec18aff1981a754e5cf.png
[_ Redis _ 10]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22e05ccb5a713216d76a47efd7e4144ab9be9616235630f5f4edea4c8615182203fb8ef74&idx=1&mid=2247491785&scene=21&sn=a8cae67660d5733f1da6003c50d3529f#wechat_redirect
[Hash]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22d53ccb5a4458368c5034905386313cc8eaf10dad2ba864989c613ae17febd1d1bfb91e3&idx=1&mid=2247492511&scene=21&sn=27c655b7b71e5a98abd810fd6f395450#wechat_redirect
[19_MySQL]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22c17ccb5a501df41ddeaecf0f7e85e292b45d6c7522e4d6a4d9c4a93a389338ee175eae8&idx=1&mid=2247492315&scene=21&sn=37c6888e30892c7fae56d0769c35a571#wechat_redirect
[60]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d557ccb65c41ec5d3b7dedd6c7a22949ddcb5de1406de482c3b702a1a4768c66b730b219&idx=1&mid=2247490459&scene=21&sn=66bc23ae41a8abcb9a6f00be754b2e47#wechat_redirect
[21 _HashMap]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d429ccb65d3fc4be6ab008e4318d3beeccb1394801c72e33cbb9fd162868dce2b9b0c0f2&idx=1&mid=2247490277&scene=21&sn=63d44db7ae6930f25478119f423227d4#wechat_redirect
[java_word_PDF]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22dc7ccb5a4d1b94f2a9bbce26082c9f845fbbf7d588a5540d072bcef39b2281d0b705f91&idx=1&mid=2247492363&scene=21&sn=6975a1a5de92dc49d04654f21ffa7c21#wechat_redirect
[Redis]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d038ccb6592e2d08ccd07a31a069ebbfc64d9abd2d1cfd88dba5efc1439f14cc78392bf3&idx=1&mid=2247491316&scene=21&sn=59fdccb5447abec7e33c881110c5be1f#wechat_redirect
[10]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22cc6ccb5a5d09ec368b85dfe087d1b68f6ccbf67d7275356f64f203d353dcba684b4012e&idx=1&mid=2247492106&scene=21&sn=e25c3eea649006f34fd6f5cb62ea78be#wechat_redirect
[10 1]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d748ccb65e5e8bfe2334dac9c4a1678fa77a4b1c6bb230fb4442682c36120cfb8d8941ae&idx=1&mid=2247489924&scene=21&sn=40b4b841430ae75879b25545291dbf0a#wechat_redirect
[format_png 3]: /images/20221123/3eb1f071fa9c4c209f668dd652eab3a6.png
[format_png 4]: /images/20221123/64616633a747418db3cb0910ec0d02f8.png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9DMXVETURxam4xOXd0dVFwSzNqbUpXM2JGR1dJOFl6NkZSMTd0bDFNRjhWZnFZeFB4OTkwa3YySjc0THZxd2liMjZLYXlIZE9YZDZlYnpycVlpYmJUand3LzY0MA?x-oss-process=image/format,png
[format_png 6]: /images/20221123/ba03fca2bae44a8cb7da58227cece915.png