小程序中的大道理之二--抽象与封装

摘要: 本文接着上一篇继续探讨抽象与封装, 团队合作, 自顶向下, 分而治之等主题, 主要深入地探讨了抽象与封装这一主题.

目录

继续扒

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

一而再地抽象(Abstraction Again)

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

pattern as a whole line

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

same line but diff space

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

line as three part

如上, 三种颜色表示了三个部分, 我们再一次运用抽象, 先不考虑传什么参数, 有点像是写 伪代码(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. 有些足够清晰的小问题, 我们已经在这一过程中把它解决掉了.

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

  1. 而那些还不够清晰的小问题, 也已经通过抽象被我们所 孤立(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;
}

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

line num space count and star count relation

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

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

小程序中的大道理三