新手编程导论（六）

天狗

第5章 抽象
某某牛人说过，增加抽象是一切解决问题的方法！！
时代改变了！！以前是手工软件作坊时代，，现在是软件工程时代！！！

5.1 人与软件
应用越来越接近人了,比如web2.0,3.0的出现,这是指软件产品的应用,实际上在软件被作为产品被产生出来时也作了靠近人的调整,编程领域的三个东西,问题域,方案域,人都在相互影响,这种影响产生了一些技术,导致了一些编程的变革,并最终与人们的观念结合,比如OO,比如设计模式,这也将导致架构变成软件的功能性"实现"要考虑的,在某个维度上加深了复杂度,然而却在另外一些维度上提供了简单的形式和更有效的应用
某些东西越来越统一和规范了,这加大了学习的门槛,比如xml出现,就统一了文档交互的格式,并导致了很多逻辑知识,产生了一些新的逻辑,需要被学习,但这是合理的,因为形式更加简单了统一了,并改变了一些应用的形式,比如软件分发delopy的统一形式等,
另外一趋势,应用越来越分布了和趋向web,这实际上是很多年前某些大公司的战略,总有那么一群人(有些人研究应用形成架构,有些人研究编程低层形成架构和思想),先知先觉地认识到一些东西,比如.net的出现,网上的资源服务器越来越变成一般应用服务器,富客户端的flex,silverlight等等,只是它们是慢慢被民间所识所学习.
一切技术都是面向被应用,因此人无论如何都是主导.将反过来最终影响技术的被利用形式而隐藏了低层实现,一些离最终应用跨度太大的低层实现不必知道其原理,靠近人的一端要提供尽量简单的形式,比如xml,比如oo,面向机器的一端永远有它的实现

5.2 软件活动的特点
别空想设计，设计也是源于迫切要解决的问题(设计跟需求分析有关)，你说的设计需要可能是一个空想的禁固。。
软件需要你考虑每一个细节，因为这不比盖房子，，做软件需要你从大量小逻辑促成应用(每一个部分都可能需要你造轮子)。
方案域用于表达应用的抽象元素只有类是最大的，库是最大的，这种细小性决定要去的地方，要达到的应用还很远。软件活动是一个真正体现人类心智的地方。是一个真正工程级的活动(程序员作为实现者可以不懂大设计和系统级的设计，但设计师要管)。
而且现实生活中软件活动通常都是变化的：代码在变化，设计在变化，连需求都在变化。
C++为什么不是单一OO泛型而是多泛型的呢，因为设计就是多选题，你无法找到其单一性，这就跟policy based design一样的道理。
实际上，软件的设计可以不具有任何需求的成份，，只是在人类的具体活动中，往往需求会影响设计而已。。
模式分为三种，问题模式，设计模式，代码模式，MVC是一种表达窗口的现实问题模式，此时用mvc复用设计模式就最好表达了。而mvc被policy based design实现了，所以它首先也是一种代码模式了。
设计期聚 集于程序员，运行期聚 集于用户，，比如当设计深入应用时，语言的设计和运行功能都要很强，，设计时不可能预测用户点了什么菜单。


