首页 > 代码库 > 小程序中的大道理之二

小程序中的大道理之二

继续扒


接着上一篇的叙述,健壮性也有了,现在是时候处理点实际的东西了,但我们依然不会一步到底,让我们来看看。

一而再地抽象(Abstraction Again)

让我们继续无视那些空格以及星号等细节,我们看到什么呢?

image

我们只看到一整行的内容,当传入3时就有3行,传入4时就有4行。我们用一个方法getLineContent来表示这样一个抽象。代码如下:

    public String getPattern(int lineCount) {
        if (lineCount < 1) {
            throw new IllegalArgumentException("行数不能小于1!");
        }
        if (lineCount > 20) {
            throw new IllegalArgumentException("行数不能大于20!");
        }
        
        StringBuilder pattern = new StringBuilder();
        for (int lineNumber = 0; lineNumber < lineCount; lineNumber++) {
            pattern.append(getLineContent(lineNumber));
        }
        return pattern.toString();
    }

黑盒子,输入以及输出(Black Box, Input & Output)

先不急着让IDE生成代码,现在集中精力思考一下,我们仅仅在这一层面上去思考,把getLineContent看作类似电路那样有一些输入端和输出端的黑盒子:

  1. 返回的值是我们想要的吗?

  2. 传入的参数是否足够让“getLineContent”里面完成它的工作呢?

第一点是可以肯定的,但传入的参数是否足够了呢?

如果按上述代码,不管是3行的情况,还是5行的情况,获取第一行的内容时,调用的都是getLineContent(0),按照输入决定输出的原则,结果将一样。

但我们很清楚,5行情况下的第一行前面的空格肯定要多于3行的情况,如下图:

image

所以很显然,只传入一个lineNumber是不够的,还要把总的行数lineCount也传进去。

自顶向下(Top-down)

现在把代码改下,多传入一个参数,并让IDE为我们生成getLineContent的代码,作些简单修改,最终如下:

    public String getPattern(int lineCount) {
        if (lineCount < 1) {
            throw new IllegalArgumentException("行数不能小于1!");
        }
        if (lineCount > 20) {
            throw new IllegalArgumentException("行数不能大于20!");
        }
        
        StringBuilder pattern = new StringBuilder();
        for (int lineNumber = 0; lineNumber < lineCount; lineNumber++) {
            pattern.append(getLineContent(lineCount, lineNumber));
        }
        return pattern.toString();
    }

    private String getLineContent(int lineCount, int lineNumber) {
        // TODO Auto-generated method stub
        return null;
    }

那么,这样一种先从高层考虑起的做法,就是所谓的自顶向下了,接下来我们还会不断地以这种方式来完成这个小程序。

自顶向下是一种很重要的思考及处理问题的方式,如果你还不习惯这样去考虑问题(包括写代码),现在是时候尝试一下了。

项目进度(Project Progress)

另外,getPattern方法里面的TODO标识可以去掉了,这个方法已经算是完成了,如果现在太阳就快下山了,那么你也可以提交它了,你的项目经理也很乐意看到“代码量天天在增长”,这给了他信心,让他觉得“项目正在稳步推进”,当他给项目总监或者客户汇报时,他就可以展示一些“进度”给他们看了。

当管理者看不到进度时,他们就会感觉到压力,这种压力会转移到你身上,你甚至会“被志愿加班”。这种压力除了损害我们的健康外没有任何好处,所以你要学聪明一点,当管理者问起你的时候,你就大声对他们说:“我今天又提交了XXX行代码。”,然后你就拍拍屁股准时下班了。

再而三的抽象(Abstraction, again and again)

现在把目光投向getLineContent方法。经过观察,可以看出一行内容由三个部分组成,我们再一次忽略具体的细节。

image

如上,三种颜色表示了三个部分,我们再一次运用抽象,先不考虑传什么参数,有点像是写伪代码(pseudo code)那样快速把程序的骨架(Skeleton)写出来:

    private String getLineContent(int lineCount, int lineNumber) {
        // TODO Auto-generated method stub
        StringBuilder content = new StringBuilder();
        
        // 1. 空格部分
        content.append(getFirstPart());
        // 2. 星号部分
        content.append(getSecondPart());
        // 3. 换行部分
        content.append(getThirdPart());
        
        return content.toString();
    }

现在再来仔细考虑往里面传入参数的问题:

  • 第一个方法getFirstPart,其实是有关于输出前置空格的,前面已经分析过“5行情况下的第一行前面的空格肯定要多于3行的情况”,所以它需要两个参数。

  • 第二个方法getSecondPart,是关于输出星号的,可以看出,无论是3行还是5行,第一行都是1个星,第二行都是3个星,所以这个跟总行数lineCount无关,只与行号lineNumber有关,所以只要传入一个参数即可。

  • 第三个方法getThirdPart,其实就是一个换行,所以不需要传任何参数。

