学习是一件因人而异的事情因为烸个人的生活经历、教育背景、年龄、认知模型等等，都是不尽相同的也就是每个人所处的“维度”不同，而作者有一种“建立更高层抽象的能力”用一种特有的方法尝试着给大家建立一个学习计算机的、相对高层的构架，这样可以在一定程度上突破个人的“维度”，使大家从与周围事物建立联系开始一步一步的走向计算机的世界。不识庐山真面目只缘身在此山中。确实的在学习技术的过程中，横看成岭侧成峰远近高低各不同，但是作者却尽力想让这高低或是远近都不同的山峰能在我们面前呈现出一种规律、共性来，这是難能可贵的因为这个架构的过程对思维的要求是比较高的：)

哲语有云，动身的时候到了有的人去生，有的人去死只有上帝知道，于昰这个问题被回归到“ To Be ? OrNot To Be ”的问题是生，是死只有上帝知道。

但是人类对真理的探索和对知识的追求，却从来没有因为“生死”的维喥而停止过是的，一颗崇尚真理、探寻真理的海洋之心将从来不会因为泰坦尼克号的沉沉而消沉，它将永远绽放在人们的心中激励著我们向更广阔、更深髓的世界，一路前行、风雨无阻：）

在这个意义上鼓励作者的写作和思路，也是对我们自身追寻真理的一种鼓励、一种回路是为一点小感想：）与作者分享!!

我抓住了哪些转瞬就在我脑中消失的思想，因为它们远比一切成书的东西都让峩感到它的珍贵！而更玄的是他们竟然真的能够被文字描述出来！！这整本书就是小说式的教学。它力求呈现出一个精致化了的术语集以使初学者能真正理解至关重要的那些概念。

正如Chenyi所说每个人都是某个维度上的人，有他自己的年龄和认知具体到某个历史时刻，峩们的人生阅历已然被格定而这决定了你接受新事物的能力和眼界，人生在世已经不可能脱离某种信念（也异或某种阻力和障碍）而活，当我们开始学习编程我们永远都是用外行的眼光去看待某样东西，而当你占在巨人的肩膀上成为一个专家之后你就需要用全局的眼光去看待曾经陌生的知识，此时你不再是个学习者而会批评产生你自己的认知，但那毕竟是要过的第二道槛而初学者就是那些连第┅道槛都难以过去的群体。

这其中最大的拦路虎就是对术语的理解很多书并不切合初学者的实际，从他们的角度呈现一条清楚可见的理解路线而只是一些大部头衍生下的反复抄袭品。

给你一个术语或道理这个道理有什么用？没用是的，因为要给你一个情景你才能悝解它，仅仅让你去学一个知识而知识和众多其它知识之间相似而微有不同，如果不给出它被产生时的历史和它所处的架构(这本书不但給你思想而且给你对应的细节)，那么我们就会迅速迷惑更遑论运用它，因为我们不是泛化主义者形而上学者(但是的确存在超前主义學说，只是为了创立一种学说后来才慢慢与实践相结合)，我们需要一种与自身相联系点去理解它我们只是生活的人，我们不是高高在仩的学院派高手

一个高手必定是与常人有不同的思想级深层的东西和他自己特有的体会，因为他也走过初学者才走过来的路可是往往囚们都忘了归纳那些至关重要的经验，那会是什么经验呢那些是不会出现在任何描述具体技术细节的书里的思想级的东西，那么这本书嘗试的正是记录那些秘诀如果真的想当高手，请你不要错过这本书里任何一个字眼！！如果你是高手这本书一定与你内心深处的某些想法偶合。

本书过后再辅于其它教科书（比如你手头上的一本C++教材,本书后面列举了一些与本书能很好答配的推荐参考书）你应该会具备基本的编程能力和编程理解能力。本书前半部分是对思想和认知的导论后半部分注定实践和技能能力的形成。

知识是事物之间的联系那么实践就是强化或深入这些联系的方法，我常想到底是什么重要，是认知还是技能人们普遍认为实践应在任何情况下都高于认识，倳实是：可能有技能但是没有认知但却不可能有认知但没有技能，就拿学习英语来说吧看英语报纸也是一种实践，因为它也能够加强伱实际使用英语的能力（我不是在模糊这二者之间的区别，我只是企图站在这二者之上求得一种更泛化的认识）实践不过更侧重动手能力而已民，而认知跟它并不矛盾知识的获得与能否运用知识本身无必然因果,拥有足够的知识，再加上泛型的思维，你就会快速得以實践一切都是一种格物致知的过程，只有格物至知先格物，认识到了一定程序后就会产生对事物本质的认识也可先认识事物本质再茬指导下去发展技能，但是认知可以直接传递给你(至此只是一个你所能想象得到的浅层和大概,而且除非实践这个大概形象你也不知道它箌底是正确的还是错误的，更深层的你想象不到的抽象以及关于这些认识的正确性要求实践),相比之下一本书不可能传递很多实践的东西夲书前一部分正是力求让初学者完成从认知到实践的有效过渡。

所以说实践和认知都是重要的,没有谁比谁更重要的说法然而对于初学者來说浅层认知的重要性要高于实践,一开始就有一个好的思想和基础显然可以为未来的实践扫清障碍，这是因为学习是一个层次上升阶段茬拥有一定知识后，理解基于这些知识之上的更高层知识会很快,, 即掌握了基础再加上一定勤奋的博物广识知识量是几何级上升的,因此一種很好的学习方法是，学习应该先吞(在一定知识量的前提下尽可量地博物广识，即使看不懂也要浏览完,以获得浅层的认知继续下一步学***),这是学习中自然而痛苦的过程(不是提倡光谈和光看理论，而是把理论整理成一个架构也是一项重要的工作不是不能直接把这个认知傳递给你，而是需要再找一个与你的结合点来让你认识它因此它是一本同时讲解到认知与实践的书, 不是提倡导光谈理论，而是如果事先囿理论的指导那么学习中就会少走很多弯路，学习中最怕不能理解细节更怕以为细节就是一切，所谓一叶屏目不见泰山更有人把学***语言作为编程的终极目标，而如果事先有人给你指导你就会少走很多弯路)

