果冻的猿宇宙

再继续扒

继续 前一篇 的话题, 在那里, 提到了抽象, 耦合及 MVC, 现在继续探讨这些, 不过在此之前先说下第一篇里提到的对称性.

注: 以下讨论建立在前面的基础之上, 为控制篇幅起见, 这里将不再重复前面说到的部分, 如果您还没看过前两篇章, 阅读起来可能会有些困难.

这是第一篇的链接小程序中的大道理

对称性(Symmetry)

这里先说下对称性的问题. 问题中的图案是左右对称的, 但到目前为此, 我们的代码却不是对称的, 输出之所以对称原因在于空格与背景之间难以区分.

让我们换个符号, 比如脱字符"^", 再输出一下, 就可以看出不对称来, 因为在右边我们输出星号后就直接换行了:

只要稍微调整一下程序, 在输出换行之前再输出一下空格(或者现在的脱字符"^"), 就能满足对称的输出了:

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

这样之后, 图案是左右对称, 反映在程序上就呈现出上下对称了. 当然也可以把三个语句写在一行里, 这样它也左右对称了:

程序是对客观世界的问题的一种映射, 因此程序的结构反映了问题的结构.

当然了, 如果你的程序写得很松散, 结构, 层次不清晰, 就不太容易看出这种对称来.

不知道是否有人意识到了, 在前面我有意无意地忽略了另一个对称问题. 这就是星号的对称, 在上图中只是把它当成对称轴看待.

撇开什么脱字符"^"或者空格, 其实单纯由星号构成的三角形也是对称的, 这是更主要的一个对称:

这种对称又来自哪里呢? 让我们深入到 getSecondPart 里面去:

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();
}

很遗憾, 你看不到什么对称. 继续深入到 getElementCountOfSecondPart 去:

public int getElementCountOfSecondPart(int lineNumber) {
    return lineNumber * 2 + 1;
}

好了, 你已经到头了, 可好像还是找不到对称的影子呀? 前面说"程序的结构反映了问题的结构", 难道这个结论并不总是成立的?

