关于API的设计和需求抽象

一，先来谈抽象吧，因为抽象跟后面的API的设计是息息相关的

有句话说的好（不知道谁说的了）：计算机科学中的任何问题都可以抽象出一个中间层就解决了。

抽象是指在思维中对同类事物去除其现象的、次要的方面，抽取其相同的、主要的方面，从而做到从个别中把握一般，从现象中把握本质的认识工程和思维方法。

在计算机学科中，抽象也称为模型化，源于实验科学，主要要素为数据采集方法和假设的形式说明、模型的构造与预测、实验分析。结果分析。在为可能的算法、

数据结构和系统结构等构造模型时使用此过程。抽象的结果为概念、符号和模型。在图论中体现的是抽象与理论形态，欧拉从哥尼斯堡七巧板问题入手，将其抽象为边和点的问题进行研究，成为图论研究的先驱。哈密顿回路、中国邮路等问题都是对现实问题进行的抽象，这些问题的研究和解决形成了一套比较完整的关于图的理论，包括一系列的定义、公理和定理等。

首先，人脑往往不适于长幅记忆或直接面对复杂的二进制底层，人们在面对根本无法控制的事情时，往往把它们转化为另外一件可控的事抽象正是这样一种方法，它可以隐藏低级层面的复杂性，而在另一个层面上提供新的更为强大的能力。再在这里抽象上构建更为高层的抽象，即抽象只是把问题变了个形式，抽象完成了之后，只要不是过度抽象，那么所有后来的事情都是另外一回事了，抽象是解决移殖问题最好的方法，抽象源于一个简单的事实，把事物从逻辑上分开，这样就会解偶他们之间的联系。只有把接口拉高，向高层抽象，那么就可以忽视平台逻辑，其次，从问题到解决不是一步而就的，所有需要建立中间层，先完成这诸多中间层，当中间的逻辑被解决的时候，事情自然就变得简单了(从这个意义上来说，世间一切软件都是抽象品，软件即抽象)，抽象的本质在于远离问题，从靠近人的一个高层角度去解决更高级的问题。 但是抽象的优点正是它的限制性，它可能带来再大的复杂性1，一般抽象到了某个程度，为了获得计算机作为底层的冯氏能力，，就不应该再抽象下去了。开发模型不需要再变了，数据抽象到数据结构级就是顶级了，再抽象就不是开发问题了，现在的虚拟机的提出，都是基于已有的模式,直接参照硬件上的机器设计中断,模拟数据类型等，从来没有那个虚拟机，其内部结构不是图灵模型，因为如果那样的话，它上面的开发模型将不再是数据加代码的方式。从来没有人突破过这个创新。仅仅因为大部分人没有想过，或根本无法尝试。其次，抽象就是编程界对事物方方面面的范式的一个界定。但一般的，抽象是抽取对象的可用部分，我们从来都是抽取事情对于我们的可用部分，所以设计时千万不能做大而全的抽象。