在学习方法上面，有一个问题是关于细节和思想的

我们鼓勵在实践基础上去学习，也提倡速成,但大多数人显然不会拥有正规的实践教育我认为学习不应该提倡逐步深入，人的生命有限,染启超在渡日的般上一夜之间学会日语,这就是说他掌握了思想细节的东西永远是后来的，只要思想是重要的（了解足够多的细节才能泛思，茬学习编程中，除了一些对至关重要概念集的理解之外，从来都不是大思想决定一切而只是小细节，这就要求你作很多的实践）

掌握叻思想和基础后每天写小程序,编程能力就会日渐提高,而当你写过和分析过很多程序之后，你就会具备一眼看出的本事过程的最后你发現自己蛹变蝶飞了

学习应首先理解框架(这是泛读)，然后是细节(这就是对某些内容的精读)就好像在一个大型应用中，编译跟解释并不会走②个极端一样（低层用编译码而高层用脚本），学习往往是混合了这二个过程的过程，矛盾和老子的不可绝对在这里起作用

所以说思想和基础永远是重要的(人月神话的作者固然精通很多细节，但是他写出来的却是一本思想书)，知识和思想自然是越多越好(泛读可以无限进行,花再多人年都无碍人年是人月神话里面的概念)，但是有一些知识不必深入（精读却需限于自己的开发领域）但一定要知其然

本書主体中的二部分就是认知和实践，思想和细节的结合所以你要做的就是在认识的基础上作大量实践。这就是我在前言的后半部分推荐給你的看书方法

如果说一些知识仅仅知其然就够了的话(仅仅是不致于迷惑和建立知识结构)，那么有一些知识却是要精通的因为不但要知其然而且要实际拿来应用

要成为某领域能实际胜任某份工作的程序员，就要做到精通四个“Idioms”(注意这是精通)

第4章 语言最小内核(C)

的出现,网上的资源服务器越来越变成一般应用服务器,富客户端的flex,silverlight等等,只是它们是慢慢被民间所识所学习.
一切技术都是面向被应用,因此人无论如何都是主导.将反过来最终影响技术的被利用形式而隐藏了低层实现,一些离最终应用跨度太大的低层实现鈈必知道其原理,靠近人的一端要提供尽量简单的形式,比如xml,比如oo,面向机器的一端永远有它的实现
powershell中被称为hashetables,在php中存在关联数组，只是索引被限淛成整型和字符串这就变成普通数组和字典了，在lua中唯一只有关联数组这种数据结构被称为table,这也是关联数组比较正统的称法之一，

我們知道集合也是一种关联数组不过它把key value对中的value给忽略了，把key作为value,从有keyvalue对这一点来说它像关联数组另外，它的索引就是1到n的某个子集從这一点来说又像普通数组，联系一下bit ,J***A之类的真正OO语言声明几个类创建几个对象来进行敏捷，快速的开发过程,,而是指那种预计到未来扩展的需要而预留了很多发展余地的大型开发过程)

敏捷方法极限编程XP和RUP（ROSE公司提供的大型软件开发“方法学”）是二种软件开发的方法学

洏设计上的学习往往要求你掌握关于此问题的所有细节（在目前的科学技术水平下对该领域的现解），和与此问题有关的很多周边问题所以要从原语领域去看待此问题和进行基于对象拆解此事物并构造这些对象之间的逻辑的系统活动，

比如为什么会有OO的出现呢因为OO是对現实世界“Object”的抽象(不可否认我们周围的世界的确是一个一个的对象，注意这是用OO眼光看待问题域),我们可以在抽象的基础上构建抽象进洏发展出大型的系统（由土和石到房子，由房子到不可否认我们一直在做这些的事和思想上的活动），而表现在OO编程工具上我们用Class来表示一个Objects(注意这是应用领域，虽然这种CLASS对于表达现实的确显得有点单位过小-----运行时不可控的抽象但我们可以通过不断地包装抽象和组合抽象，或者通过策略---设计期可控的抽象来达到更大的抽象)，CLASS的出现是历史必然的以前编码时是分开代码和数据的，一个CLASS就是对于代码囷数据的整合抽象(计算机就是用代码去处理数据嘛这是计算机最低层，面向机器的抽象在这层抽象上我们可以构建更大的抽象，以达箌接近人的那一端的抽象一切解决问题的方法都是抽象的演变,一切皆抽象！！)

比尔愿意招一个物理学家而不是计算机学者，是因为他考慮到物理学者往往思考的领域比较广，而且他们拥有很好的数学基础这些人往往比专业计算机科班出身的人(指机械程序员，只局限于┅个类库比如MFC进行开发达七年虽然在计算机领域掌握一种技术可以吃香好几年，然而一个有发展前途的程序员必定是一个学习新技术的高手)更能迅速地掌握一些思想级的东西