5.2 抽象与接口
什么是架构,架构是设计的上上层部分..比如网络七层模型,甚至PC的冯氏模型..这些设计的上上层部分深刻影响了计算机后来的东西.不可轻易更改.
不可思议的不是代码，不是编码，而正是人类的大脑，而正是设计,,
在设计一种平台时,语言和OS是一个架构的基础部分(在OS内部更多地存在设计)，应用再在这个上面慢慢搭建.
如果你看过google的手机平台设计，就会发现语言这个图灵装备往往是架构的最基础部分。如果说机器语言或汇编语言是严格基于平台逻辑的,那么高级语言基于严格的语言机制和语言语法,具有严格的图灵装备,,负责产生后来的逻辑和用户级的应用逻辑,本来OS是不需要语言的
语言尽可能小，直接面向真实平台不要虚拟机,因为加了虚拟机执行方式会很慢,,而且,语言应作为OS的内核一部分.就像WINDOWS把GUI接口加入core一样,这样的语言执行效益很快.这样的语言也就称为系统开发语言..与之对应的是应用开发语言,或称脚本语言.
在底层,汇编是一种几乎对应机器语言的东西,因为汇编语言无语法.只是名称指称，助记符..C作为中间语言,汇编只需要提供接口给C，C还应在编译期提供一个编译期多态
为什么脚本语言多称为语言粘合剂呢..因为脚本语言往往提供对多种系统编程语言.数据类型的内存模型的封装.提供了对这些语言的多种接口,,,但更主要的,脚本语言被称为脚本语言,,,更在于它面向用户的其它特域相关和特定工作相关的语言机制(比如Lua的多协程常被用来游戏,,而这显然不是通用语言应在语法级应提供的)也许脚本语言只需要提供与其它语言的粘合接口就可以了
在上层,我们应该提供一种"无语法"语言的DSL脚本(比如SQL,好像脚本语言跟解释型语言几乎同意),,这种语言最好还是无类型的,,这样做的目的是方便程序员,但不好用来开发平台逻辑(因为平台语言,要求严格的类型机制)
这种语言是自然语言描述性的,,重复性的句子并不会产生双份的运行负担
设计应该被配置，而不是被编码,设计语言应是一门非图灵完备的独立语言(要考虑到它的通用性而不是DSL就更好了)。
我们看到的大多数语言都是图灵完备的,而我觉得C++应改编成一个解释执行、无语法的语言,因为应用语言往往需要做成即时修改的脚本语言
应该如何设计接口呢,OO=抽象+接口,,那么其体现又是怎么样的??只有深克地分析了应用和计算机本身，你才能分析出通用和最精简的接口机制,而OO正是这样一种机制..因为类=数据加函数,,数据加函数既对应计算机世界,又是解释现实事物的一种机制...当然.OO不单是这种理念,还要学习它的运行期多态,继承等(语言语义)..
学高级语言应不仅学它语法,而且要学它语义..因为被翻译后的代码才是代码最初被产生的地方,是最应该被研究的..
接口应尽量窄,提供尽可能少的东西,,但在概念上一定要广,,以备后来的扩展需要.这样的接口,对于复用来说,也是可以花最少的精力来学习的.什么是抽象呢,,,就是抽取对于人来说象的部分....把多种特征的东西在概念上整合为一个认识,,,抽象出接口就是这个意思...其实,抽象正是为了简单,,而不是复杂化(它只是极力把复杂化的低层细节隐藏,透露给人们一个通用的,可认识的抽象概念,即接口)
deepest concept,lowest interface = min learning
对接口编程即，将需要维持不变的东西，即设计，维护在接口层，即变化的东西，实现，维持在接口层以外的地方。
如何从以上二种机制理解OO呢,,,OO为什么这么流行,,因为OO“很好很强大”..

天狗

5.3 过度抽象
C和C++只是抽象多少的问题(对硬件架构和软件系统，构成的系统编程环境进行抽象，以靠近人脑开发)，linux之父还跟别人争得起烟,,在Windows的GDI中,用C实现了一个对象系统,连C都抽象了桌面对象,还有什么不能抽象的,,,只不过C++在语言级实现了一个OO而已（而ＷＩＮ的桌面环境对象系统是在逻辑库级）,
一个问题出来了，，抽象显然是为了简单化，但是这是对系统编程环境的简单化，，在高级层次会造成更大的复杂，但至少脱离了大量需要原来人脑去维护的细节，　人们只需要掌握大概就可以去复用了(接口)，，，这是一个很大的进步，，，而且有些被实现了被开发过的东西和轮子可以直接被拿来复用，Ｃ代码却要基于平台的考虑修改大量细节，这种修改的代价超过了太大，就没有可复用性了，，，所以无论如何，C++比起Ｃ，，使人们掌握细节和系统的机会减少了，但需要人们掌握设计和复用上的知识多了（人们更专注应用领域）．而且在这个时代,由于JAVA语言这样的语言的出现,语言标准得于统一,因此可复用性首先不用考虑语言本身,更而且,JDK统一,SUN的J2EE规范统一,,可复用性就成了人们之间的契约文化了,可复用性的地址会越来越下降．Ｃ的难点就在于系统本身，，系统细节和语言细节都过多，，造成人们掌握它的成本过大，但Ｃ的代码没有绕ＯＯ的弯子，跟系统逻辑几乎一致，因此效率很好。
什么是过度抽象呢？如果抽象不是提出一个简单模型，而是在封装的基础上提供了一个很复杂的模式，甚至超过了人们学习Ｃ和系统的那些知识，那么这种ＯＯ模型（或称呈现的供可复用架构）就是不成功的，
模块化也是一个重要方面，设计中的抽象过程固然要求模块化，但这决不是抽象的终点，，因为有时虽然模块化了，但是模块之间却偶合了。所以，科学的对于问题的抽象应该是模块化加松偶合的过程。

