设计模式与架构的核心概念乃是抽象

  最近一年来一直在学习设计模式，上周在公司内部听了一个分享，当时一位同事提出设计模式的核心是封装，我强烈不赞同，在我看来设计模式的核心乃是抽象。

  君不见，各种开源框架开源项目遍地都是抽象类和接口，每每此时，你心中肯定一万个草泥马在奔腾：是不是有病呀，整这么多接口和抽象类，也不嫌累。其实不是这样的，为了扩展性，这些是必须的。

  面对对象的三大原则是：封装、继承、多态。封装就不必说了，但是没有抽象，就没有继承和多态。

  设计模式6大原则SOLID，除了单一职责原则，其余五个原则都需要抽象，没有抽象，其他5个原则完全无法实现。

  设计模式23种，除了门面模式，每一种模式都需要抽象，没有抽象，23种设计模式也无从实现。

  那为什么抽象最重要呢？我们回想一下，设计模式和架构想解决的最关键的问题是什么？是扩展性，是如何快速应对需求的变更。什么样的东西扩展性最强，适用的问题领域最广，当然是抽象的东西。举个例子：我是一个水果，这句话适用的领域就比我是一个苹果适用的领域要广。即越抽象的东西越具备扩展性，前提是你要基于问题领域做好思考，到底可能的扩充方式有哪些，才好预先留好扩充的接口。论及复用，则是作用范围越小的东西越具备复用性。

是什么在谷歌让数千名工程师建立可扩展的系统，是因为他们有非常聪明的工程师像杰夫·迪恩和桑杰·格玛沃特创建了简单，但丰富的抽象，如MapReduce的，SSTable，Protocol Buffer等。是什么让Facebook工程这么支持大规模，是因为专注于核心，同样喜欢抽象和简单，Thrift, Scribe, Hive。是什么让设计人员能够在Quora的有效构建产品，Webnode，Livenode 也是基于同样的理解。

保持核心抽象的简单和减少自定义解决方案，并增加团队熟悉度和对专业知识的抽象。日益普及系统像Memcached，Redis，MongoDB等系统都是降低建立定制存储和缓存系统的必要。团队重点转移到少数核心抽象，而不是分裂在很多临时解决方案，让公共库更稳健，监控更智能，性能更易理解，测试更全面。所有这一切都有助于搭建一个简单的系统，降低操作负担。