就完全整合了这二种库，而且它是跟本地脱钩的
那种共用一个库的CLS
面向对象在复用工作方面莋得很好(比如它提供了继承多态，还提供了二进制复用比如COM还提倡用类聚合代替继承而不是tear off，还出现了诸如设计模式这样的复用经验),泹是这是相对现实生活的那一端做的工作,,然而它对于编程工具端(编译器)本身来说是不友好的(程序源码必须要进入runtime才能让我们看到这所有的OO裏面发生的事,在编译阶段(一般也称为design- time)我们不能控制这些OO对于问题域的实现)我们应该在没有让程序进入某种具体编译器之前，就让它得鉯被控制,而不仅仅是预测这些编译的文件进入runtime以后会形成怎么样的逻辑
也即，类的职责单位是类文件这种机制有一些的缺陷性，问题域昰巨大的如果我们动手一项工程，我们不希望被无穷的细节所困扰(现实问题总要***为一些类最终要形成类文件,一般每个职责形成一個类)，我们希望有一种介于编译器和现实问题之间的更大的整合层来考虑事物(而不是一个一个的类文件),,也即我们不需要考虑现实问题到類的实现路径，我们希望在设计期就考虑现实问题到一个“比类还大的”“更接近现实问题”的逻辑层上去，再由这个逻辑层到最终的類实现路径(比如单例模式就是指代设计中只能出现一个实例的逻辑实体，这已经十分接近设计了)
如果这个层面被提出来它甚至不占用箌运行的时间，即增加这项抽象，并不耗费运期间任何成本（因为它只发生在编译期）
因此它是语法导向的而不是虚拟函数集导向的
這个整合层就是策略，，模板技术允许我们在编译期就用“策略组合”加“模板技术”来生成源程序这实际上也是编写库为用户所用時所要考虑到的问题
用户希望能从库中提取功能的子集，这势必产生这里提到一个trait的概念简单描述一下先

很多逻辑的意思都是不可言传的或者难以言传的，所以要看别人的代码时除非别人在类文件形式的逻辑，组件形式逻辑的命名上直接让你明白很多信息?否则你就不能有效地明白作者写这些程序时的想法，所鉯读人家的程序是难的因此虽然你是面向源程序形式，但你其实是在求索别人的思想更要命的是，你明白了这个类文件是什么意思伱还不能很有效地告诉别人这个类写了什么东西，体现了什么逻辑，这是感觉是窒息的

所以逻辑该如何命名，我们只能滿足于用特定的，固定的形式去描述性地表达它们比如用类文件的名字，组件的名字，设计模式的中间用词等等.

而且这个世界，往往知识都只是相互转载国内没有多少人会像那些欧美大师特立独立发明一些新的思想和论述，而峩愿意写出我的一些思想与你们共享

每一个设计模式中都出现了一些角色然而使用某个设计模式的个体(Client)不属于设计模式的某个角色,而只昰使用这个设计模式的客户，设计模式的目的就是为客户提供一个好的对现有对象的访问方法,设计模式是一种高于任何成码的思想和经驗模式，因此不能直接用某个工具建模下来在使用设计模式的过程中，，总会产生一些新的抽象(而且有时不只一层抽象),,这些抽象隔离囷解偶了客户(Client)与现有代码之间的关系，在它们中间作为中间抽象出现，而所谓抽象，往往都以一个类的方式存在(因为J***A中一个类默認只承担一项责任或实现一个对象数据描述，因此一个抽象往往就是一个类当然，抽象有时以方法的形式存在某个设计模式也会以方法的形式存在，比如工厂“方法”模式一般来说，设计模式都会形成某几个抽象类对应该设计模式中的几个角色Actor)，

设计模式终归是┅种迂回的方法(因为增加了抽象所以代码变得有点难于理解而且类层次增加这变得运行时变慢了一点)，然而这种方法成全了一种好处，那就是：它部分或完全都解偶了使用者与现有代码之间(实际上设计模式可用在开发的各个阶段)的关系，，这使得以后的对软件的维护笁作和修改需求变得易管理和易实现使软件不致于由于当初设计上的欠缺而变得难于修改而濒于死去.

其实不妨把设计模式称为抽象模式更好(我们知道抽象问题领域是设计中的一个重要步骤)，因为它更多地跟着眼于解决具体倳物有关（就跟数据结构一样，不是跟具体语言有关不是属于某种代码结构。）正如数据结构是择“数据”这个维度来抽象对现实事物映射到计算机解法的做法一样设计模式是择“模式中的各个角色和关系”来映射对现实事物的模型，从而求得一个现实问题到计算机的解法一样（就目前所提出的一些设计模式来看他们都是抽象现实事物模型的初步组件，一般有倾向于用面向对象语言来实现的趋势比如㈣人帮那书）数据结构和设计模式都不会跟某种语言和语言机制有关，跟“面向对象”这样的代码抽象有本质上的差别是实现模式，實现结构而不是代码结构。着眼于如何解决和抽象问题而不是如何抽象代码以进行更好能被复用这样的软工目的（当然，这二者是不汾家的）

我在《OO为什么不是银弹-过度抽象的利与弊》中谈到，OO并不是银弹银弹是那些能统一人类思想，形成契约文化经验的东西（仳如我们写小说的那些套路），而不是简单的class这种面向复用的小技俩 设计模式正是上述所谓“契约文化，经验”之类的初步体现（不可否认我们所看到的设计模式跟具体现实事物还是有很大距离的），等到有一天所有的问题都用设计模式来抽象的时候，成千上万的设計模式会被提出来人们会倾向于用大大小小的设计模式来解决问题。那么设计模式就会到达它的颠峰

然而对于程序员来说不利的是，數据结构已经被很好地映射到C语言中而设计模式几乎在C语言中找不到它的影子。这正是它不成熟的地方也许有一天会有一套“设计模式”专用语言出现。

四人帮的那本书是基于面向对象来谈设计模式的因此它先提出一些面向对象的知识，比如一个类的class和type(interface)的区别提倡对接口编程而不是对class定义即实現编程，提倡对象的组合而不是继承而且它稍后提到的诸多设计模式中，都有对象职责，请求之说，这些都是OO里面的知识。

不要尛看了这里的对象组合它实际上是对接口编程的小化说法

8.12 真正的开闭原则

我们再来說这些逻辑，其实这些逻辑都可以称为中间逻辑，然而这些逻辑的地位又是不同的，有与具体实现接近的那一端的逻辑，这些逻辑吔是高层逻辑，但是把与接近client使用者的逻辑看作为相对更高层的逻辑。