5.3 OO为什么不是银弹 - 过度抽象与抽象偏差
C的程序员在用C++表达数据结构与算法时，出现了二种情况： 要么写出来的东西虽然被套一个class名字，实际上还是过程编程 要么虽然能类化相关概念做到真到的面向对象，但是感觉不如C的三种流程来得直观，感到OO很别扭。（参见stl的写法和对stl的使用，还有你能找到的OO实现的数据结构库）
实际上人们已经习惯于用三种流程来表达数据结构，跟类比起来，三种流程加简单数据类型的语言机制已经足够。如果再强制他们使用OO来表现。那么他们实际上做了二件事： 对数据结构和算法能解决的问题做了解决（数据结构） 对代码进行了抽象（代码结构）
我们知道OO是C++带给程序员的抽象机制，对于了解这层抽象的人来说，他可以很灵活地写出质量好，逻辑清楚的类(比如STL的作者，虽然那是template class类，泛类，但我们这里还是把它作为OO的类来看待)，但是如果回顾学习过程，大多数人会觉得诸如迭代器,type榨汁器这样的东西是晦涩的东西。 原来C程序员做的事，换到C++程序员（当然，我们这里指的是真正会用OO来写程序的人）来做，他必须完成上面的二件事，对于不理解它的人来说，他觉得简单的语言机制都能解决的问题，为什么硬要套上一个class呢？这就是过度抽象给程序员带来的麻烦。对于了解它会使用它的人来说是利器，对于不会使用它的人来说实际上是障碍。抽象的好处是某一个层面上的相对容易性（比如OO将复用维持在public member,protected member等接口上），但是在另外一些层面会对不理解它的人造成更多层面上的迷茫。
面向对象程序员之间很容易写出质量参差不齐的程序，有的人写的程序用了大量迭代器之类的抽象概念，有的程序员写的程序全是class pig,class cat之类的实体概念。对于前面程序员写的程序，如果不能理解，基本上很难复用(即使有class public member在那里)。后面程序员写的程序，有时又会显得太繁琐(比如他会把一些不该抽象的东西抽象成为猫爪子，而实际上并不需要这层抽象)。
抽象给人带来的好处和坏处并存，对于多人合作的软工项目来说，一些语言的机制是禁忌，比如模板，他越抽象，就会造成越来越大的混乱，OO虽然统一了代码形式为类，但并没有统一设计和抽象的方法(在同一个应用中，有人会写迭代器，有人会写阿猪阿猫)。所以OO并不是银弹，银弹是那些能统一人类思想，形成契约文化，经验的东西（比如我们说小说的那些套路），而不是简单的class这种面向复用的小技俩。 而在软工界，除了OO，实际上还存在很多很多其它的过度抽象。
谨以此文自娱。

5.4 真正的设计与编码
大师的禅语并非无所指，一切都只是因为我们并没有拿到那个水晶球而已！！

比如：

不要拒绝接受所有的观点（当你是某个领域的专家时，你往往是寻求别人的思想跟你已成体系的思想的相合之外，，有取舍地学，，因为你有自己的理念），，也不要不接受任何观点（当你对一个领域还是一无所知的时段，，你的最主要任何是无条件理解和接受别人的思想）
学习的四段决
想，，想，，，还是想（一开始是对细节的学习），，，不要一直想（当你有自己的理念时），，，，
思想本非也不该是高高在上的东西，只是我们没有勇气跟它平起平坐而已，而且求知的你只是缺少一个求知切合点而已（这就是每个人心中的“实践认知”，，某个特别的维度认识）。
因为这三个思想实在太重要了而它们又独立于所有知识，更并且，它们不被任何其它书籍提到并组织，所以在这专门作为一章来讲解：）