有这么一个故事, 我估计很多人都听说过(文字摘自以下网址 http://www.niwota.com/submsg/5682754/):

有一位牧师在某个星期六的早晨正在为明天的讲道稿大伤脑筋. 他的太太外出买东西了, 外面正下着雨, 小儿子失去了户外活动的机会, 在屋里折腾. 牧师的思路一再被儿子打断.

牧师手边正好有本旧杂志, 为了把儿子从身边支开, 他撕下一张彩色世界地图, 再撕成碎片, 丢到客厅地板上对儿子说: "Johnny, 你把它拼成原样, 我就给你一个 Nickle(25 美分镍币). "

儿子有事可做, 又有报酬可得, 积极性很高, 立刻拼了起来. 牧师想, 这下子我可以安静一个上午, 构思自己的讲道稿了. 谁知道只隔了十分钟, 儿子就来敲书房的门了, 说已经拼好. 牧师不相信, 跑到客厅一看, 果然整幅地图完整无缺. 牧师又懊恼又惊奇地问儿子: "你怎么那么快就拼好了呢? "

儿子得意地说, 这再简单不过了, 这张地图的背后印着一幅人物肖像, 我想, 如果这个人拼对了, 世界地图也就拼对了.

牧师忍不住笑了起来, 很高兴地给了儿子一个镍币, 说, 你替我把明天讲道的题目也准备好了: 如果一个人是对的, 那么这个人的世界也是对的.

现在我们的程序能够输出一个对称的图案来, 肯定不是巧合, 而且我也可以肯定地告诉你, 这里面是有对称的. 你可以再仔细找找看, 如果你已经找到或者实在找不出来, 那么可以往下看了:

现在看来是不是很明显呢? 也许你早也看出来了. 我们能得到有什么启示呢?

运用**直觉(Intuition)**去思考!

如果你的代码中怎么变换也找不出对称来, 当你的人都是错的时候, 你的世界还可能正确吗? 所以你甚至不用费心去上机验证了.

发明了**差分机(difference engine)的计算机先驱查尔斯·巴贝奇(Charles Babbage)**说:

我曾两次被(议员)问到, "巴贝奇先生, 请问假如您往机器里输入了错误的数据, 还会出来正确的答案吗? "我实在无法恰当地理解是怎样的逻辑混乱才会(使他们)提出这样的一个问题.

On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

看得出来巴贝奇的评论还是很客气的, 他当时似乎在寻求议员拨款来支持他的差分机研究, 我估计他当时内心其实想说: "你丫脑子进水了, 问这种问题!"

巴贝奇谈的是往正确的机器里输入错误的数据的情况, 在这里, 如果连机器里面(即代码)都已经是错的, 那么即便给出了正确输入, 也不可能有正确的输出了.

在某些特殊情况下, 你也许会碰到"负负得正"的情况, 但这不过是巧合而已.

你可能遇到过这样的 bug:

你加了一个新特性, 系统出错了, 你找到一处 bug, 然后你很奇怪, 为何之前居然没问题? 而在你改正这个 bug 后, 之前的一些功能反而不正常了!你可能打死也想不到系统中还有另一个你没发现的 bug 在默默地抵消了它!

诚然, 这样的"负负得正"情况即便能工作也是非常脆弱的.

当事实与直觉不符时, 那么一定有什么地方出错了.

回到我们的问题, 再单独地拿输出空格部分来看:

public int getElementCountOfFirstPart(int lineCount, int lineNumber) {
    return lineCount - lineNumber - 1;
}

有对称吗? 它有两个不同变量, 单独的一份随便你怎么去变换, 你都找不到对称. 这也是为何你需要二份一左一右围绕在星号旁边才能形成对称.

关于直觉, 如果你还有兴趣, 可以见我之前写的另一篇文章(有些读者可能已经看过), 深入图解字符集与字符集编码--定长与变长, 也有谈到用天平之类的模型来直观地思考问题.

本质, 证明以及直觉

按前面那图:

如果有人试图从输出的 1, 3, 5, 7 的展开式的对称性来向你证明表达式"lineNumber*2+1"的对称性, 那么呢? 这不过是本末倒置. 正如前面所说, 你把表达式做个变换就可以看出表达式是对称的, 对称是该表达式的本质属性, 所以输出的1, 3, 5, 7 的对称性恰恰是表达式所决定的.

相信很多人都跟作者类似, 在大学的数学课上, 被那些形形色色的恐怖的证明弄得苦不堪言:

这里是在对"人"弹琴, 数学大"牛"们请走开或请无视(要鄙视, 俺也认了), 这里不是在说你们!你们不会懂的!

如果你的老师只能通过证明来告诉你一件事情为什么是这样, 通常你还是很难明白它为什么是这样, 你甚至可以怀疑老师是否真的深刻理解了这件事情, 要么他就是不打算告诉你真正的原因:

好好反思一下你是否在什么事情上得罪了他? 你写作业是不是全靠"Ctrl+C, Ctrl+V"?

又或者他想让你自己去领悟:

真是用心良苦!你体会到了没有? 你领悟了吗? 要是没有请继续, 学费是不会退滴, 你别领悟到其它地方去了~

而如果你的老师可以通过直觉告诉你事情为什么是这样, 你也许就会说: "啊哈, 原来如此(Aha moment)!"从此你就记住了事情为什么是这样了, 那些冗长的证明你都可以丢到一边去了.

独立的数据模型(Isolated Data Model)

前面说到 getElementCountOfFirstPart 和 getElementCountOfSecondPart 两个方法达到了抽象的极致, 从而与具体的表现形式解耦. 在有了对称性之后, 我们甚至可以反转两个表现形式, 依然可以呈现出所谓的"三角形"出来:

对比两种情况, 不变的是三个部分中的那些数字:

所以这才是图案的"魂", 或者说是它的"意", 抽象出意, 我们就能"得意而忘形".

前面说过也许有一天, 客户的需求可能扩展到 web service 上, 对于一个较大的行数, 需要传输较大的数据, 但有了这种解耦, 我们可以把一个纯粹的数组传递过去:

[3][1][3] [2][3][2] [1][5][1] [0][7][0]

另一方可以在收到这个数据模型后, 再把图形还原.

因为存在对称性, 第三列甚至也可以不传.

灵活性(Flexibility)与松耦合(Loose Couple)

而这个还原过程则可以很灵活地处理, 下图演示了在本地直接利用上述两方法获取图案模式并用 icon 图片展示的效果:

代码如下(我对 swing 之类的编程也不是很熟, 随便在网上搜来的代码改了下):

public class PatternPic extends JPanel {

    private static final long serialVersionUID = 1L;
    
    private Image image;
    
    public PatternPic(Image image) {
        this.image = image;
    };
    
    @Override
    public void paintComponent(Graphics g) {
        super.paintComponent(g);
        int width = image.getWidth(this);
        int height = image.getHeight(this);
    
        int lineCount = 4;
        Pattern pattern = new Pattern();
    
        for (int lineNumber = 0, y = 0; lineNumber < lineCount; lineNumber++, y += height) {
            // 直接获取各部分的数目
            int elementCountOfFirst = pattern.getElementCountOfFirstPart(lineCount, lineNumber);
            int elementCountOfSecond = pattern.getElementCountOfSecondPart(lineNumber);
    
            for (int i = 0, x = elementCountOfFirst * width; i < elementCountOfSecond; i++, x += width) {
                g.drawImage(image, x, y, width, height, this);
            }
        }
    }
    
    public static void main(String[] args) throws IOException {
        Image image = ImageIO.read(PatternPic.class.getResource("/logo-git-oschina.png"));
        JFrame frame = new JFrame();
        frame.add(new PatternPic(image));
        frame.setSize(800, 600);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }
}

所以这样的抽象是有很大好处的, 我们说高层的一些抽象如果觉得啰嗦可以去掉一些(如上述就没作过多的抽象), 但这一层的抽象反而要保留. 我们把它作为公共的 API 提供出去, 调用者就不再受限于那些写死的"空格与星号", 这种灵活性与前面说到的可重用性及可扩展性都是紧密相关的.

MVC

MVC 中重要的一点即是强调模型(M, Model)与视图(V, View)的分离. 所谓的模型即是一种独立于视图的数据, 这与我们抽象出来的数据模型是很相似的.

真正的 MVC 与我们这里的例子间或许还有很大差异, 但在解耦合这一点, 两者是一致.

可以对比下最初的玩具式的代码, 那种情况就是一种 紧耦合(tight couple), 而这里则达到了 松耦合(loose couple) 的目的.

在当下, 常常一方面要处理传统的 web 界面, 另一方面又要处理移动端的界面, 抽取出纯粹的数据模型无疑将带给我们很大方便.

在下一篇将谈谈单元测试的问题.

继续扒

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

一而再地抽象(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 住, 余下主题我们下回再见. 下一篇见

小程序中的大道理三

前言

以下将用一个小程序来探讨一些大道理, 这些大道理包括可扩展性, 抽象与封装, 可维护性, 健壮性, 团队合作, 工具的利用, 可测试性, 自顶向下, 分而治之, 分层, 可读性, 模块化, 松耦合, MVC, 领域模型, 甚至对称性, 香农的信息论等等.

为什么不用大程序来说大道理呢?

因为大程序太大了, 代码一端上来, 读者就晕菜了, 看不过来甚至压根不想去看, 这样说理就很抽象了, 效果反而不好.

小程序中也能说出大道理来吗?

我们有句话, 叫"以小见大", 我们又常常有种说法, 叫:

麻雀虽小, 五毒俱全. (咦? 好像应该是五脏俱全...总之你明白我的意思就好了. )

所以呢, 小程序也是可以来说大道理的, 而且小程序又有短小的特点, 大家看得也没那么累, 也很快能看懂. 毕竟那种代码, 叫什么来着, "意大利面条式的代码", 大家在实际的开发中, 已经见得太多了.

意大利面(spaghetti), 翻译过来好像叫"通心粉", 非常长的一条条, 彼此缠缠绕绕的, 所以"意大利面条式的代码"就是又长又绕, 让人非常头痛的那种代码.

按我们的习惯, 也许叫它"裹脚布式的代码"大家觉得更熟悉, 更形象一点, 也正好符合"又长又臭"的特点.

啊, 说"又长又臭"可能有点刻薄了, 毕竟大家都可能写过这样的代码(本人就写过好多), 即便现在不会再写这样的代码, 想当年应该也是写过的, 除非你从一开始觉悟通天, 那我就无话可说了.

这种代码我们在工作中见得太多了, 所以这里就不再弄出来考验大家的毅力了, 闲话少提, 让我们看个简单的例子.

我们的例子

就是要打印出如下的一个三角形图案:

  *
 ***
*****

当然了, 这只是以三行为一个示例, 我们的程序应该接受任意的正整数, 比如, 给一个 5, 就要能打出 5 行的类似的三角形来. 让我们来看看如何写出这样一个程序, 并在这个过程中借此兜售我们的大道理.

玩具式的代码

我知道很多"数学帝"可能一眼就被图案中的规律吸引过去了, 他们很快就指出星号是等差数列, 然后很快就弄出了计算每行前面要缩进多少个空格的公式, 然后呢, 一层循环, 二层循环, blablablah…然后最里面几条优雅而性感的 print 语句, 搞掂!一种智商上的优越感油然而生, 接着他们可能就要问:

这么简单的东西, 你也好意思拿出来讲?

下面是这样的一个代码, 能够完全实现以上要求(只演示了 3 行的情况):

public static void main(String[] args) {
    int i = 3;
    for (int j = 0; j < i; j++) {
        for (int k = 0; k < i - j; k++) {
            System.out.print(" ");
        }
        for (int z = 0; z < 2*j+1; z++) {
            System.out.print("*");
        }
        System.out.println();
    }
}

这里用的是 java 语言来演示, 包括以下的. 我相信像 java 这样烂大街的语言, 即使你没这个背景看懂也不是难事, 在代码中也不会用到什么高深的特性. (这一点皆因我的能力有限所导致, 而不是想装逼的意愿所能决定的~)

怎么说呢, 我们不要以上那种"玩具式"的代码(toy program), 我们要的是生产级(production, 生产环境)的代码.

生产级的代码

让我们来看看如何写出这样的代码.

可扩展性(Extensibility)

首先呢, print 语句是绝对要避免的. 你要明白, print 语句写得太死, 而需求是不断在变化的, 有句话是怎么说的?

唯一不变的就是变化本身.

客户今天跟你说的是要 print 这个图案, 你要是按着客户怎么说, 你就怎么做, 你可就惨了.

客户哪一天突然又会说, 再加点特性, 要能输出到文件；哪一天又说, 再加点 web service, 能供其它程序调用.

让我们多留点心眼, 代码如下:

public void printPattern(int lineCount) {
    String pattern = getPattern(lineCount);
    System.out.print(pattern);
}

我们先借助 getPattern 方法拿到要打印的内容, 这样, 如果哪天要输出到文件, 哪天要供 web service 调用, 我们都可以把这个 getPattern 方法提供出去.

我们只要多抽象出那么一层来, 就会给我们带来很多方便.

抽象与封装(Abstraction & Encapsulation)

抽象与封装同时也是很多其它特性的基础, 在后面我们还会不断说到这一主题.

getPattern 就是一个抽象, 是对一系列动作的一个封装.

可能有人会比较教条地认为抽象与封装只能在类层次中进行, 这常常导致在类的内部缺少必要的抽象层次, 常常是一大件事情在一个方法里完成, 方法巨大巨长无比, 这样的所谓面向对象编程不过是虚有其表, 其模块性甚至还比不上那些用面向过程语言写就的代码.

在 printPattern 层面, 我们不需要知道 getPattern 的细节, 我们只需要传入所需参数及定义好需要的返回值即可.

大道理: 定义好输入与输出, 描述清楚想要做的事, 先不用去管细节.

然后呢, 我们是不是需要手动去把这个方法写出来呢?

利用好你的工具(Tools)

你不用手动去做这些, 以 eclipse 为例, 只要把光标定位到错误的地方(可以按Ctrl+"."(点)快速定位), 然后按下"Ctrl+1", 然后选择"Create Method"即可:

工具将根据传入参数及返回值自动为我们生成方法, 结果如下:

只要输入与输出定义清楚了, 工具就能自动帮我们生成方法定义, 这里默认它是 private 的, 我们可以把它改成 public.

这里说的是 Eclipse 这个 IDE, 其它的我相信也会有类似的功能. 如果你偏好轻量级的文本编辑器, 那我就不敢说也一定有这些功能了.

利用好任务标识(Task Tags)

我们可以看到, 生成的代码里有个 TODO, 显示出了特别的颜色, 这是个任务标识.

类似的标识还有 FIXME, XXX, 甚至你还可以自定义标识.

打开 eclipse 的菜单-- windows--preferences, 在过滤框中输入"task tag":

这些有什么用呢? 我们可以看下, 在编辑器的左右侧, 都有显著的标志提示有个任务标识存在；在 Markers 视图里, 有列举出这些标识:

在代码质量分析工具 sonar 中, 它也会追踪这些标识. 下图是我在 sonar.oschina.net 上的一个项目的截图:

这些有什么用呢? 我们在写代码中, 写到一半, 很可能被某些难题卡住了, 为了不中断正常的流程, 我们先用个 TODO 来标识, 然后就可以继续地把一些简单的问题先处理完, 再回过头来对付这些.

又或者像现在这样, 我们生成了出来了这个方法, 工具为我们自动加了入"TODO"的标识, 毕竟方法的主体还没有, 可不巧的是, 现在到了下班时间了, 然后呢, 我们就可以存盘并提交到 svn 或者 git 上去了. 有人可能要说: "啊? 不是吧, 你的代码都没写完你怎么就提交了? "

没关系, 我们已经标识好了 TODO, 所以它会提醒我们还有工作是没做完的. 另外我们为何如此着急提交呢? 因为我们并不是在单打独斗:

团队合作(Teamwork)

我们前面说了, 我们可能还要做输出图案到文件的需求, 很可能你有个同事哥们, 他就正做着这个模块, 而他现在呢, 就在等着你这个 getPattern 方法. 你提交了, 他就可以继续写他的代码了:

package org.jcc.core.demo;

public class PatternFile {
    
    private Pattern pattern;

    public PatternFile(Pattern pattern) {
        this.pattern = pattern;
    }
    
    public void generatePatternFile(int lineCount) {
        String content = pattern.getPattern(lineCount);
        saveInFile(content);
    }

    private void saveInFile(String content) {
        // TODO Auto-generated method stub
        //System.out.println(content);
    }
}

可以看到, 他的类依赖你的类, 在他的方法 generatePatternFile 里还调用了 getPattern 方法, 你没实现, 那又怎样呢? 接口好了就行了!

面向接口编程(Interface)

有人可能比较死板, 比较教条主义, 以为呢, 说到接口就一定要弄个 interface, 其实呢, 我们这个方法 getPattern 就是一个承诺, 一个约定, 一个协议, 也是一个广义上的接口.

有人可能要问, 你方法细节还没有实现, 他怎么测试? 别担心, 办法会有的:

利用 Mockito 来测试

代码如下:

@Test
public void testGeneratePatternFile() {
    // 用mockito来模拟接口的行为, 为此我们手动构建一个三行的图案
    Pattern pattern = Mockito.mock(Pattern.class);
    String mockContent = "  *" + System.lineSeparator() 
                       + " ***" + System.lineSeparator() 
                       + "*****" + System.lineSeparator();
    
    // 当调用getPattern方法时, 就返回这里定义好的内容. 
    Mockito.when(pattern.getPattern(3)).thenReturn(mockContent);
    
    // 测试generatePatternFile方法, 在它的里面将会调用getPattern方法
    PatternFile pf = new PatternFile(pattern);
    pf.generatePatternFile(3);
    
    // TODO 断言文件存在并且文件中的内容与mockContent一致
    // assert that file is exists and content in file is equals the mock content
}

以上我们用一个 mock 对象以及 when, thenReturn 来主动模拟一个尚未实现的方法.

你也许对 Mock 之类的技术还不太了解, 但这些词表达的意思我想大家都不难明白. Mock 的更详细介绍请自行百度之.

借助 Mockito, 这个哥们就可以这样写好他的代码, 并完成他的测试了, 然后可以提交他的代码, 宣布工作完成, 接着他就可以飞到马尔代夫去度假去了.

可以看到, 尽管我们的功能八字还没一撇, 可只要我们坚持面向接口编程, 时时想着团队合作, 经常提交已经写好的代码, 特别是公共接口方面的代码, 我们的同事就能及时推进他们的工作, 甚至比我们还早完成, 这都是有可能的, 都是正常的, 也是我们应该追求的.

而利用好抽象及封装, 我们还能得到好几个好处:

可测试性(Testability)

通过以上举例, 可以看到, 我们可以手动构建一个图案, 并交给程序去判断(注: 为了简短起见, 代码中省略了具体的 assert 细节). 而如果是开头那样直接就打印了呢? 你根本没法让程序去判断, 只能通过人眼去观察输出, 这样就给 自动化的测试(Automatic Test) 带来了困难.

可重用性(Reusability)

当 getPattern 被抽象出来之后, 可以看到, 不但可以在 printPattern 方法里使用, 也可以在 generatePatternFile 方法里使用. 而如果按开头那样呢? 你没法复用, 你还是不得不重构；又或者你可能只是简单地把代码复制一遍了, 再作些改动.

当然, 现在这个程序很小, 全部拷贝一遍好像也很快, 但如果是很大的程序呢? 又或者我们又要拓展到可供 web service 调用, 难道就这样拷贝下去? 哪一天程序要做些小调整, 难道又要一一去修改吗?

不要重复(DRY: Don’t Repeat Yourself)

管理重复性一直都是程序开发中的重大关切, 在目前这个小程序里, 这一问题还不是那么迫切, 这个在此就不作详述, 以后会另写一些文章来做些介绍.

好了, 说了一大通, 绕了一大圈, 测试也测了, 同事也度假去了, 我们也要赶紧我们的工作. 那么接下来是不是赶紧写那些实现呢? 不!

我们已经介绍了不少的"ility"结尾的单词, 接下来还要说到!我有点担心大家说我"zhuangbility", 有句话说: "Don't zhuangbility, zhuangbility leads to leipility"(莫装逼, 装逼遭雷劈), 没办法, 为了阐述这些大道理, 我也只好冒着被 leipility 的危险.

可维护性(Maintainability)

你首先把注释写好:

怎么说呢? 现在 IT 工作强度很大, 过劳死是不稀奇的事, 写着写着说不定哪天人就挂了. 一个人挂了不要紧, 工作可不能挂!(不是在说笑话, 貌似有些公司或老板表现出来的态度就是这样的~)

别人要能顺利接手你的活, 这是关键.

其实没必要说"挂了"这些不吉利的话, 也可能是有人要生了, 比如你老婆要生了, 你也休产假去了, 你写到一半, 老板把你的工作转交给你的同事.

试想, 要是一点注释都没有, 你的同事接手起来就很困难, 他要加班加点才能早点弄清你的代码的意图. 所以呢, 不要害了你的同事!把代码的可维护性做好, 大家的健康也才有更好的可维护性!

代码如下:

/**
 * 获取指定行数的图案, 比如3行时: 
 *   *
 *  ***
 * *****
 *  
 * @param lineCount 指定的行数
 * @return 图案的字符串表示, 包括换行符在内
 */
public String getPattern(int lineCount) {
    // TODO Auto-generated method stub
    return null;
}

其实, 良好的命名同样也是可维护性的关键, 比如上面的 getPattern, lineCount, 而不是像最前面那个示例中的 i, j, k, z 等乱七八糟的名字.

另外, 丰富的抽象层次也是如此, 这点我们后续还会不断提及.

好了, 注释也写完了, 然后呢, 现在该轮到写那个该死的等差数列了吧? 不!

健壮性(Robustness)

Robustness 又常常音译成鲁棒性.

作者在大学时读的是自动化专业, 在那些自动控制理论里, 老出现什么鲁棒性, 看了让人犯晕, 不如直接叫健壮性.

我倒是想起了小时候老爸常买给我喝的 Robust(即乐百氏, 与娃哈哈类似的饮品), 味道是不错, 不过喝完身体挺没见得健壮到哪去, 也许喝得还不够多~

我们先要把判断做好, 输入负数或者输入的数字太大了, 你要拒绝它们, 同时在注释中也作出说明:

/**
 * 获取指定行数的图案, 比如3行时: 
 *   *
 *  ***
 * *****
 *  
 * @param lineCount 指定的行数, 1-20之间
 * @return 图案的字符串表示, 包括换行符在内
 */
public String getPattern(int lineCount) {
    if (lineCount < 1) {
        throw new IllegalArgumentException("行数不能小于1!");
    }
    if (lineCount > 20) {
        throw new IllegalArgumentException("行数不能大于20!");
    }
    
    // TODO 
    return null;
}

我知道我在这里说这些, 有些人可能已经不耐烦了, 他们想着的是写那些有技巧的代码, 那些有挑战性的部分, 那些 tricky 的部分, 那些能体现出他们智商上的优越感的部分.

有个词是怎么说的, "rocket science"(火箭科学, 喻指那些高精尖的技术), 特别的有些刚毕业的心气很高的学生, 满脑子想的可能就是这些. 可是呢, 类似情况不是没有, 但通常是很少的:

骚年, 不是我在打击你, 你也许真的想多了. 工作上, 我们多数时候处理的都是一些细节的问题, 一些琐碎的事情, 一些按部就班的样板式的代码, 需要的不是多高的智商, 多么 tricky 的技巧, 要是是耐心, 细致, 严谨, 一丝不苟.

为何一开始就要把这些做好呢? 因为到了后面, 你就没时间去做了. 这一点你一定要相信我, 以下引自 wiki 的"90-90法则":

前 90% 的代码要花费你 90% 的开发时间, 剩余的 10% 的代码要花费你另一个 90% 的开发时间.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

--Tom Cargill, 贝尔实验室

而最后如果因为时间紧急, 就这样没保护就上了生产环境, 一旦出了问题, 你会花更多的时间去收拾这些烂摊子, 而最终你还是不得不将这些补上.

有一个"墨菲定律"(Murphy's Law)大意是这么说的:

有可能出错的的东西一定会出错.

现在不擦屁股, 后面还有得擦. 你省掉了纸尿裤, 你的程序就裸奔了, 你就等着洗更多的外套.

我们也常说: "该来的一定会来. "如果用电影<<无间道>>里的话来说呢, 那就是:

"出来混, 迟早要还的". (哇塞, 说得太精彩了. 这些编导或者剧作家不去写教科书太可惜了. )

所以呢, 不要有侥幸的心理, 把程序从一开始就写健壮才是正道.

小结

说了半天, 我们甚至连一行核心代码都没写, 不过, 文章至此倒是要先做一个阶段了结了. 我们说写代码有个原则, 那就是方法不能太长, 最好一个屏幕就能显示完, 否则看起来就很累了；自然的, 文章也不能写得太长, 否则写起来, 读起来都很累人.

所以呢, 虽然一开始那里提了好多的道理, 本来也是想一扒到底的, 但扒到一半发现已经很长了, 所以上半身扒完, 就此腰斩, 下半身留待后面继续扒, 下半身更精彩, 我们下回再见.

下一篇, 见 小程序中的大道理之二 .