bianchenzhenyan.txt

一部关于编程设计方面的箴言级的书籍

?? 真正的原语抽象
原语就是Generic,原语强调的是一种泛化与发散，它把我们考虑问题的范围（一般是设计阶段而非编码阶
段，在详尽地考虑了所有细节的情况下编码只是机械的活动，而设计是可变的活泼的）放大到整个人类的
认识，我们称之为人类认知空间，对于某个具体问题或事物，不只是编程界对它们有抽象（编程界对现实
事物或问题的看法或解法的抽象属于编程界专用的抽象，诚然，编程的确可以产生一个网络游戏中的道
具，比如一个加血瓶，然而编程并不能真正为你产出一平加血瓶，有它独有的局限），还存在其它领域对
现实事物或问题的抽象（系统架构师好像就是编程界的真正的思想家，分析系统就是真正的一场思想活
动，除非编程界有现成的抽象方案可以直接拿来使用或借鉴，否则他独立看待事物以进行编程抽象的视角
和广度是受他本人认知和思维能力决定的，对于一个东西，系统分析师看出它用于编程的那些用法，而一
个教育工程师可能看出其它的用法，即便是网络工程师，虽然跟系统分析师同处IT领域，也会看出对他们
有用的东西），但是无论是各行各业，只要是都属于人，都局限于一个共同的“人类认知空间”（除了那
些未被认知的事物或问题之外）。这就是“问题或事物原语空间”，各行各业有它自己“经过抽象了
的”的看法或解法
不管是已认知或未认知，事物或问题总有它“最大的原语空间”，我们把经过编程抽象的事物原语称
为“事物或问题编程中的原语空间”，称为“具体事物或问题的原语（有时空间二字可略）”，这显然是
一个子集空间。原语空间就是领域Domain，各个问题都有它被提出和讨论时的领域，比如IDL语言，IDL
现实世界(问题或事
物原语空间)
未认知
已认知
人
经过领域抽象的原语(总看法和解法)
编 程 抽 象（编程界
与现实结合点的事
物）
编程界传统看法与
解法
其它领域抽象
被抽象形成
思考
导致设计与算法
1,原语设计,面向编程的多范型
设计
2,通用解法,面向编码的OO解
编程新手真言 - GameRes.com 页码，10/101
mhtml:file://F:\Cpp\编程新手真言.mht 2008-7-30
是一种领域语言(Domain Lanuage,可以专门开发一门领域语言用来开发一个领域内的应用)，COM是一种
高级的构件，因为它直接提供了对接口的支持(接口可以仅仅指API，这是一个特例，接口泛义为“位于二
个东西中间起适配作用的桥梁”，因此它还可以是库啊，结构体这些意义的接口，这种泛化思想就让接口
成为一种原语，自然有它提出来时的原语空间和当以后不断发展时所形成的更广泛的原语空间)，所谓接口
也是一个领域空间，这IDL语言就是根据一种“接口语义(也就是接口最终能表达的原语空间内的所有意
义)”来定义出来的应用方案(问题方案就是接口原语)
泛化诚然跟抽象不同，虽然二者都强调从低向高层演化，然而泛化更着重思想范围的扩大，而抽象强调的
是一种思想的深度和高度，即能从普通现实得出本质性认识的过程，经过抽象的事物要么是事物的一部分
（经过抽象的事物压根儿就不是事物的原形，只是一种被修饰或刻意片面化的事物变形,这种变形是对抽象
使用方有利的）,要么是解决问题的中间层（比如要实现一个带花园的洋房，这是一个原语问题，如果不仅
仅是从编程领去看去解，那么原语解法一般是从材料到房子，从没有装修的房子到洋房，从没有花园的洋
房到最终带有花园的洋房，我们总是一步一步来解决问题的，但是当我们想考虑这个问题的某一步时，我
们并不想考虑前面几个问题，即我们在考虑一个问题时，希望只考虑与它相邻的问题，这样就达到了通过
隔离的手段但是又不致于增加复杂性的目的，而且这也是现实的需要，这一步一步的解决问题的方法称为
抽象的叠加，问题的最终被解决不是一步而就的，其中间层过程就是所谓的抽象），一个是广度一个是深
度
为什么要提出这二种思想呢,,因为这是跟软件开发过程中的设计密切相关的二种思想啊（当然也是你理解
很多知识的重要思想，比如我这本书里好多概念都试图从一个超越一般书籍的泛化范围和角度去建立一条
知识之间的联系线）
?? 真正的策略
策略为什么跟设计模式有关？
设计跟编码之间无法精确定界，因为设计可以仅仅是提出一个用于实际编码所用的架构，也可以是考虑了
所有编码细节的详尽设计，设计的最终目标可以是一张UML图，也可以仅仅是一张草图或一堆小卡片
(Wildcard说法即来源于此,当然，并不一定要求设计要成档，但是将它具现化表达出来还是很好的行为)，
然而归跟结底，我们设计最终是想产生一堆有机的类文件(UML图也是，卡片也是)，也即我们在进行设计
时，我们的目标(Dest)是产生“编程领域对于现实事物或问题抽象的OO解(OO解只是解空间的其中一种而
已,单纯使用OO的三重机制这只是初级和简单的范型，但已经是非常强大的范型，它产生的类文件已经可
以实现出一个很大的架构，然而，结合了模板和策略的范型就更加是功能强大的范型了,可以更为灵活地产
生出一个架构)”，这往往就是一系列的Class文件，而设计的源(Src)则是“经过了编程抽象的现实事物或
问题”，设计模式就是用来描述这个过程的，然而它又跟算法不同，算法体现的是大领域内对于某个事物
的解决方法(这就是为什么算法也可以用编程语言来表达的原因所在)
我们知道设计是高于编码的，这就是说在我们进行设计时，进行的是一种纯思想的活动(非常重要的是这里
的设计二字远非设计模式中的设计那么狭隘)，并不预先想到要面向编码而设计，然而我们得出的某种设计
方案(比如一种设计模式)并不是不可以在技术上用一种方式来实现，因为狭隘的设计模式之说的设计不过
是根据设计方案产生一堆类文件而已，设计模式高于成码跟设计模式可以用一种技术来实现并不矛盾，你
可以联系ISO网络参考模型来考虑，一种思想或协议的确可以用来实现。。就凭这点，我就十分佩服策略
的提出者
编程新手真言 - GameRes.com 页码，11/101
mhtml:file://F:\Cpp\编程新手真言.mht 2008-7-30
策略是属于设计的而不是编码的，，，这是本质，明白这点非常重要
策略就是这样一种技术，模板技术天然就用于参数化类并产生类文件，这在设计期是一个天然的技术实
现，比如一个类文件可以产生一个职责或对应设计中的一个对象，而模板可以跟据对象本身的特征(比如对
象的类型)去决定产生的表示这个对象的类逻辑，，而这正是策略要解决的问题
策略是多范型设计的较高境界,虽然OO也可很好地表达设计和思想，其它范型也可以，然而策略更接近设
计,比如DP的Sington,Boost 的Enable If,,从这些字眼上看就直接跟思想和设计已经十分接近了。
?? 真正的设计与编码
软件开发过程分设计和编码，组织这二者(以及对其它细节的工程可控性要求)的工程化方法就是XP啊，
UPS啊什么的，设计阶段的工作是可以涵盖整个软件开发过程的，而且可以跟编码同步或异步进行，
与设计模式相比，算法体现的是一种更泛化的问题解决方法的说法(或者说它更测重于说明如何实现能不能
实现，而设计体现是如何设计，要设计出什么架构)，在《数学与算法》节中提到的算法是数学界对于问题
的Solution(VC7以上的工作空间被称为Solutiom).
设计的严格意义是广泛的，，
我们这里说的设计是指定义某种思想上的架构（软件架构往往是一种思想构架，然而必须最终在代码上体
现出来），然后在这种架构下编码构建应用(世俗的眼光里好像编码的地位一直要次于设计^^)，这不是一
种泛思想的活动（虽然严格意义上的设计的确是泛义的），而是面向产生类文件的设计，但我们正对事物
或问题进行设计，所以在源端是非常不确知的高构，在目标端是一定要产生类文件，
因此编程界(注意这三个字)的设计有三种
1. 基于通用设计传统的设计,比如采用一切语言级和非语言级的多范型设计
2. 一开始并不直接面向编码的原语设计，后来才转为面向编码的范型设计
2. 技术上用策略来实现的设计
3. 混合了你自己创建出来的一些架构思想的设计
用原语设计去主导你的设计，再用修饰过的原语设计去主导你的多范型设计(有效的设计应分分这二步)，
最后才产生类文件。。
?? 真正的构件库
构件是运用了组合的思想之一，然而组合是一种更大的思想，有些时候，组合的个体之间并不需要接
口，，只是当它们运作起来，它们便突然构成了这个璀璨的世界。就像这个世界，水，火，大海，高山并
不是某个神预谋为了某种美感而创立的，神只是分别创立它们（没有留专门的接口吧？），然而它们各自
存在而已，然而突然有那么一天，神创建的人类突然发现这简单的组合也是这么美和合理。（请原谅我用
了这么一个不严格的神话来描述这种思想，然而作这种泛化思维有好处的）
在编程领域，库跟构件严格上是二不同概念，然而大体上等价，这里不区分二者。
按使用形式分构件一般有五种
编程新手真言 - GameRes.com 页码，12/101
mhtml:file://F:\Cpp\编程新手真言.mht 2008-7-30
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由表现和世界逻辑组成云
云)
比如上图中，中间逻辑的有穷互饰就会形成最终应用逻辑，但是中间逻辑这个说法永远都是相对（于最终
应用逻辑）说法，越靠近最终应用的中间逻辑越是高级逻辑
库A
库B 库C
编程新手真言 - GameRes.com 页码，13/101
mhtml:file://F:\Cpp\编程新手真言.mht 2008-7-30
GameGeneric向你透露面向游戏和脚本级开发者的那些接口(包括它自己的一些逻辑，和一些对库B，C的
封装逻辑也即入接口逻辑，库A向用户封装了B，C的细节而提供一个大接口给用户使用，当然库A可能也
有它自己的逻辑和架构),这些接口是直接面向高阶应用和开发的需要而创立的，既然GameGeneric建立在
B，C之上，那么在引用A的时候(利用A进行编码实现或在其上面架构更高层逻辑的时候)，B，C是不是变
得无可访问呢？不是，我们其实还是可以在这个步骤中访问到库B，与C的内节的(库的组合逻辑绝非一方
屏蔽一方而是一方对一方的归纳简化和扩展导出)。
?? 真正的可复用
可复用到底追求一种什么样的效果，又能最终达到什么样的效果？运行期的效率或重构期的不可复用和窄
扩问题，一切都可归究到设计期的问题。
编程界的可复用主要是面向对象和构件复用和设计模式和设计复用，库也是语言内部的可复用(就跟你拥有
库的源文件一样.因为有头文件也是一样的，因为你还至少清楚库的构架,这也就跟理解并应用一个库只需
了解其API就行了但不需要了解其SRC级的实现一个道理),COM的复用就是纯粹的二进制的复用，因为有
真正的接口的隔离作用(此时你根本不知道库的构架)，在库定义的接口中，你必须透过接口才能深入接口
更下面的逻辑(可能是另一个库的实现)，因此接口一方面提供了方便性，另一方面也增加了屏蔽性，这是
一对矛盾,接口的定义是为了引入某种架构或桥接二种架构使其配合工作，而这种机制在提供了方便性的同
时也增加了理解和使用该接口的复杂性和运行时空的代价。
库的组合=功能的组合(类库设计是一种跟语言同级的设计)，当然这种逻辑在使用同一种语言下是成立的
(不同语言时也可以用Swig等技术来改造或Bind)，然而库作为中间逻辑的封装者(库让你跳过库的实现即中
间逻辑这些细节而直接面向大逻辑大架构编程,只要引用它们就可以在自己的程序中实现它们)，可以一直
细化接近最终实现,诚然单逻辑的一个类也可以被封装为一个库但是往往不样做，一个库封装了一套互饰的
中间逻辑的有机组合，,这里的中间二字是相对最后的应用逻辑来说的，往往把最终的应用逻辑称为实现，
这就是一种实现逻辑了而不再是中间逻辑了(这就是说库可以是一种内含高抽象的架构逻辑或具体的工具函
数的实现逻辑，或基于其它库之上的架构逻辑或实现逻辑)，库可以直接深入到实现细节，但是我们要控制
这种过程，一方面是中间逻辑与最终应用逻辑不可精确定界，另一方面是因为设计与封装是个无底洞，不
必做这种深入，第三方面是有其它的库可以plug 进来然后在这些“ 轮子” 上实现（库应只提供
BaseGeneric这个库构架(此时库本身是一组架构逻辑而非实现集)和对一些其它外来支持库的引入接口(一