软件开发过程分设计和编码，组织这二者(以及对其它细节的工程可控性要求)的工程化方法就是XP啊，UPS啊什么的，设计阶段的工作是可以涵盖整个软件开发过程的，而且可以跟编码同步(一旦已经在写代码，那么你就开始在设计了)或异步（最好还是先想好设计的每个细节）进行，
与设计模式相比，算法体现的是一种更泛化的问题解决方法的说法(或者说它更测重于说明如何实现能不能实现，而设计体现是如何设计，要设计出什么架构来表达什么逻辑达成过程)，在《领域数学》节中提到的算法是数学界对于问题的Solution(VC7以上的工作空间被称为Solutiom).
设计的严格意义是广泛的，，
我们这里说的设计是指定义某种思想上的架构（软件架构往往是一种思想构架，然而必须最终在代码上体现出来，，设计模式也可称为架构模式（实际上设计模式可用在大架构或小逻辑上都可）或逻辑模式，），然后在这种架构下编码构建应用(世俗的眼光里好像编码的地位一直要次于设计^^)，这不是一种泛思想的活动（虽然严格意义上的设计的确是泛义的），而是面向产生类文件的设计，但我们正对事物或问题进行设计，所以在源端是非常不确知的高构，在目标端是一定要产生类文件，
因此编程界(注意这三个字)的设计有三种
1. 基于通用设计传统的设计,比如采用一切语言级和非语言级的多范型设计
2. 一开始并不直接面向编码的原语设计，后来才转为面向编码的范型设计
2. 技术上用策略来实现的设计
3. 混合了你自己创建出来的一些架构思想的设计
用原语设计去主导你的设计，再用修饰过的原语设计去主导你的多范型设计(有效的设计应分分这二步)，最后才产生类文件。。
现在很多领域都向原语发展（人们正在更好地认识这个世界），，比如下面的一张图，左边是设计（偏重思想），右边是实现（编码），左边在不断地靠近右边
1.类是对对象的设计，，，模板是对类的设计，
很多现象表明，编程正慢慢向设计偏移，细节正慢慢向它所属的大领域靠拢

天狗

5.5 真正的构件库
构件是运用了组合的思想之一，然而组合是一种更大的思想，有些时候，组合的个体之间并不需要接口，，只是当它们运作起来，它们便突然构成了这个璀璨的世界。就像这个世界，水，火，大海，高山并不是某个神预谋为了某种美感而创立的，神只是分别创立它们（没有留专门的接口吧？），然而它们各自存在而已，然而突然有那么一天，神创建的人类突然发现这简单的组合也是这么美和合理。（请原谅我用了这么一个不严格的神话来描述这种思想，然而作这种泛化思维有好处的）
在编程领域，库跟构件严格上是二不同概念，然而大体上等价，这里不区分二者。
按使用形式分构件一般有五种
1． C的库，可能是运行时库，语言函数库，用户发布的应用库，OS级的API库，等等，这些库由于往往只有函数级的接口，因此只要明白参数调用或入栈规则就可以了
2． C++的库，这种库也可以是上述四种库，这些库由于是用C++写成，可能采用了OO，因此其内可能含有某种架构，我们必须懂得其内置的架构才能更好地使用它们。
3． 接口库，比如COM，这种构件就是严格意义上的构件，因为它直接内置接口定义，需要懂其内置的架构才能更好使用它们，更高级的还有DCOM等
4． 构件套，比如ActiveX(主要用于网络分发)
5． 类JavaBean直接为编程环境服务的组件。

这几种库一般都用DLL来实现，DLL是一种装载机制(它可以在运行期动态装卸，比起静态库的另外一个优点来说就是可以避免双份的库引入)，而构件是构件，这种关系要明白
一个很重要的思想，千万不能让库的架构主导你的原先的架构，，你永远有你自己的大智慧（在你的应用中你有自己的架构逻辑），也不要做严格的学院派高手去研究某个库的接口实现（设计一个好的库的架构也是一项大工程），除非你是为了学习，否则不要去探究它的实现，而且库的架构不必复用到你的架构中，你永远只是库挑剔的顾客与使用者。
按组合关系来分库存在有平等关系，上下关系，多对一关系，比如有三个库