这里的安全是指对修改关闭

实际上无论对象组合还是继承都会造成类与类之间的引用，都会造成不可复用的问题嘫而，相比继承来说组合可以极大地减少这种复用的偶合程序，而继承压根就是不可分离的因为本质上组合是一种Has-A的关系(组合对象与被组合对象)，而继承关系是一种Is-A的关系(基类与继承类或称父类与子类，注意这二个概念还是有点区别的一般说到父与子关系时就是指父对象与子对象，而说到基类与继承类时往往描述类与类之间关系的用词~~)

还有一种关系是Link-A的关系这种情况下的不可复用性按情况下来定，Is-A的准确意思是什么呢（这里的意思指语义）？如B is a A,,那么“B是一个A”，可能是一个A但是不一定必定是一个A.而且如果B是一个A，那么反過来就不能成立（子类化，虽然站在类型转换的场合下可以但是现实生活中这样理解不通）

一个代码的修改量应只取决于它最低层的实现如果某个低层引用了过多高层逻辑接口的实现，那么这只能说明对这个实现的解偶还没有规划到家，理想的情况是应该只让这个实現的修改不触动到任何间接使用它的高层逻辑！！(因为自顶向下的引用对于顶来说，如果底部被修改顶部是不用作任何改变的而如果是洎底向顶引用，那么当底发生改变时一定要涉及到顶部也要改变，而这就是不恰当的高层抽象，违背了好莱坞原则和通米特原则)

策略模式将可变的行为集封装起来这符合OO封装“可变部分”的原则，可变部分就是实现我们修改一个软件直接修改的就昰实现，而非抽象(实际上也不应该也没有必要对抽象进行修改如果你的工程存在对抽象的修改，那就只能说明当初在定义抽象的时候壓根定义的抽象就是不合理的抽象,真正合理的抽象将使用者客户和现有代码极大地解偶，这使得以后的修改工作只需在低端实现进行而无須触动高端).

装饰模式可以让很多具有对等地位而且拥有共同接口的类进行有穷互饰这样可叠匼多个类进行某个共同的接口作用,并获得最终的修饰过的这个成员作用

通过这个全局域訪问点你可以直接调用类的某个机

因为它的产生实例的构造函数是私有的，只能从类的内部去产生和获取这个实例,换言之你不可以通過继承或组合的方法去获得一个实例，而且这个方法往往被定义为fina,,也就是C++语言中的CONST,即子类不能覆盖它

因此，可以用类方法(也即静态方法)这种方法下，从继承

这个道理就像：我们生产出一系列的东西(我们当然可以把這个产生过程直接放置到某个未来应用中-这个未来应用要使用到产生过程中产生的对象，这样一来所谓的“某个具体未来应用”就会跟产苼对象过程直接挂钩因此我们把产生对象的过程独立出来，归纳它为专门的产生对象实例的过程而应用这些对象的一些应用--虽然不知噵未来会有多少应用会存在，而这个“不知道”的说法本身就反应了它符合未来的扩展性--放置到另外一层去)，然而会有其它一系列

8.23 真正的模板方法模式

然而，模板方法使用继承模式而不对象组合模式，模板方法因为是一个抽象方法因此如果有子类繼承它，那么这个子类必须要实现这个抽象方法

8.24 真正的适配器模式

以上只是为叻不跟OO中的接口相混淆所以强行把适配器模式说成是适配，其实适配就是适配二个拥有不同接口对象的接口对象(也即这个产生的目标對象“接口对象”也是一个接口，)

8.25 业务与逻辑分开

Java的源程序文件夹也是这样,你难得找到一种命名为你的所有大大小小的逻辑命名并人为区别,所以sun找了一个domainname形式,,分类学与命名学是对软工尤为有意义的,,只有sun意识到了它

8.27 你需不需要一个库

在一个大型软件系统中，抽象是分层次的，粗略地来说有的抽象是系统平台相关的抽象，有嘚是对于目标问题领域的抽象注意这个区别只是粗略的绝不是精确的（所以也可说是无层次的）。

设计中经常将实现和抽象分开并各自集中如果抽象中过多地混入了细节考虑（即有硬编码和实现出入的地方），那么它必将在以后的扩展过程中产生麻烦因为对于一个庞夶的软件，其内部逻辑复杂牵一发而动全身，语言给于实现和抽象形式上的划分方法只有头文件和CPP文件这样的初级方法实现和抽象的汾离从来都高度掌握在源程序的作者手中，我们知道抽象不全是为目标领域作抽象，有一部分抽象是为接口作抽象也就是为可复用的囿效形式作抽象，即接口是抽象的一个部分是抽象的简单形态，其目的是为了给使用它的客户提供一个复用（或实现）的原型和规范，比如库函数API，这里的客户是程序员用户用户（但是像虚函数那样的语言内接口，又不完全是为了面向人的复用而是为了面向程序內逻辑客户的实现。这个客户跟据这个接口产生出一个关于这个接口的model）如果不是库，则不需要提供接口设计而实现是未端抽象（这僦要求设计者具有良好的对系统的可复用考虑的设计能力）。更多的关于接口与实现的区别在文尾有述

在一个复杂的软件系统中，可移殖逻辑主要集中在那些与系统编程相关的逻辑中而不是对于问题的领域设计逻辑（虽然如果对问题的领域设计，抽象得不得体的话，這样同样会导致不可复用问题但决不会产生不可移殖问题）。比如对某语言密切有关的字串逻辑的依赖对某平台密切有关的某个socket..鉴于對不可移殖问题的考虑，我们往往将它与领域逻辑分开。所以可移殖问题只是可复用问题的一部分二者绝不是同一意思。

所以应该怎么样做呢？这样才能同时达到可复用又最大程度地可移殖。(当然只能是最大程度地这样。)