抽象都是有唯度的，数据结构就是基于数据化类型的唯度抽象了开发中组织内存的套路，而高级语言机制或范式基于多样化写代码的唯度抽象了开发，设计模式是基于设计抽象了应用，而设计，就是人的事情了，处在前面数据结构，范式，应用的所有实际上软件的设计哲学是可以用来解释一切的,因为它是真正的哲学,而真正的哲学并不仅适用软件开发(软工和计算机是二个完全不同的抽象,虽然没有人提出过计算机抽象到底是什么,软工抽象到底里面有哪些抽象存在,我们仅能站在某个或某些唯度上给出一个描述性的概念而不是有限集,这也就够了,如果能站在一个大全的唯度上说明到软工的全部抽象,虽然这是不可能的,但我们还是给得出的这个结果取个名字,叫范式,范式在意义上是大全而的抽象,然而人类的范式总表现为某些唯度上的产物上面层次。下面详细介绍这个唯度的概念。

我们来问个问题，程序如何分类呢，从算法和数据结构的角度看我们可以发现，数据结构加算法等于程序。因为数据结构源于从一套相似的算法中找出操作对象的共性这个现实，而从复用来看呢，，又可以产生设计和接口就等于程序这种说法，因此这完全是不同事物的不同唯度而已。根本没有可比性。（至少二者都可以产生程序这个概念，于是，程序=机器加电也是正确的）抽象把事物的复杂度换化到另一层面，实际上也是另一唯度。这就是抽象与唯度。其实就语言本身来说,并没有汇编,C,C++和Java,Python,Ruby这几个语言之间哪个语言更强大一点的说法,大凡用其中一方能实现的功能,用一方都完全能够抽象得到,Java所关注的Web编程领域,C++完全可以提供同样的功能实现, 只有抽象完成,整个Windows系统都可以用Java来写,这就是说,在软件的抽象里,任何事情都可以以抽象叠成的方式来完成.但是，“决定用什么语言干什么事”这个前提是“它善于干什么事情”，而不是“能不能”(而这，是由应用本身和人的要求所规定的)，所以显然地,在Wintel上装个Jvm,再用Java实现个Windows,这是个傻瓜行为(舍近求远而且有应用的瓶颈问题存在).比如用C进行C++能很好工作的事，这也是个傻行为（仅仅因为C没有显式的OO设计手段虽然它可以抽象得到）。

过程抽象的概念是程序设计语言的设计中最老的概念之一，所有的子程序都是过程抽象。因为它们提供了一种方式，让一个程序说明要完成的某些过程，而不是要提供如何来完成的细节，以使程序设计的过程逐步趋于简单化。例如：当一个程序需要将某种类型的数值数据对象数组排序时，它通常使用一个子程序来进行这种排序过程，在程序中需要进行排序的位置。过程抽象对于程序设计过程十分关键，这种将子程序中的算法的许多的细节抽象出来的能力，使得人们有可能来构造、阅读和理解大程序，现在被认为的大程序必须至少其有好几十万代码。

所有的子程序，包括并发子程序和异常处理程序都是过程抽象。 数据抽象必然跟随着过程抽象的发展而发展，因为每一种数据抽象中的一个不可分割的中心部分都是操作，而操作被定义成过程抽象。

数据抽象的动机之一与过程抽象的类似，它是对抗复杂性的一种武器，是使得大型以及复杂的程序比较容易管理的一种方法。

在程序设计当中，所有内置数据类型都是抽象数据类型，例如：考虑一个浮点的数据类型。

在高级语言中，封装是抽象数据类型的先驱及支持机制。一个封装可以分割编译或者是独立编译，对一组相关的计算机提供了一个抽象系统和一个逻辑组织。

抽象思维方法本身随着人类文明的进化也在不断演化。从大类看，抽象思维方法分为抽象思维的形而上学方法和抽象思维的辩证方法。抽象思维的这两种具体形式不象有些人认为的那样，是对立的和没有共同基础贩。实际上，抽象思维的辩证方法是建立在抽象思维的形而上学方法之上的，在运用分析、综合、归纳、演绎方法来形成概念并确定概念与概念之间演绎的关系、概念外延的数量属性关系这些内容上，抽象思维的辩证方法和抽象思维的形而上学方法完全一样；只是面对发展和变化着的世界，为了提高思维的形而上学方法完全一样；只是面对发展和变化着的世界，为了提高思维的精确度从而减少思维对现实的偏差，抽象思维的辩证方法才增加了对概念内涵的数量属性关系的考察。可以说，抽象思维的辩证方法是对抽象思维的形而上学方法的补充的提高。

二，API的设计

1.为了设计API对你如此重要呢？

----如果你是程序员，那么也可以说你是一个API设计者：一个好的代码，实际就是模块和模块之间有一个API

----有用的模块需要考虑能复用：一旦一个模块有用户了，那么就不能随意改变API了。（因为对于用户可见的是API，如果改变它，用户相当于使用一个全新的产品，需要花费更多的精力去学，即使有详细的文档保证）；好的可复用模块之间都是能很好的互相协作的

----在你写代码的时候，思考API如何设计，能提高代码质量

2.一个好的API的特点

2.1易学

2.2即使无文档保证，也能轻易使用。（也就是我看到API的时候一目了然，这涉及到函数命名，参数安排的问题）

2.3难以被错误的使用（同上）

2.4容易读懂，保持原有代码

2.5很好的满足需求

2.6容易扩展

2.7对于用户来说适当

总结：感觉以上很符合Unix设计哲学，KISS原则无处不在啊

3.API设计过程

了解明确需求，思考需求（持有怀疑论的态度反思）

-----更好的解决方案是存在的。（没有最好，只有更好）

-----能使用更简单更有效的方法来构建一件“事物”，让此“事物”变得更普适。（这也说明了软件接口越往上层越普适，不会依赖于平台相关）

3.1先写以小段API的规范说明书开始（保证说明书短小容易修改，API的输入尽量满足多数人所需要的）

3.2提前设计API，不管其实现细节。然后再API的实现过程中，慢慢再完善API的设计，对其做单元测试

3.3插件式的API要保证能够以多种方式来实现。

3.4保持API最现实的异常处理情况，大多数API都要设计成强约束的，因为你不能够迎合每一个用户，在异常处理方面，对于每个用户都必须严格校验。考虑API出错（不理想），经过现实时间的工业检验，这些错误都会慢慢暴露出来的，然后你再去修复。

4.设计API的基本原则

4.1 API的功能必须很简单就能解释清楚，不能复杂。如果对一个API很难命名，那么就说明这是个糟糕的设计，功能抽象做得不好。

4.2 API要尽可能的小，但是不能太小。API需要满足它的需求。当遇到错误，需要及时处理跳出。API的概念比API实现体积重要。你能添加API，但是不能删除它。（保持兼容）。API的参数不能过多，否则依赖过度，说明抽象不好

4.3 API的实现完全不影响API本身

4.4减小API之间的依赖性

4.5从API的名字就可以看出功能，阅读代码像读散文一样。（就是容易理解）

4.6一个好的文档也是重要的。