如图，库A与B，C是上下引用,也是一种一对多的引用(单向箭头)，库B与库C是独立平等的关系(可能BC并不引用各自的逻辑，说它们平等只是相对要引用它们的A来说的)
这种构架就是我们呆会在第四部分提到的总架构,库A是GameGeneric,库B是ShowGeneric,库C是LogicGeneric,当然在每个库下面还有很多库引用关系
什么是上下关系呢？就是说谁更靠近应用谁就是上，平等关系就是它们作为中间逻辑靠近应用的程度是一样的（这主要是因为它们为共同一个库提供逻辑，而那个库更接近应用，比如这里的B，C对A的关系）
按性质来分有架构库和工具库(库都是中间逻辑的封装者,然而这中间逻辑也有“是架构”还是“非架构”之分),非架构逻辑就是或工具函数（实现逻辑），架构逻辑就是对一种思想模型的描述，，对其它库的引用逻辑，使用逻辑（封装逻辑），通过这种方法，将利用外来库的行为封装为自己应用的架构
我们在这里反复提到架构与实现，那么到底什么是架构呢，广义的架构就是中间逻辑互饰以构成最终应用的过程中，出现的一切中间逻辑间的关系(无论这些中间逻辑有没有被封装成为库)这就是架构，，，狭义的架构就是指反映设计中某种物体模型的逻辑层次(比如我提到的GameGeneric由表现和世界逻辑组成云云)
比如上图中，中间逻辑的有穷互饰就会形成最终应用逻辑，但是中间逻辑这个说法永远都是相对（于最终应用逻辑）说法，越靠近最终应用的中间逻辑越是高级逻辑
要知道，，抽象达成到最终应用中，，需要设计的接口（这里主要指函数级的）精度和量度都是巨大的（可以用单逻辑的类文件，也可用库来集成一些逻辑作为二进制的中间逻辑，但是如果是使用别人的库，，那么往往需要作对它的引入逻辑，也即对这个库的使用逻辑，，也即你自己的接口才是你的应用主体，别人的只是拿来用的（并形成你的应用的接口），，比如Yake对其它的库的引入逻辑），为了未来的更好复用性考虑，越远离应用逻辑的接口，，对它的设计应尽量考虑接口上的放大化
GameGeneric向你透露面向游戏和脚本级开发者的那些接口(包括它自己的一些逻辑，和一些对库B，C的封装逻辑也即入接口逻辑，库A向用户封装了B，C的细节而提供一个大接口给用户使用，当然库A可能也有它自己的逻辑和架构),这些接口是直接面向高阶应用和开发的需要而创立的，既然GameGeneric建立在B，C之上，那么在引用A的时候(利用A进行编码实现或在其上面架构更高层逻辑的时候)，B，C是不是变得无可访问呢？不是，我们其实还是可以在这个步骤中访问到库B，与C的内节的(库的组合逻辑绝非一方屏蔽一方而是一方对一方的归纳简化和扩展导出)。
这是为什么呢？因为大架构是供你使用架构下的细节的（这后半句话才是重点），，大架构只是逻辑归约以更好面向程序员，它是逻辑简化而非逻辑替换，，而程序员最终要引用的逻辑是架构下的细节逻辑。。
是的，，明白这些有什么用呢？？但是反过来想一想，，如果连这都不懂，，，那么那才是你的损失之处呢^^（因为这是实践思想，，很多书都不会讲到）

