# 如何在简洁与抽象间平衡

抽象是编程的关键。你应该仔细选择你需要抽象的程度。充满活力的初学者经常创建许多没有什么用的抽象。一个标识是，你是否创建了这样一个类,不包含任何代码并且没有真的做什么事情,除了抽象一些东西。这种抽象是可以理解的，但代码的简洁性的价值必须与代码的抽象价值相权衡。有时候，我们可以看到一种热情的理想主义者犯的错误：在工程的一开始，定义了一大堆的看起来抽象得很美的类，然后他会推测说它们可以处理每一个可能出现的情况。随着项目推进及琐事掺杂进来，这些代码本身变得混乱了。函数体比他们本来该有的样子还要长。空的类是一种写文档的负担，在压力之下，它们会被忽略。如果让花在抽象上的精力去保持其简短，最后的结果应该会更好。这是一种*推测编程*的形式。我强烈推荐 PAUL gRAHAM\[PGSite] 的这篇文章 ['Succinctness is Power' by Paul Graham](http://www.paulgraham.com/power.html)。

有这样一种关于*信息封装*和*面向对象编程*的有用技能，但有时候它们被带远了。这些技术让一个人抽象地编码并预计变数。然而，我个人认为，你不应该写太多推测性的代码。例如，在一个对象里用增量器和访问器隐藏一个整数变量是一种可接受的风格，这样变量本身就没有暴露，仅仅暴露了很少的关于它的接口。这确实允许了变量的实现的改变不影响调用代码，并且可能对一个必须提供一个稳定 API 的库编写者是合适的。我不认为这种好处会超过其冗长的代价，特别是当我的团队拥有调用代码并因此可以把调用器重构为比原来的更容易时。四到五行多余的代码会是这种推测性好处的沉重代价。

可移植性也有类似的问题。代码是否应当可移植到不同的电脑，编译器，软件系统或平台？还是简单地传输？我认为，不可移植，短而简单传输的代码比长而可移植的代码要好。把不可移植代码限制在特定的领域是一个想对轻松而且无疑是好的主意。比如一个使用了特定 DBMS 的数据库查询的类。

Next [如何学习新技能](https://braydie.gitbook.io/how-to-be-a-programmer/zh-traditional/2-intermediate/personal-skills/06-how-to-learn-new-skills)