软件设计-项目重构技巧

版权声明
作者:zuoxiaolong(左潇龙)
出处:博客园左潇龙的技术博客–http://www.cnblogs.com/zuoxiaolong
您的支持是对博主最大的鼓励,感谢您的认真阅读。
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
原文地址:https://www.cnblogs.com/zuoxiaolong/p/pattern27.html

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还要说的是,上面的实例只是手法的一种简单展示,实际应用当中,代码的结构可能是千奇百怪,但却万变不离其宗。因此只要抓住每种手法的核心,就不难从这些乱军丛中安然穿过。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
项⽬重构⽅案设计 最近接⼿到⼀个已经成型的项⽬,然后我们的任务就是对它进⾏重构,这个项⽬是⼀个功能很齐全的WPF视频播放器(附带很多其他功 能),在仔细研究了项⽬的背景和架构以后,初步做出了⼀下的重构⽅案: ⽬前现状: 虽然整个系统做得很漂亮,代码也写得不错,但仍有以下不⾜: 1. 架构有待改善。虽然看似MVC架构,却没有遵循MVC的模式,⾥⾯逻辑和UI耦合很⾼,没有清晰的规律。 2. 没有充分⽤到WPF的特性。WPF除了给我们很多炫丽的效果外,还给我们提供了诸如Binding,command等特性,这些特性可以帮我们隔开耦合, 同时减少代码量。 3. 代码和⽂件没有组织。代码、dll、样式⽂件和资源⽂件等没有统⼀的组织,到处都有,这样看起来就会很混乱。 4. 没有建⽴公⽤代码库。没有把公⽤的代码库独⽴出来,很多地⽅都是另外在写,这样既增加了代码量,同时维护和重构也带来了⿇烦。 5. 逻辑处理不应暴露在Client端。项⽬是⼀个C/S架构的系统,没有必要把所有的逻辑都暴露在Client端,应该⽤分布式把Logic放在服务器端,这样 可以更安全同时使客户端变⼩。 6. 没有单元测试。这样⼀个庞⼤的程序,没有单元测试是⾮常危险的,我们不可能做到100%的覆盖率,但是我们可以对主要的逻辑和Function做单 元测试,这样既减少了测试⼈员的⼯作量同时整个系统的安全、稳定和可维护性得到了⼤⼤的提⾼。 7. 性能不够优化。启动项⽬,通过WPF性能⼯具Perforator和Visual Profiler分析得出,程序启动和界⾯操作都导致CPU很⾼,内存也消耗⽐较多。 解决⽅案 1. 1. 针对缺陷1的"架构问题"。做法是采⽤MVP或者MVVM模式,⽬前正在对⽐和考虑。 2. 针对缺陷2的"WPF特性"。做法是充分利⽤Binding,command等特性。 3. 针对缺陷3的"代码和⽂件没有组织"。做法是建⽴⼀些单独的⼯程或者⽂件来分类和组织这些代码,并且充分隔离 耦合。 4. 针对缺陷4的"没有建⽴公⽤代码库"。做法是把⼀些公⽤的代码和常⽤的代码做成单独的Dll,并且有完整的单元测 试,这样才能提⾼效率。 5. 针对缺陷5的"逻辑处理不应暴露在Client端"。做法是⽤WCF做为中间层,把业务逻辑全部进⾏封装,通过WCF提 供统⼀的接⼝供项⽬调⽤。 6. 针对缺陷6的"没有单元测试"。做法是不管⽤MVP还是MVVM,我们起码保证对逻辑组件的代码有充分的单元测试 覆盖,同时对⼀些公⽤的组件也要有单独的单元测试代码。 7. 针对缺陷7的"性能不够优化"。这个我会单独做⼀个性能优化列表出来,针对耗资源的操作和其他有损害性能的操 作,我们应该避免。 8. 那么我们就可以结合实际情况搭建如下的结构 9. 10. 因为使⽤了MVVM模式,所以UI结构图就做如下调整 11. 12. 由于整个项⽬客户部希望我们引⽤第三⽅的组件或者⼯具,所以很多功能都只能通过企业库实现,⽐如AOP和 IOC,log和exception对项⽬特征做了定制化,数据访问通过企业库重写实现局部ORM,对性能要求⽐较⾼的应⽤仍 然实现存储过程。对所有事务操作都转移到数据库,邮件使⽤JOB进⾏发送。⼤型数据和客户要求较⾼的实时操 作,⽤MSMQ和SSB相结合的⽅式。层次依赖关系 UI: 功能模块使⽤时候,都会⾸先通过UI层次Security模块的安全验证(验证是通过Components模块⾥⾯的⾃定义的⽤于页⾯功能以及功能 点验证的控件触发), Security模块会通过服务层获取⽤户⾝份数据,⽤于页⾯验证. 功能模块的实际功能实现,如果需要数据库⽀持,那么依然会通过服务层进⾏数据操作.整个架构基于MVVM模式。 Service:通过WCF做中间服务,使应⽤隔离开来,这样有利于扩展和维护,同事提⾼了整个应⽤程序的伸缩性。 Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调⽤,由上往下调⽤,逐级依赖,最后Service底层边界Data Access模块将调 ⽤Framework中的Data模块,Data模块将调⽤MS.EntLib3中的Data,向数据服务器发送数据操作命令和数据. Framework: 该层次提供许多基础的功能模块(七⼤块),分别提供给UI,Service层⾥⾯的模块直接或者间接的调⽤,同时也可以看到 Framework层次内部各模块之间再运⾏时也有互相依赖调⽤的关系存在.该层次的部分模块会依赖和调⽤Ms.EntLib3中的模块,⼀般是按 照两个层次⾥⾯的模块名称,产⽣关系的. MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的,只会在运⾏时被更⾼层次的模块依赖和调⽤,同时该层次内部各个模块之间也 存在依赖和运⾏时调⽤关系.  
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值