To程序员：要写出好代码，你需要懂点儿“底层思维”

👆点击“博文视点Broadview”，获取更多书讯

在阿里巴巴的晋升会议上，评委经常会问：“你的成功可以复制吗？”

我最初做评委时基本不会问这样的问题，因为我认为这样的问题很虚，工作完成就行了，不需要那么多道理。

然而随着时间的推移，我发现这的确是一个好问题。

因为它可以区分出你是碰巧把事情做对了，还是你具备了一直做对事情的能力，二者是有本质区别的。碰巧做对，说明你的能力可能还不足，换一种情景，你就不一定能应付。

因此，好的晋升制度不仅要考查成绩，更重要的是考查能力。对从事脑力劳动的技术人员来说，“能力”主要指的是“思维能力”。

例如，我们都知道编程的时候命名很重要，也很难，可为什么会这样呢？

如果要深挖其背后的原因，将是一个非常有趣的话题，甚至可以和哲学有关。

命名工作中暗含了抽象思维能力和语言哲学，语言本身是抽象的符号，比如当你说“花”的时候，指的并不是某一朵具体的玫瑰花、郁金香，而是花的抽象概念。一朵具体的花虽然看得见、摸得着，但总会有凋零消亡的时候，而“花”这个字作为精神实体将永不会消亡。所以，抽象的花和具体的花到底哪个才是本真呢？这是一个哲学问题。

抛开哲学争论，就“花”这个字而言，它是提取了所有花的共性的抽象符号。命名之所以难，是因为你要经历一个提取共性、归纳要义，并赋予恰当名称的抽象思维过程。

因此，要想真正做好命名，除了要掌握一些命名技法，还需要更深层次的修炼——提升抽象思维能力。

在《西方哲学史》中，奥古斯丁说：“至于什么是时间，在没人问我时，我非常清楚；可一旦要向别人解释，我就有点糊涂了。”

对于抽象的概念也是如此，我们都知道，抽象思维是工程师最重要的思维能力。因为软件设计是纯思维的创造活动，软件技术本质上就是一门抽象的艺术。程序员每天都要动用抽象思维，对问题域进行分析、归纳、综合、判断、推理等。

但到底什么是抽象思维？什么是抽象的层次性？如何运用抽象思维解决软件中的问题？如何提升抽象思维能力？对于这些问题，并不是每个人都能说的清楚。

简而言之，“抽”就是抽离，“象”就是具象。从字面上理解抽象，抽象的过程就是从“具象”事物中归纳共同特征，“抽取”得到一般化的概念的过程。英文的抽象——abstract，来自拉丁文abstractio，它的原意是排除、抽出。

为了更直观地理解抽象，让我们先来看一幅毕加索的画。图的左边是一头水牛，是具象的；右边是毕加索的画，是抽象的。

抽象牛只有几根线条，不过这几根线条是做了高度抽象之后的线条，过滤了水牛的绝大部分细节，只保留了牛最本质的特征，比如牛角、牛头、牛鞭、牛尾巴等。这种对细节的舍弃使得“抽象牛”具有更好的泛化（Generalization）能力。可以说，抽象概念更接近问题的本质。也就是说，所有的牛都逃不过这几根线条。

回到毕加索的抽象画，如果映射到面向对象编程，抽象牛就是抽象类（Abstract Class），代表了所有牛的抽象。抽象牛可以被泛化成更多的牛，比如水牛、奶牛、牦牛等。每一种牛都代表了一类（Class）牛，对于每一类牛，我们可以通过实例化，得到一个具体的牛实例（Instance）。

从这个简单的案例中，我们可以总结出抽象的3个特点。

对于程序员来说，对抽象层次的权衡是对我们设计能力的考验，要根据业务的需要，选择合理的抽象层次，既不能太高，也不能太低。

例如，现在要写一个关于水果的程序，我们需要对水果进行抽象，因为水果里面有红色的苹果，我们当然可以建一个RedApple的类，但是这个抽象层次有点低，只能用来表达“红色的苹果”。假如来一个绿色的苹果，你还得新建一个GreenApple类。

为了提升抽象层次，我们可以把RedApple类改成Apple类，让颜色变成Apple的属性，这样红色和绿色的苹果就都能用Apple表达了。再继续往上抽象，我们还可以得到水果类、植物类等。

可以看出，抽象层次越高，内涵越小，外延越大，泛化能力越强。然而，其代价就是业务语义表达能力越弱。

我经常开玩笑说：“为了通用性，把所有的类都设置为Object，把所有的参数都设置为Map的系统，是最通用的。”因为Object和Map的内涵最小，其泛化能力最强，可以适配所有的扩展。从原理上来说，这种抽象也是对的，万物皆对象嘛！但我们为什么不这么做呢？就是因为越抽象，越空洞，虽然通用，但也“无用”。

思考一下，我们在写代码的过程中，什么时候会用到强制类型转换呢？当然是LSP不能被满足的时候，也就是说子类的方法超出了父类的类型定义范围，为了使用子类的方法，只能使用类型强制转换将类型转成子类类型。

举个例子，在苹果（Apple）类上，有一个isSweet()方法用于判断水果甜不甜；在西瓜（Watermelon）类上，有一个isJuicy()用于判断水分是否充足的；同时，它们都共同继承一个水果（Fruit）类。

此时，我们需要挑选出甜的水果和有水分的西瓜，会编写如下一段程序：

public class FruitPicker {

    public List pickGood(List fruits){        return fruits.stream().filter(e -> check(e)).                collect(Collectors.toList());    }        private boolean check(Fruit e) {        if(e instanceof Apple){            if(((Apple) e).isSweet()){                return true;            }        }        if(e instanceof Watermelon){            if(((Watermelon) e).isJuicy()){                return true;            }        }        return false;    }}

对于代码中的强制类型转换，仔细分析一下，可以发现，根本原因在于isSweet()和isJuicy()的抽象层次不够。站在更高的抽象层次，也就是Fruit的视角看，我们挑选的就是可口的水果，只是具体到苹果时，我们看甜度；具体到西瓜时，我们看水分而已。

解决方法是对isSweet( )和isJuicy( )进行抽象层次提升，我们可以在Fruit上创建一个isTasty( )的抽象方法。

注意：tasty这个词本身就要比sweet和juicy要抽象。

因此，我们在做抽象提升的时候，一定是伴随着语言的变化的。

通过提升抽象层次，我们消除了instanceof判断和强制类型转换，让代码重新满足了里氏替换原则，利用面向对象的多态，也使代码重新变得优雅可扩展了。

public class FruitPicker {

    public List pickGood(List fruits){        return fruits.stream().filter(e -> check(e)).                collect(Collectors.toList());    }            private boolean check(Fruit e) {        return e.isTasty(); //不再需要instanceof和强制类型转换    }}

所以，每当我们在程序中准备使用instanceof做类型判断，或者用cast做强制类型转换的时候，都有可能是一次做提升抽象层次的机会。

▊ 《程序员的底层思维》

张建飞 著

 
如果喜欢本文
欢迎 在看丨留言丨分享至朋友圈 三连

 热文推荐  

书单 | 云端架构怎么设计才好？这几本书告诉你！
程序员最讨厌的四件事，它能解决！
豆瓣9.6分，Scala编程圣经第5版重磅来袭！
量子时代已来，与时代接轨，从这本书开始！


▼点击阅读原文，了解本书详情~