有人可能有些疑问:这样是不是分得太细了?抽象与封装究竟要到什么样的程度呢?

过度工程(Overengineer)

特别地,让我们看看第三个方法:getThirdPart。我们知道,这最后其实就是一个换行,一条语句即可搞掂,所以再封装就没有必要了。

过度的抽象与封装有时反而使得程序臃肿难读,半天也找不到具体“干活”的语句在哪,性能方面也会受到损害。

Java语言中已经可以直接表达换行的语义,最终结果如下:

    private String getLineContent(int lineCount, int lineNumber) {
        StringBuilder content = new StringBuilder();
        
        // 1. 空格部分
        content.append(getFirstPart(lineCount, lineNumber));
        // 2. 星号部分
        content.append(getSecondPart(lineNumber));
        // 3. 换行部分
        content.append(System.lineSeparator());
        
        return content.toString();
    }

    private String getFirstPart(int lineCount, int lineNumber) {
        // TODO Auto-generated method stub
        return null;
    }

    private String getSecondPart(int lineNumber) {
        // TODO Auto-generated method stub
        return null;
    }

抽象不足(Lack of Abstraction)

另一方面,我们也要警惕缺少必要的封装层次的情况。不幸的是,很多情况,我们都是缺少必要的抽象与封装。

做过维护的同学可能都见过那种超长超恐怖的方法,里面的语句有的甚至高达几千行,哪怕是在方法内找一个变量的定义,也能让你想起周杰伦与费正清合唱的那首歌——《千里之外》,去维护这样的方法自然不是什么愉快的经历。

这里之所以不厌其烦地对这个小程序不断的抽象下去,是想告诉大家,即使是如此之小的一个程序,抽象到这一地步,语义层面依然还没有过度的倾向。

通常,如果程序语言已经可以直接表达出我们想要的语义,封装就可以结束了。我们来审视一下前两个方法,显然,还不能直接表达,所以封装还可以继续。

一般地,如果一条语句就能表达的时候,抽象与封装也就基本到头了。

同时,不必过于刻板地去遵循这些,有时三两条语句可以表达时,不封装也是很正常的;

而有时为了提供更清晰的语义,哪怕只有一条语句,你再封装一下也是可取的。

当然了,对于目前这个小程序,大家可能觉得已经有些过度封装了,但在后面我们将看出,其实还没到最抽象的阶段。现在先不争论这一点,说到后面我们就明白了。

分而治之(Divide and Conquer)

其实抽象与封装还能带来什么好处呢?那就是这里要讨论的分而治之了。

我们可以回顾一下程序写到现在,我们可曾遇到什么“阻碍”没有?

答案是没有。你可以看看前面的代码,都是简简单单的for循环,append之类的。

有人可能不服气地说:

“困难的地方都被你这种一层又一层的抽象与封装延后了,代码写了半天啥事也没干到。”

这种评价对不对呢?的确,前面通过抽象不断地压制那些细节的表达,不断地推迟对其的处理。

想像有一个房间,衣服,物品堆放得乱七八糟,这时有人拿来一个大箱子,把这些东西通通塞了进去。把这些东西”封装“起来后,房间自然整洁了,但我们也很清楚,箱子里依旧是一团糟。

但这个比喻并不适合这里的情况,我们的抽象并不是简单地把问题转移了,通过一层层抽象的手段,一个大问题在不断被分解成一个个小问题。

1. 有些足够清晰的小问题,我们已经在这一过程中把它解决掉了。

比如,输出一个换行的问题。

2. 而那些还不够清晰的小问题,也已经通过抽象被我们所孤立(isolate,或者叫隔离)出来了,有的已经看到了解决的曙光。

比如,在上一步,我们还是有两个参数传了进来,但通过在里面进一步划分成新的子问题,可以看到,有些子问题只要一个参数即可解决了。

所以,抽象并不是什么事也没干,相反,它干了很重要的事情。

通过抽象,问题正在被分解与简化;通过抽象,我们构建出了程序的骨架。

在这一过程中,大问题分解成小问题并被安排到了适当的位置,与其它的小问题隔离开来,有个词怎么说的,”众神归位“,大概就是这样一个意思。

群魔乱舞,你怎么去应付呢?如果他们都呆在自己的位置上,我们就可挨个收拾他们了。

抽象不存在“事不过三”(No Limits for Abstraction)

