继续扒

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

一而再地抽象（Abstraction Again）

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

我们只看到一整行的内容，当传入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行的情况，如下图：

所以很显然，只传入一个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方法。经过观察，可以看出一行内容由三个部分组成，我们再一次忽略具体的细节。

如上，三种颜色表示了三个部分，我们再一次运用抽象，先不考虑传什么参数，有点像是写伪代码（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;
    }

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

图中规律已经很明显，最终结果如下：

    /**
     * 获取每行第一部分的元素个数
     * @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住，余下主题我们下回再见。

小程序中的大道理之二