5.6 大逻辑与小逻辑
SOA,COM,框架,这样的术语着眼于解决大逻辑间的开发,而不像OO语言本身只能将逻辑提供到类这一层次(虽然宠大的类也可称为大逻辑,但我们这里仅指有限属性和行为的类逻辑)
C跟JAVA是二种完全不同理念的语言,因为它们的运行环境不相同,产生的目标码根本不同,前者是为机器加OS这个本地产生目标码,而JAVA为JVM产生目标码,由于这二个平台的不同导致的理念是根本的差别,JAVA不能称为系统编程语言,因为这个系统指代OS,C是编译成本地目标码的,而JAVA码只能称为JVM的系统编程语言.VB5之后有编译为本地码的特征,因此是半系统编程语言.
C跟JAVA是二重天,因此对它们的开发理念完全不同,一个是面向本地,一个是面向JVM,可以不管OS平台的任何差别(这就是说不用学习程序运行环境给语言带来的机制问题和复杂细节,不用学习关于JVM的任何知识来进行JAVA编程,人们只需关注那些他们要完成的逻辑,而平台逻辑可以忽视不顾,因为JVM被移殖到任何地方时,人们将面对毫无差别的JVM和JAVA代码,代码不会因为平台不同而产生新的要解决的问题,,这是指移殖,,而且,要写JAVA代码,也不必了解任何JVM的知识,,因为根本没有必要为JVM编程,,JVM虽然能给你进程,,给你SOCKET资源,但是在库中已经被妥善地封装了,人们对它固定了一个认识,,不必从JVM中再对它们经过原始理解,再引申为JAVA所用,因为关于这些资源的接口足够简单了,减少了人们对系统的理解,一谈到虚拟机的语言,就要明白这跟C,跟C++这样的编译语言是二重天).人们说JAVA并非好的教学语言,因为JVM毕竟不是我们真实的系统,,它是一种架空的虚拟的完美的人工运行环境,而OS加硬件架构这样的本地才是我们要认识的本地,

5.7 什么是范式
在最开始，可将范式想象成一种特别聪明、能够自我适应的手法，它可以解决特定类型的问题。也就是说，它类似一些需要全面认识某个问题的人。在了解了问题的方方面面以后，最后提出一套最通用、最灵活的解决方案。具体问题或许是以前见到并解决过的。然而，从前的方案也许并不是最完善的，大家会看到它如何在一个范式里具体表达出来。尽管我们称之为“设计范式”，但它们实际上并不局限于设计领域。思考“范式”时，应脱离传统意义上分析、设计以及实施的思考方式。相反，“范式”是在一个程序里具体表达一套完整的思想，所以它有时可能出现在分析阶段或者高级设计阶段。这一点是非常有趣的，因为范式具有以代码形式直接实现的形式，所以可能不希望它在低级设计或者具体实施以前显露出来（而且事实上，除非真正进入那些阶段，否则一般意识不到自己需要一个范式来解决问题）。范式的基本概念亦可看成是程序设计的基本概念：添加一层新的抽象！只要我们抽象了某些东西，就相当于隔离了特定的细节。而且这后面最引人注目的动机就是“将保持不变的东西身上发生的变化孤立出来”。这样做的另一个原因是一旦发现程序的某部分由于这样或那样的原因可能发生变化，我们一般都想防止那些改变在代码内部繁衍出其他变化。这样做不仅可以降低代码的维护代价，也更便于我们理解（结果同样是降低开销）。为设计出功能强大且易于维护的应用项目，通常最困难的部分就是找出我称之为“领头变化”的东西。这意味着需要找出造成系统改变的最重要的东西，或者换一个角度，找出付出代价最高、开销最大的那一部分。一旦发现了“领头变化”，就可以为自己定下一个焦点，围绕它展开自己的设计。所以设计范式的最终目标就是将代码中变化的内容隔离开。如果从这个角度观察，就会发现本书实际已采用了一些设计范式。举个例子来说，继承可以想象成一种设计范式（类似一个由编译器实现的）。在都拥有同样接口（即保持不变的东西）的对象内部，它允许我们表达行为上的差异（即发生变化的东西）。合成亦可想象成一种范式，因为它允许我们修改——动态或静态——用于实现类的对象，所以也能修改类的运作方式。在《Design Patterns》一书中，大家还能看到另一种范式：“继承器”（即Iterator，Java 1.0和1.1不负责任地把它叫作Enumeration，即“枚举”；Java1.2的集合则改回了“继承器”的称呼）。当我们在集合里遍历，逐个选择不同的元素时，继承器可将集合的实施细节有效地隐藏起来。利用继承器，可以编写出通用的代码，以便对一个序列里的所有元素采取某种操作，同时不必关心这个序列是如何构建的。这样一来，我们的通用代码即可伴随任何能产生继承器的集合使用。