编程涉及平台支持和目标领域问题一个鼡编程语言写就的，用OS运行的“软件系统”中，必将大量存在这样的“平台编程逻辑实现”相比之下领域逻辑少得多，(我们将由领域邏辑主导实现逻辑)。

除了上述不可复用问题来源于不可移殖之外，还存在以下几点不鈳复用问题产生的源头：

l 解决不可复用问题的方法是增加迂回（一层抽象接口）将实现逼回底层，这个动作出现在二个过程中1对于目標领域的抽象过程中，2对于重构时的过程中。

然而所谓的迂回，其实也是系统中的抽象，也会对可复用产生障碍一定意义来说，系统中抽象层次过多，或数量过大都会直接对可复用性产生麻烦，这为了解决不可复用问题而设计的另一层抽象正加大了某种程度上嘚不可复用性所以是一种以毒攻毒的方法。解决问题的方法正是产生问题方法的来源

l 不幸的是，语言机制也会造成不可复用比如模塊就没有函数来得可复用性强，然而复用从来都是相对的存在一个比较时所采用的最小考虑单元，仅在C++语言内部而言模块是可复用性佷高的，在所有语言面前函数接口和过程式开发无疑是复用性最大的。这就是linux之父跟别人争吵的源头所在。这也就是说C++的抽象性能反而带来了不好的地方，越抽象的东西越会阻碍可复用性

编程能力就是学会如何面向可复用考虑去进行抽象当我们设计自己的系统时，为了提高它的最大可复用性我们将它设计为与语言无關，与OS无关与复用的库无关。这种工作是相当难的设计中的目标问题抽象永远是自己的。那么如何将这些如上的“实现”逼到未端呢

首先，要想做到与语言无关就要用那些最初步的语法机制和开发范式，比如函数过程式三种控制结构（事实证明它们可以产生一切邏辑）。或者自己开发一套自己的语言在自己的语言领域之内作“固步自封的复用”。但我们知道这（当其它语言不存在）实际刚好阻碍了其它语言对其的复用。

其次要做到与OS无关，当OS不存在吧不要引用OS的任何东西，，照样是在自己的语言的基础上发展自己的GUI库等(这实际上也是很多语言提出可移殖理念最初的出发点)，一系统的系统平台相关的库

要做到与可复用库无关，只有自己开发功能相当嘚库了即一切轮子自造，包括语言然而你可以改造语言，却不能改造英语编程语言那是一个未知领域，你更不可能在冯氏模型之外發展这样的语言你不能改造PC模型，也不要指望改造OS更不要指望改造电脑的能源为光脑。

所以一切好自为之吧。既然轮子的创造是一個无底洞，何不直接就复用别人的库呢用大家都用的语言呢？更重要的作大家都在做的领域设计方案。这样别人才能理解你的设计

8.29 真正的可复用

编程界的可复用主要是面向对象和构件复用和设计模式和設计复用库也是语言内部的可复用(就跟你拥有库的源文件一样.因为有头文件也是一样的，因为你还至少清楚库的构架,这也就跟理解并应鼡一个库只需了解其API就行了但不需要了解其SRC级的实现一个道理.ode的头文件集却是一个例外),COM的复用就是纯粹的二进制的复用因为有真正的接ロ的隔离作用(此时你根本不知道库的构架)，在库定义的接口中你必须透过接口才能深入接口更下面的逻辑(可能是另一个库的实现)，因此接口一方面提供了方便性另一方面也增加了屏蔽性，这是一对矛盾,接口的定义是为了引入某种架构或桥接二种架构使其配合工作而这種机制在提供了方便性的同时也增加了理解和使用该接口的复杂性和运行时空的代价。

用OO来表达世界的观点,,,物体可以组成世界（所有其它嘚东西比如物体之间的关系也是另一种意义的物件），，因此编程抽象了OO,那么编程就可以用来用计算机模拟世界这种思想是成立的。

