从上个世纪五十年代冯·诺依曼创造第一台计算机开始，一直到现在只有短短70年时间，从第一门计算机语言FORTRAN，到现在我们常用的C++，JAVA，PYTHON等，计算机语言的演进速度远超我们所使用的任何一门自然语言。从最早的面向机器，再到面向过程，到演化为现在我们所使用的面向对象。不变的是编程的宗旨，变化的是编程的思想。
1 面向机器
计算机是01的世界，最早的程序就是通过这种01机器码来控制计算机的，比如0000代表读取，0001代表保存等。理论上这才是世界上最快的语言，无需翻译直接运行。但弊端也很明显，那就是几乎无法维护。运行5毫秒，编程3小时。由于机器码无法维护，人们在此基础上发明了汇编语言，READ代表0000，SAVE代表0001，这样更易理解和维护。虽然汇编在机器码上更可视更直观，但本质上还是一门面向机器的语言，依然还是存在很高的编程成本。
2 面向过程
面向过程是一种以事件为中心的编程思想，相比于面向机器的编程方式，是一种巨大的进步。我们不用再关注机器指令，而是聚焦于具体的问题。它将一件事情拆分成若干个执行的步骤，然后通过函数实现每一个环节，最终串联起来完成软件设计。
流程化的设计让编码更加清晰，相比于机器码或汇编，开发效率得到了极大改善，包括现在仍然有很多场景更适合面向过程来完成。但软件工程最大的成本在于维护，由于面向过程更多聚焦于问题的解决而非领域的设计，代码的重用性与扩展性弊端逐步彰显出来，随着业务逻辑越来越复杂，软件的复杂性也变得越来越不可控。
3 面向对象
面向对象以分类的方式进行思考和解决问题，面向对象的核心是抽象思维。通过抽象提取共性，通过封装收敛逻辑，通过多态实现扩展。面向对象的思想本质是将数据与行为做结合，数据与行为的载体称之为对象，而对象要负责的是定义职责的边界。面向过程简单快捷，在处理简单的业务系统时，面向对象的效果其实并不如面向过程。但在复杂系统的设计上，通用性的业务流程，个性化的差异点，原子化的功能组件等等，更适合面向对象的编程模式。
但面向对象也不是银弹，甚至有些场景用比不用还糟，一切的根源就是抽象。根据 MECE法则将一个事物进行分类，if else 是软件工程最严谨的分类。我们在设计抽象进行分类时，不一定能抓住最合适的切入点，错误的抽象比没有抽象复杂度更高。里氏替换原则的创始人Barbara Liskov 谈抽象的力量 The Power of Abstraction。
1 真在“面向对象”吗
// 捡入客户到销售私海
public String pick(String salesId, String customerId){
// 校验是否销售角色
Operator operator = dao.find("db_operator", salesId);
if("SALES".equals(operator.getRole())){
return "operator not sales";
}
// 校验销售库容是否已满
int hold = dao.find("sales_hold", salesId);
List<CustomerVo> customers = dao.find("db_sales_customer", salesId);
if(customers.size() >= hold){
return "hold is full";
}
// 校验是否客户可捡入
Opportunity opp = dao.find("db_opportunity", customerId);
if(opp.getOwnerId() != null){
return "can not pick other's customer";
}
// 捡入客户
opp.setOwnerId(salesId);
dao.save(opp);
return "success";
}
这是一段CRM领域销售捡入客户的业务代码。这是我们熟悉的Java-面向对象语言，但这是一段面向对象代码吗？完全面向事件，没有封装没有抽象，难以复用不易扩展。相信在我们代码库，这样的代码不在少数。为什么？因为它将成本放到了未来。我们将此称之为“披着面向对象的外衣，干着面向过程的勾当。”
在系统设计的早期，业务规则不复杂，逻辑复用与扩展体现得也并不强烈，而面向过程的代码在支撑这些相对简单的业务场景是非常容易的。但软件工程最大的成本在于维护，当系统足够复杂时，当初那些写起来最easy的代码，将来就是维护起来最hard的债务。
2 领域驱动设计
还有一种方式我们也可以这么来写，新增“商机”模型，通过商机来关联客户与销售之间的关系。而商机的归属也分为公海、私海等具体归属场景。商机除了有必要的数据外，还应该收拢一些业务行为，捡入、开放、分发等。通过领域建模，利用面向对象的特性，确定边界、抽象封装、行为收拢，对业务分而治之。
当我们业务上说“商机分发到私海”，而我们代码则是“opportunity.pickTo(privateSea)”。这是领域驱动所带来的改变，面向领域设计，面向对象编程，领域模型的抽象就是对现实世界的描述。但这并非一蹴而就的过程，当你只触碰到大象的身板时，你认为这是一扇门，当你触碰到大象的耳朵时，你认为是一片芭蕉。只有我们不断抽象不断重构，我们才能愈发接近业务的真实模型。
Use the model as the backbone of a language, Recognize that a change in the language is a change to the model.Then refactor the code, renaming classes, methods, and modules to conform to the new model
--- Eric Evans 《Domain-Driven Design Reference》
译：使用模型作为语言的支柱，意识到言语的改变就是对模型的改变，然后重构代码，重命名类，方法和模块以符合新模型。
3 软件的复杂度
这是Martin Flowler在 Patterns of Enterprise Application Architecture 这本书中所提的关于复杂度的观点，他将软件开发分为数据驱动与领域驱动。很多时候开发的方式大家倾向于，拿到需求后看表怎么设计，然后看代码怎么写，这其实也是面向过程的一个表现。在软件初期，这样的方式复杂度是很低的，没有复用没有扩展，一人吃饱全家不饿。但随着业务的发展系统的演进，复杂度会陡增。
而一开始通过领域建模方式，以面向对象思维进行软件设计，复杂度的上升可以得到很好的控制。先思考我们领域模型的设计，这是我们业务系统的核心，再逐步外延，到接口到缓存到数据库。但领域的边界，模型的抽象，从刚开始成本是高于数据驱动的。
The goal of software architecture is to minimize the human resources required to build and maintain the required system
--- Robert C. Martin 《Clean Architecture》
译：软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求
如果刚开始我们直接以数据驱动面向过程的流程式代码，可以很轻松的解决问题，并且之后也不会面向更复杂的场景与业务，那这套模式就是最适合这套系统的架构设计。如果我们的系统会随着业务的发展逐渐复杂，每一次的发布都会提升下一次发布的成本，那么我们应该考虑投入必要的成本来面向领域驱动设计。
抽象永远是软件工程领域最难的命题，因为它没有规则，没有标准，甚至没有对错，只分好坏，只分是否适合。同样一份淘宝商品模型的领域抽象，可以算是业界标杆了，但它并非适合你的系统。那我们该如何驾驭“抽象”呢？UML的创始人Grady booch在 Object Oriented Analysis and Design with Applications 一书中，提到了评判一种抽象的品质可以通过如下5个指标进行测量：耦合性、内聚性、充分性、完整性与基础性。
1 耦合性
一个模块与另一个模块之间建立起来的关联强度的测量称之为耦合性。一个模块与其他模块高度相关，那它就难以独立得被理解、变化或修改。TCL语言发明者John Ousterhout教授也有同样的观点。我们应该尽可能减少模块间的耦合依赖，从而降低复杂度。
Complexity is caused by two things: dependencies and obscurity.
--- John Ousterhout 《A Philosophy of Software Design》
译：复杂性是由两件事引起的：依赖性和模糊性。
但这并不意味着我们就不需要耦合。软件设计是朝着扩展性与复用性发展的，继承天然就是强耦合，但它为我们提供了软件系统的复用能力。如同摩擦力一般，起初以为它阻碍了我们前进的步伐，实则没有摩擦力，我们寸步难行。
2 内聚性
内聚性与耦合性都是结构化设计中的概念，内聚性测量的是单个模块里，各个元素的的联系程度。高内聚低耦合，是写在教科书里的观点，但我们也并非何时何地都应该盲目追求高内聚。
内聚性分为偶然性内聚与功能性内聚。金鱼与消防栓，我们一样可以因为它们都不会吹口哨，将他们抽象在一起，但很明显我们不该这么干，这就是偶然性内聚。最希望出现的内聚是功能性内聚，即一个类或模式的各元素一同工作，提供某种清晰界定的行为。比如我将消防栓、灭火器、探测仪等内聚在一起，他们是都属于消防设施，这是功能性内聚。
3 充分性
充分性指一个类或模块需要应该记录某个抽象足够多的特征，否则组件将变得不用。比如Set集合类，如果我们只有remove、get却没有add，那这个类一定没法用了，因为它没有形成一个闭环 。不过这种情况相对出现较少，只要当我们真正去使用，完成它的一系列流程操作后，缺失的一些内容是比较容易发现并解决的。
4 完整性
完整性指类或模块需要记录某个抽象全部有意义的特征。完整性与充分性相对，充分性是模块的最小内涵，完整性则是模块的最大外延。我们走完一个流程，可以清晰得知道我们缺哪些，可以让我们马上补齐抽象的充分性，但可能在另一个场景这些特征就又不够了，我们需要考虑模块还需要具备哪些特征或者他应该还补齐哪些能力。
5 基础性
充分性、完整性与基础性可以说是3个相互辅助相互制约的原则。基础性指抽象底层表现形式最有效的基础性操作（似乎用自己在解释自己）。比如Set中的add操作，是一个基础性操作，在已经存在add的情况下，我们是否需要一次性添加2个元素的add2操作？很明显我们不需要，因为我们可以通过调用2次add来完成，所以add2并不符合基础性。
但我们试想另一个场景，如果要判断一个元素是否在Set集合中，我们是否需要增加一个contains方法。Set已经有foreach、get等操作了，按照基础性理论，我们也可以把所有的元素遍历一遍，然后看该元素是否包含其中。但基础性有一个关键词叫“有效”，虽然我们可以通过一些基础操作进行组合，但它会消耗大量资源或者复杂度，那它也可以作为基础操作的一个候选者。
抽象的品质可以指导我们抽象与建模，但总归还是不够具象，在此基础上一些更落地更易执行的设计原则涌现出来，最著名的当属面向对象的五大设计原则 S.O.L.I.D。