让我们继续,我们还可以继续抽象吗?答案是肯定的。无论是参数更多的getFirstPart,还是参数更少的getSecondPart,它们都还可以分成两部分:

  1. 拿到一个数量N(你甭管怎么算出来)

  2. 输出N个空格或星号

代码如下:

    private String getFirstPart(int lineCount, int lineNumber) {
        int count = getElementCountOfFirstPart(lineCount, lineNumber);
        StringBuilder part = new StringBuilder();
        for (int i = 0; i < count; i++) {
            part.append(" ");
        }
        return part.toString();
    }

    private String getSecondPart(int lineNumber) {
        int count = getElementCountOfSecondPart(lineNumber);
        StringBuilder part = new StringBuilder();
        for (int i = 0; i < count; i++) {
            part.append("*");
        }
        return part.toString();
    }
    
    private int getElementCountOfFirstPart(int lineCount, int lineNumber) {
        // TODO Auto-generated method stub
        return 0;
    }

    private int getElementCountOfSecondPart(int lineNumber) {
        // TODO Auto-generated method stub
        return 0;
    }

现在再来看看如何实现最后的两个方法,以一个四行的图案为例:

image

图中规律已经很明显,最终结果如下:

    /**
     * 获取每行第一部分的元素个数
     * @param lineCount 总行数
     * @param lineNumber 行号,从0开始
     * @return
     */
    public int getElementCountOfFirstPart(int lineCount, int lineNumber) {
        return lineCount - lineNumber - 1;
    }

    /**
     * 获取每行第二部分的元素个数
     * @param lineNumber 行号,从0开始
     * @return
     */
    public int getElementCountOfSecondPart(int lineNumber) {
        return lineNumber * 2 + 1;
    }

这里把最后的两个方法加了注释,并把它们改成了public,为什么呢?下面将作些解释。

抽象到数字

有人可能不太理解,为什么要抽象到如此之深,这里最后两个方法都只有一条语句,直接在上一层就写了不就完了?

可以看到,最后两个方法,返回的都是int类型,也即一个数字。我们都知道,数字是非常纯粹,非常抽象的一种概念,抽象到了这一层,已经不能再抽象了。比如,单独拿一个“1”出来,它是非常抽象的:

1可以是一粒土豆,1也可以是一颗红薯;

1可以是一匹元代马,1也可以是一头程序猿。

抽象(abstract)作为一个动词而言,它的原始意义,有“把…抽取出来”的意思,即有把东西抽离,剥离的意思。

我们说数字很纯粹,为什么要追求这种纯粹呢?这一过程中我们又把什么剥离了?

耦合,解耦合,得意而忘形(Coupling, Decoupling,$%#&…)

我们都听过一种说法,叫“言不达意”或者又叫“词不达意”,表明我们用“言”来表达“意”,当然“达不达”就是另一回事了;另一方面:

“言者所以在意,得意而忘言。”——《庄子 外物》

而《晋书·阮籍传》中有一段对阮籍的描述:

“嗜酒能啸,善弹琴。当其得意,忽忘形骸。”

这就是所谓的“得意忘形”的最初意义:

指得其意,即其思想精髓,而不必计较形,即表现形式。

而“形意交融”则表明形跟意常常是混在一起的,“意”需要通过“形”传递给我们。

要表达的意思与它的载体之间的这种紧密关系,用我们软件领域的说法,就叫“耦合”。

这里可以算是耦合的一种,耦合还可以有很多其它方面的理解。

这种形与意的交融有时并不是件什么好事,陶渊明在他的《归去来兮辞》里说:

既自以心为形役,奚惆怅而独悲。

回到我们的问题,前面一直在处理这么一个图案,那么,这个图案它的“形”是什么呢?而它的“意”又是什么呢?

显然,那些一个个的星号(以及前面的空格)就是所谓的“形”了,而“意”呢?

其实就是前面说的“抽象到了极致的数字”了,这就是图案的“意”。

通过把“形”从图案中剥离,或者说把“意”从图案中抽取出来,我们就能“得意而忘形”,从而达到解耦合的目的。

把握住了“意”,我们就不必拘泥于空格或者星号,我们可以使用各种各样的“形”,最终出来的图案依然可以看到“三角形”的影子。

如果你已经对所谓的MVC(Model-View-Control,模型-视图-控制)有些了解,那你是否在这里看到了Model跟View的影子呢?

再一次的,由于篇幅过长,这次还是不能“扒到底”,美腿有点长,再扒一半,就此膝斩。Hold住,余下主题我们下回再见。

小程序中的大道理之二