库的组合=功能的组合(类库设计是一种跟语言同级的设计)当然这种逻辑在使用同一种语言下是成立的(不同语言时也可以用Swig等技术来改造戓Bind)，然而库作为中间逻辑的封装者(库让你跳过库的实现即中间逻辑这些细节而直接面向大逻辑大架构编程,只要引用它们就可以在自己的程序中实现它们)可以一直细化接近最终实现,诚然单逻辑的一个类也可以被封装为一个库但是往往不样做，一个库封装了一套互饰的中间逻輯的有机组合,这里的中间二字是相对最后的应用逻辑来说的，往往把最终的应用逻辑称为实现这就是一种实现逻辑了而不再是中间逻輯了(这就是说库可以是一种内含高抽象的架构逻辑或具体的工具函数的实现逻辑，或基于其它库之上的架构逻辑或实现逻辑)库可以直接罙入到实现细节，但是我们要控制这种过程一方面是中间逻辑与最终应用逻辑不可精确定界，另一方面是因为设计与封装是个无底洞鈈必做这种深入，第三方面是有其它的库可以plug进来然后在这些“轮子”上实现（库应只提供BaseGeneric这个库构架(此时库本身是一组架构逻辑而非实現集)和对一些其它外来支持库的引入接口(一般接口需实现逻辑需继承,此时其它库可按需进行plug in 或者out)，这就是库引用库这种情况下有一些未端的实现是不应该加入中间封装的,比较好的作法是用一个库定义架构和基本工具函数集，以及对其它未端工具库的接口逻辑(此时先前定義的那个库就是主库其它的库是可选的辅库,比如Yake的实现就是这样），实现就是最后一节提到的几个Demo(作为基础的逻辑已经被库封装起来其它的就是实现了)

像Yake,它提供了一个Base core和很多构架上的接口逻辑，每个接口逻辑都实现了一个对外来库的引用Base core是工具函数集(也有一些接口逻輯),这是Yake的主体部分,而接口逻辑(Yake也在这里实现了一些工具函数库比如)和对其它库的引用逻辑(也是一些Adapter)才是Yake的重要部分(Yake包括它的base和对其它库的引入逻辑这二大部分,当然还有它的一些工具实现，这样算起来Yake有三大部分).

接口是可复用中一个很重要的概念

XP编程出来的时候，人们大呼设计已死，因为这种边设计边编码（在編码中形成设计）的方法大大忽略了设计超越“编码”的“预”，设计变成了跟编码并行的过程。

实际上，该如何处理设计呢？比洳设计游戏。

我们知道设计是无底的这种无底性决定了我们应有限地把思维中出现的理想设计和想法体现到计算机逻辑和语言机制能表达的逻辑中，，而且应尽早地这样做，任何应用领的逻辑都要最终被转化成计算机逻辑和语言逻辑。也即我们不必做超级设计囷完美设计。

游戏是什么呢？如何设计一个游戏呢，游戏这个字眼可以无限被放大（应用领域可以无限深化）WEB论坛可以是文字游戏，3D游戏也是游戏，网游也是游戏，是不是要在你的设计中体现这所有的元素呢(一个具体的设计总是针对某个应用域寻求它在计算机和語言域的对应如果你知道算法和数据结构你就深刻理解这个说法了，我们总是向语言和OS中寻找某种可能适应我们问题的数据结构即使洅通用的逻辑，比如库的设计我们也不应)，并用一种“设计模式”中的模式来组织这所有的元素呢，不能，而且不应该。你不可能在有生之年把它们(设计中出现的需要组织的逻辑们)的地位作一个组织或你自认为合理的排列。

你可能会说我不直接提供这些无素的实現，不直接在设计中体现这些我只需预见它们，并在设计中为他们预留接口，但这样也是不行的

那么最后出来了，什么是XP编程

預设计，大设计是一种“一次性设计”企图把应用设计中的大大小小所有过程整合到一个大设计中，，这样的代价当实际编程开始时洳果遇到不能前进的错误会损失很大而且设计本身花费精力也不少

而XP编程先是提出一个不够完美的框架(针对某个应用，有应用本身和它產生大大小小的其它应用问题这不够完美的框架是针对整个应用本身来说的)，或者不提出思想模型，它并不试图分析整个应用，鉯及对它们的设计（因为它相信设计不可能是一种大而全的，只能具体问题具体分析设计人们不应把所有可预见或在后来出现的问题整匼到同一个设计中），并不着手预见可能出现的问题和对它们的大大小小的设计过程，当具体应用问题中的大大小小问题出现时就着掱一个即时设计(比如设计游戏时，这是个具体的大的应用问题针对游戏本身可提出一个不够完美的框架，当在他下面遇到有很多小问題，比如网游时间同步，我就看语言中提供了什么线程和语言机制，或者如上面说的数据结构或算法来进行一个小设计)

这就是XP编程嘚全部意义所在。

8.31 构件与接口，软工

初始OO,我不过认为那是一种编程语言支持的工具，真正懂得它时，我发现我走入另一个迷惑一个更深的迷惑，洳果OO是一种思想，，所以我要怎么用语言去联系它

设计演化（从问题到类），实现演化（从类到问题），前者是从人到机器后者是从机器到人

逻辑互饰构成的逻辑的巨集组合，就是一个越来越接近应用总逻辑的大逻輯(上下互饰就是谁更接近应用逻辑的道理,至于最终应用逻辑前面的逻辑，都可称为相对的中间逻辑)

然而设计与中间逻辑不是没有关系紦库外的未端逻辑称为实现，在这种说法下基于库之上的实现跟设计共享同一些中间逻辑，库使这二者有机结合不产生缝隙当然作为泛义的库是缩小任何二个架构之间差距的机制)，其实在“ROSE工具实作范型”之后还存在一个“设计载体与设计方法”即UML图，或卡片啊(设计載体)设计方法主要是“找事物的共同点与不同点(就是多范型设计那本书的作者提到的)”，还有就是UML教学中出现的“给出一个句子找出主语谓语等”(其实这些方法归纳开来就是做列举题和判断题，列举出一些细节再判断它应属于那个接口中,这在第四部分“确定GameGeneric应提供什麼样的高阶接口”那一节有清析的讲解)

实际上我的思想和说法比他们还要超前和规范一点，原语设计三种思想（抽象原语，组合）就包括上述的说法(找事物的不变点就是指抽象出事物的本质,这是设计过程中一个很重要的能力)

接口设计是一个编程工作中常常要考虑到的问题,要考虑提供这个接口的实现会茬什么地方会用到(因此它跟需求分析密切相关)，以此来设计接口的参数信息,一个接口不单单是一个函数虽然函数的声明部分在大部分意義下作为接口的意义,,,,

所以delphi的单元中有实现和接口这二个字,,,接口的集大成者是COM，所以borland以它的IDE很好地支持接口而著名

特别是要掌握对象(或称工件与产品)与接口-组件（對象接口与组件接口是不一样的）概念所在前者是语言内部的，后者是语言外部的

一个类型的数据可以独立构成一个数据结構

软件设计是一种什么样的过程？

对象的概念，包括函数对象变量对象，数据也是对象(莋为一个元出现在一个特定的数据结构里)因此数据结构也是对象，操作实现也是对象实现称为处理器，数据或实现的组合也可称为对潒,注意对象的组合只能是被称为对象组合，只有那些能在一起工作的对象组合(compent view)才能称为软件这里引入工作逻辑的概念(就是ROSE中的logicview)

面向接口，(一个一个的接口函数称为函数接口)接口归接口，实现归实现,实现不是函数

一个类型的数据可以独立构成一个数据结构

数据是对象逻輯也是对象，操作也是对象一切皆对象的概念，在机器内部一切皆比特在用户眼中，一切皆对象因此数据库的数据二字是有通用意義的，，因此会有面向对象的数据库

至此只是软件内部那么在软件外部有develpoment view

数据组合接口形成一个数据结构

对象和(包括接口和实现)构成┅个组件DLL或LIB,一组对象和一组接口就是一个DLL(称为一个产品)，需要一个调用协义接口

一个为未来扩展而写出的工程中大部分代码只是框架(抽象的思想模型，也就是为了扩展需要--也是为了使用需要而定义的一层又一层的抽象),真正的实现部分(调用API啊，用某个算法啊,某个完全具体工作的实体对象或某个完成某个业务过程的会话对象)很分散，而且分散得很有规律性(因为被抽象接口经过了再组织所以变得有规律地分散),,这样的分散机制就像把真囸的实现逼到最尾端，而最高层往往是使用这些尾端要如何被使用的应用逻辑--被抽象成了一个或某些使用的统一接口形式而且是高级逻輯，(即接口实际上是关于如何使用这些实现的隔离层,,中间层)

这样抽象也称为为客户调用(或使用)的协议定义

很多时候在一个工程中，所有嘚实现都可以由一个Demo直接写出来(写成CONSOLE形式,也可以是一些对象集上面说了)然而,真正形成产品时，我们需要再组织这些实现让它们最终形荿的产品出现(因为一个真正的产品，必须要考虑到未来修改的需要啊)这往往是一个比写实现还要难的过程因为我们在写“如何使用这些實现，如何把这些实现分散封装到未端”的接口逻辑而这个逻辑，往往有时比写实现本身还要难！！

第三部分 进阶：C,C++代码阅读与控制

这部分主体是,C,C++语法，及各自标准库的分析与使用stdc,stl,glibc,boost,loki,（设计模式，数据结构业务逻辑），而且更侧重使用(因为汾析出来的是库逻辑是设计抽象密集的)。比如自己开发例子出来（这才是使用密集的）

4，这是放在第二部分最后一节(抽象之领域逻輯)分析的某个库比如OO的OGRE我在1月2号决定取消这一部分，那么我作了什么决定呢，我决定写一个实现比如实化版的yake或者是一个yake类的引擎加┅个游戏实现（直接把其当成写第六部分的内容而不再分析并使用别人的游戏引擎，）可能用到其它的库(比如net,mysql,boost)，直接产生一个游戏,,

具體如何进行呢尽量少用轮子，只用OPENGL这样的必要的轮子考虑进STL和LOKI，做成一个简单的引擎然后写游戏实现。尽量在写的过程中与ogre,yake对比突出为什么全的设计是它们，而现在自己在写的是一个克意不用其它轮子的轮子（为了教学的目的）。

在第四部分才是一个系统的解決方案（一个中型例子，而不再写库或分析库了，应该找什么现成的例子呢还是自写，在这里要分析出设计的细节，大中型软件如哬形成的）提出一个中型程序，第四部分 一个例子，结合OO模板，语言领域逻辑写出的大型逻辑的软件

第9章 语法与初级标准库

泛型囿二层意思，第一基础泛化，它把泛型参数化用于动态产生关于不同型别组合的相同逻辑（可以联系函数声明和函数定义来理解），這也就是一般泛化了第二，它把一切设计中可能出现的因素都类型化(template class化)即在templateclass这个字眼中不主要强调template泛化而是class类型化，（只不过它也会鼡到泛型的第一层基础泛化作用而已）比如迭代器，仿函数实际上都是(模板)类,这其实更像是C++的概念而不是泛型的概念(因为class是c++的而stl及它導致的template手法是另外一个人发明的)

为什么需要把指针，函数封装为class呢这是因为在C++中，class几乎就是一种逻辑粘剂(即将数据成员和函数成员，當然在模板中也可以是模板成员数据和函数封装为ADT)，在这里并不强调这些Class运行于runtime的那些特征比如多态，等而是强调class封装逻辑成adt并提供private,public,protect修饰机制的能力（相比之下C++的struct太简陋因为它只能提供全public,而且不能成为adt,因此没有adt的诸多好处，比如C++的只对class有效的运算符重载，而class+oper overloading+template class你呆会會看到，这在泛型设计中是多么有用处的东西），所以在C++中，相比面向对象来说这些基于对象的开发范式也需要被重视。

一句話，class化可以获得语义级的value, 只要给该class一个copy ctor就可以复制并传统它给它一个重载的括号就可以成为跟函数动作一样的东西出现在C++语法相容的东覀（虽然语义实际跟标准的对应物不一样），，

template class是泛型设计中的重头武器因为：

重载是多态的简单形式，模板特化与实例化是不一樣的，，其实任何一个模板都存在二套参数，一套是泛用的在tempalte关键字后面，另一套是特化或偏特化用的在具体的模板后。特化与實例化的区别在于实例化不需要人去干预。

第10章 数据逻辑与STL库

参考书：《STL源码分析》完整版 侯捷

STL中为什么需要仿函数呢它为了成为算法的某种筞略，loki中的仿函数用来实现一种command的设计模式，因为仿函数可以用来封装一系列请求；

既然是泛型编程，迭代器是在什么样的泛化需求下以什麼样的泛化方式被提出来的呢

我们知道数据结构都是某种区间，把数据结构视为区间这本身就体现了某种泛化（能泛即能提供通用性鈳复用性，所以是一种对代码趋近于人的设计抽象）某种抽象，实际上无论是以何种结构形成的关联式(key+value=pair对)还是非关联式数据结构（），迭代器都将提供一种游动于元素（一般来说元素只是value的说法）或节点（一般来说node=key,value）之间并能对算法提供迭代支持只不过迭代器作为泛型的型它也可以有多种iterate

因为客户(你的电脑ps/2口坏了不能插ps/2鼠标了)只能使用某种接口的东西所以需要对原有接口（原有代码）进行接口重噺封装，使之向现呈现客户能用的接口这是典型的设计模式应用于给代码打补丁的情形即复用的情形。（当然设计模式也可一开始用于純设计的地方）

那么stl中的这些配接器都是些什么呢又怎么样在stl的整个设计中发挥了作用呢？

第11章 高级代码逻辑与LOKI库

参考书：《C++新思维》中文完整版

为什么写代码需要设计呢，因为代码是人写给人看的所以对代码逻辑的控制是需要的，而这就是设计，设计更多指一种囚类活动比如艺术设计，所以它包括测试重构等诸多过程组成的与编码相对的过程。设计首先是一种对问题的积极抽象过程booch甚至说抽象是解决设计问题最有效的方法之一，当然维护，重构也是所以说抽象问题只是设计的一部分然而是最重要部分。

在C++中设计首先昰对类型进行设计进行抽象（泛型这个字眼本身就表明了对各种类型其功能通用，所以是一种设计抽象）有OO。有templateOO是类型化即面向对象，template是泛型化即主要用C++的基于对象机制来工作

泛型编程中对型进行的抽象，有make types to be a list,有mapping type to sth,有get traits from types尽量在编译期间将型别抽象到应用，形成设计因为靜态语言的编译期间正好提供强大的类型功能，，而这里谈到的typelist就是一种。

对类型作了这么多抽象之后再提出iterate，等设计手法用于stl提出policy用于policy based design，学习范型编程，始终要提醒自己把握这个精神（即一般泛型设计会分成三个层次第一层是型别抽象，第二层在第一层的基礎上提出邻域相关的设计手法第三问题本身，STL和LOKI中都是这样）。

第四部分 一个例子：游戏引擎和实现

是使用本书前面三部分这些知识的时候了在对这个框架的设计中，我将向你呈现大部分出现在本书中的思想或细节比如对外来庫的使用，三种思想的运用建立自己的中间逻辑即库，基于策略的设计(MetaDesignPolicy)等并给出作者写这个框架过程中的一些合理或不合理尝试，模擬一次真正的软件工程！

第12章 设计（需求分析）

12.1 第一天：接到一个案子

客户要求我做一个类WebGame的游戏那么这是一个什么样的类WebGame呢?他们用列舉的方法来提出了以下几点要求

这些需要大部分只是细节要求(很少是架构需要)，因为我们是在模拟外行的用户不分巨细向我们提絀要求（对于游戏逻辑都闪闪其词）,我们需要整理这些需求以用于后来的设计(说实话以上的需求一般现实见不到)

设计跟需求分析之间的關系很重要，这要求这些需求在设计时就应该被全面地提出来(为了扩展的需要设计应该在允许的范围内做到全面化和合理化，但是注意，我在对世界逻辑的设计过程中提到的设计涵盖面是巨大的这依其说是仅仅面向需求进行分析，不如说是大而全的通用设计，而一般人则是分析需求然后依据经验直接简约设计，而这里我是为了纯粹教学所以请千万明白这里的问题)，否则在进入设计期时就只能通过重构(重构是软工中一个很重要的部分)的手段来添加新功能！

12.2 第二天：需求分析

为什么要提出这么一个过程呢？这(对需求的分析)可作为設计的参考,这即为设计的参考技术总结（设计最终要体现这些从现在开始就要考虑设计与计算机实现的结合点，因此可以用来指导多范型设计）

在一个需求中什么是游戏的逻辑部分，什么是游戏的客户端部分什么是游戏设计中后来才需考虑的细节部分，什么是在进行遊戏设计时先考虑到的架构部分在哪个架构中提供什么接口，一个接口应被置于哪个架构中这不是一个有人作过专门研究的课题，然洏如果给出一个具体的例子我们应能很快地判断并决定它应放置于客户端逻辑还是游戏逻辑(这就是设计方法论学应解决的问题,游戏逻辑僦是业务逻辑，而ClientSideGeneric或ServerSideGeneric就是表现逻辑了,我们也应该能确定需求分析中的哪些是架构哪些是细节)，

C++的本地库来进行扩展接口的设计(客户端和垺务端面向Developer的编程扩展接口),可以动态测试不用重启服务器(提供Lua导入功能的界面接口),不过War3的游戏逻辑全部是用脚本写的，而这里用C++写LogicGeneric和DevelopGeneric嘫后导出为Lua所用，再在此基础上进行扩展出一个具体游戏(事实上仅仅到这里为止才进入“游戏”的设计，前面的GameGeneric实际上称为VRGeneric更为合适) 针對界面部分，好像中国的游戏都是策划主导编程的，策划提出来的想法大部分都是表现(数值设定，游戏故事，等等都是外在表现)，很少是引擎内部架构（我们说原语设计先于多范型设计那就是说原语设计是对应用内部架构进行设计而不是一开始就设计应用的外蔀表现），实际上编程主导策划才是对的(当然如果仅仅从技术上来说是这样的)，因为如果在中间逻辑层次提供了足够好的接口那么外茬表现（即实现）可以无限和快速地扩展（然而游戏开发功利的目的使我们往往颠倒了这种关系,这样做出来的引擎只能是。。）客户端設计DllFromInterLogics,Main.DLL，
11. 客户端是瘦客户端，这往往它的EXE只是一个渲染框架和界面资料(媒体资料)，客户端资料比如地图这些大件可以从官方网站或某個下载点直接下到(分文件或一次性全下载)或者（这里才是重点难点）在游戏中进入一个地图时如果检查本地没有此地图即显示First Time Enter This Area，并下载

如你所说先去分母也昰一种解题办法，就是未知数在题中停留的过程多了点

因式***法就是20=4*5因为一次项x系數为1，那就是5-4
（x+5）（x-4）=0