编程新手真.docx

编程新手真.docx

《编程新手真.docx》由会员分享，可在线阅读，更多相关《编程新手真.docx（124页珍藏版）》请在冰豆网上搜索。

编程新手真

编程新手真言

ByMuziSoft08

1.别怀疑，这正是一本同时可作为入门和进阶级的书！

真正的高手和真正的初学者都将从中有所得.

2.你还在为学不懂大量术语而烦恼吗？

如果你真这么认为，那么你可能先要看这本书再看你正在看的C++的书，因为你仅仅缺少一根主线,而它是能让你少走很多弯路的拐棍）

3.对架构的学习才是真正的学习,知识也有它的架构，然而在这本书内有架构也有细节（高手固然知道细节，然而高手也有精神空洞,因为你还需要懂得一些细节之外的架构级的东西）!

4.NotWar3的从零到尾的实现，让你知道其实你一个人就可以做出类War3的游戏！

！

（本书作者也自称是一个菜鸟，但是这个程序的确是他自己写的）

5.再写封皮要满了：

（:

第一部分

本书关键字

前言

引用今何在在《九州羽传说》中的一句话“世界上的事就是这么简单，当你不说出来你永远都不会明白，但当你说出来一切都显得那么简单!

!

人生在世，我们的所见所闻也都那些，给你一个道理，，这个道理有什么用？

没用，是的，因为要给你一个情景，你才能运用它

仅仅让你去学一个知识，如果不给出它被产生时的历史和它所处的架构，那么我们就会迅速迷惑，因为我们不是泛化主义者，形而上学者（但是的确存在超前主义学说，只是为了创立一种学说，后来才慢慢与实践相结合），我们需要一种与自身相联系点去理解它，我们只是生活的人，我们不是高高在于的学院高手，某之若衣的人类悲情，生活里最阳光的感情才是，做一个小人物

倒干你杯子里的水，这是一种很蠢的思想，人生在世，已经不可能脱离某种信念而活，当一个小说家，开始我们永远都是用外行的眼光去看待某样东西，当你占在巨人的肩膀上成为一个专家之后，你就需要用全局的眼光去看待曾经陌生的知识，此时你不再是个学习者，而会批评产生你自己的认知

知识是事物之间的联系，那么实践就是强化或深入这些联系的方法

我常想，到底是什么重要，是认知还是技能，人们普遍认为实践应在任何情况下都高于认识，事实是：

可能有技能但是没有认知，但却不可能有认知但没有技能，只有格物至知，先格物，认识到了一定程序后就会产生对事物本质的认识，也可先认识事物本质再在指导下去发展技能,,,但是认知可以直接传递给你（至此只是一个你所能想象得到的浅层和大概,而且除非实践，这个大概形象你也不知道它到底是正确的还是错误的，更深层的你想象不到的抽象以及关于这些认识的正确性要求实践）,而实践不能被直接传达

看英语报纸也是实践，因为它也能够加强你实际使用英语的能力，

知识的获得与能否运用知识本身无必然因果,拥有足够的知识，再加上泛型的思维，，你就会快速得以实践

所以说实践和认知都是重要的,没有谁比谁更重要的说法，然而对于初学者来说浅层认知的重要性要高于实践,一开始就有一个好的思想和基础显然可以为未来的实践扫清障碍（不是提倡光谈理论，而是要把理论本身谈好也不是一件很容易的事）

因此，即便这个浅层的认知，也是无比重要的,因为学习是一个层次上升阶段，在拥有一定知识后，理解基于这些知识之上的更高层知识会很快,,即掌握了基础再加上一定勤奋的博物广识，知识量是几何级上升的,因此一种很好的学习方法是，学习应该先吞，（在一定知识量的前提下尽可量地博物广识，即使看不懂也要浏览完,以获得浅层的认知继续下一步学习）,这是自然而痛苦的过程,（注意这只是泛读阶段,以建立一个知识的框架）

我们鼓励在实践基础上去学习，也提倡速成,我认为学习不应该提倡逐步深入，人的生命有限,染启超在渡日的般上一夜之间学会日语,这就是说他掌握了思想，细节的东西永远是后来的，只要思想是重要的

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

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

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

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

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

1.你要用到的语言和IDE的“Idioms”（一门语言，一种开发库）---编程首先就是会用一门语言和它的库

2.数据上的”Idioms”（数据结构-数据的内存模式，数据库-数据的外存模式）---编程第一个就是数据，想起DOS下的编程了吗，一是数据，二是代码

3.设计上的”Idioms”（面向对象，设计模式）-----编程第二个就是代码或代码框架

4.以上三条都是前提，那么这第四条就是最终的你要实际涉入的业务领域的”Idioms”---编程最终是为了为这个领域服务

以上四条是主干（最好按1-4的顺序精读），而其它的都是支节。

比如工具的使用啊，XML啊，UML啊，XP方法啊，ANT部署发布知识啊等等

对于计算机专业来说，为什么也才那么几门课程（高数线代离散，编译原理，C与算法,Java），，因为这些学科是最重要的（真正掌握了这些基础，你会发现再多后面的技术用语及其背景都是支节）,这就相当于前面提出的四个Idioms

比如拿编程语言来说，只要越过语言的表达这一层，我们才能用语言表达和理解事物（语言跟你要说的话就像用C++语言去表达一个算法，方案领域跟应用领域的对应）,就像口才，一个好口才的人说话时绝对不会想到措词，因为语言已经成为一种意象,只要把一样东西思想化，才能超越这个东西而去想到别的东西而长足发展，比如面向对象，这本书将帮你解释为什么面向对象是一种科学的机制，解释的过后你甚至会觉得这是一种本来就该存在的很亲切的机制，只要超越了面向对象我们编程时，再加上一定设计模式，才能真正不会一动手编程就考虑什么是面向对象之类。

。

而这些，好像都是一个高手所能做的事了，）。

编程时碰到的信息量永远是巨大的，有生之年我们不可能掌握这些信息的来龙去脉，对于程序员来说，提供一个关于它的编程参考文档可以说是掌握了此信息，因为这个文档就是这个信息的大概，实际上我们编程大部分情况下都只是用第三方的代码库来编程，这个信息用于编程所需的全部东西，对于编程来说只要掌握这些东西就行）,换句话说，一些知识如果不能理解就得先放（以后总会弄懂它的吧？

又不是为了应付临时的考试！

）,在这个信息的社会，至于信息，是撞事学事！

一个程序员并不全知全能，它只提取和了解事物对于编程方面的信息。

对于事物的逻辑认识，只能在对它的编程中不断掌握它

问题随之而来，既然存在这个界限，又如何突破，否则这就是一个空谈

多走弯路，学习是认识事物间联系的过程，而记忆或实践是加强这个联系的过程，，能够认识到事物之间的联系，即便是自想的联系也可加深对事实的记忆（一个程序员有他自己的知识体系是重要的），这就是知识

一切东西，我们应该查本究源,深入其原子世界（任何一个术语都不会简单，有它自己产生的环境与其它知识的联系，但也正是因为这样，这也决定了它的有域性，任何知识只要放在它自己的领域内去理解才能更容易被理解）,,翻译过很多文章你就知道要措词，措词跟概念有关,二个稍微相差不大的措词都会让读者摸不头脑或让他们恍然大悟。

我们高中做到了英语的相似名词不同分析，本书也打算在一定程序上这样做（虽然计算机技术领域一个概念可以自成一书这种现实不允许我们这样做），咬文嚼字在这里起作用，，在某些情况下，它是一种好习惯!

然而千万不要走入另外一种极端,,知识用词和技术用语没有一个标准，比如方法和函数指的是同一个东西

什么是线性（一次就是线性），什么是离散（离散了的量），这都是仁者见伍，智者见，但人们对此的理解都不会差到那里去，并且也不会影响后来的学习,这里有一个描述或形式的概念，相信大家都还记得初中学过的集合，是描述性概念，但集合其实还有一个形式概念,给定了形式就可以框死

而且，要知道，即使是《虚拟机的原理与设计》这本书的作者也会对别人书里的进程概念感到不解。

我注意到程员序考试中多了一项标准化，的确，知识的传达也需进入标准化时代了

最后，如果说任何行为都是功利的，，那么我写这本书的目的只为博你一笑，，，

书中错误再所难免，望不吝赐教！

！

阅读建议

本书的架构就是第一部分到第三部分都是独立的一章，既有知识架构，也有学习方法，技术细节的描述，这三部分要为第四部分用到的细节都给出了详细解释。

。

（四部分都是独立且相互联系的）第二到第三部分很多知识点的讲解都为了第四部分服务，比较侧重于游戏编程，因为我们本书的主要任务之一是产生一个游戏

第二部分要懂得什么

1.（要懂得一点思想）《原语，抽象，组合》

2.（要懂得一点领域内的数学）《数学与算法》

3.（要懂得所处的环境）《硬件，平台，网络》

4.（要懂得方案域的常用原语）《面向对象与面向构件》

5.（要懂得待处理问题域的大概的编程原语，比如）《J2EE大领域学》

第2到第4讲的都是范型，第5讲的是问题

第三部分要精通什么

1.（要精通所用的语言的语法语义）《C++与JAVA》

2.（要精通处理什么样的数据）《数据结构与数据库》

3.（要精通写什么样的代码或框架）《策略与设计》

4.（要懂得待处理问题域的编程原语,为第四部分作准备）《游戏编程与虚拟现实》

第1到第3讲的都是范型（1讲的是语言级的，2，3讲的都是非语言级的范型），第4讲的是问题

第四部分一个综合的例子

这部分就是讲解如何用范型来解决问题

1.《设计----NotWar3框架开发过程》

2.《编码-----一个核心Demo的实现》

3.作业与重构

第二部分

原语，抽象与组合

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

！

因为这三个思想实在太重要了而它们又独立于所有知识，更并且，它们不被任何其它书籍提到并组织，所以在这专门作为一章来讲解：

）

抽象,原语

●真正的原语抽象

原语就是Generic,原语强调的是一种泛化与发散，它把我们考虑问题的范围（一般是设计阶段而非编码阶段，在详尽地考虑了所有细节的情况下编码只是机械的活动）放大到整个人类的认识，我们称之为人类认知空间，对于某个具体问题或事物，不只是编程界对它们有抽象（编程界对现实事物或问题的看法或解法的抽象属于编程界专用的抽象，诚然，编程的确可以产生一个网络游戏中的道具，比如一个加血瓶，然而编程并不能真正为你产出一平加血瓶，有它独有的局限），还存在其它领域对现实事物或问题的抽象（系统架构师好像就是编程界的真正的思想家，分析系统就是真正的一场思想活动，除非编程界有现成的抽象方案可以直接拿来使用或借鉴，否则他独立看待事物以进行编程抽象的视角和广度是受他本人认知和思维能力决定的，对于一个东西，系统分析师看出它用于编程的那些用法，而一个教育工程师可能看出其它的用法，即便是网络工程师，虽然跟系统分析师同处IT领域，也会看出对他们有用的东西），但是无论是各行各业，只要是都属于人，都局限于一个共同的“人类认知空间”（除了那些未被认知的事物或问题之外）。

这就是“问题或事物原语空间”，各行各业有它自己“经过抽象了的”的看法或解法

不管是已认知或未认知，事物或问题总有它“最大的原语空间”，我们把经过编程抽象的事物原语称为“事物或问题编程中的原语空间”，称为“具体事物或问题的原语（有时空间二字可略）”，这显然是一个子集空间。

原语空间就是领域，各个问题都有它被提出和讨论时的领域，比如IDL语言，IDL是一种领域语言（DomainLanuage,可以专门开发一门领域语言用来开发一个领域内的应用），COM是一种高级的构件，因为它直接提供了对接口的支持（接口可以仅仅指API，这是一个特例，接口泛义为“位于二个东西中间起适配作用的桥梁”，因此它还可以是库啊，结构体这些意义的接口，这种泛化思想就让接口成为一种原语，自然有它提出来时的原语空间和当以后不断发展时所形成的更广泛的原语空间），所谓接口也是一个领域空间，这IDL语言就是根据一种“接口语义（也就是接口最终能表达的原语空间内的所有意义）”来定义出来的应用方案（问题方案就是接口原语）

泛化诚然跟抽象不同，虽然二者都强调从低向高层演化，然而泛化更着重思想范围的扩大，而抽象强调的是一种思想的深度和高度，即能从普通现实得出本质性认识的过程，经过抽象的事物要么是事物的一部分（经过抽象的事物压根儿就不是事物的原形，只是一种被修饰或刻意片面化的事物变形,这种变形是对抽象使用方有利的）,要么是解决问题的中间层（比如要实现一个带花园的洋房，这是一个原语问题，如果不仅仅是从编程领去看去解，那么原语解法一般是从材料到房子，从没有装修的房子到洋房，从没有花园的洋房到最终带有花园的洋房，我们总是一步一步来解决问题的，但是当我们想考虑这个问题的某一步时，我们并不想考虑前面几个问题，即我们在考虑一个问题时，希望只考虑与它相邻的问题，这样就达到了通过隔离的手段但是又不致于增加复杂性的目的，而且这也是现实的需要，这一步一步的解决问题的方法称为抽象的叠加，问题的最终被解决不是一步而就的，其中间层过程就是所谓的抽象），一个是广度一个是深度

为什么要提出这二种思想呢,,因为这是跟软件开发过程中的设计密切相关的二种思想啊（当然也是你理解很多知识的重要思想，比如我这本书里好多概念都试图从一个超越一般书籍的泛化范围和角度去建立一条知识之间的联系线）

●真正的策略

策略为什么跟设计模式有关？

设计跟编码之间无法精确定界，因为设计可以仅仅是提出一个用于实际编码所用的架构，也可以是考虑了所有编码细节的详尽设计，设计的最终目标可以是一张UML图，也可以仅仅是一张草图或一堆小卡片（Wildcard说法即来源于此,当然，并不一定要求设计要成档，但是将它具现化表达出来还是很好的行为），然而归跟结底，我们设计最终是想产生一堆有机的类文件（UML图也是，卡片也是），也即我们在进行设计时，我们的目标（Dest）是产生“编程领域对于现实事物或问题抽象的OO解（OO解只是解空间的其中一种而已,单纯使用OO的三重机制这只是初级和简单的范型，但已经是非常强大的范型，它产生的类文件已经可以实现出一个很大的架构，然而，结合了模板和策略的范型就更加是功能强大的范型了,可以更为灵活地产生出一个架构）”，这往往就是一系列的Class文件，而设计的源（Src）则是“经过了编程抽象的现实事物或问题”，设计模式就是用来描述这个过程的，然而它又跟算法不同，算法体现的是大领域内对于某个事物的解决方法（这就是为什么算法也可以用编程语言来表达的原因所在）

我们知道设计是高于编码的（非常重要的是这里的设计二字远非设计模式中的设计那么狭隘），这就是说在我们进行设计时，进行的是一种纯思想的活动，并不预先想到要面向编码而设计，然而我们得出的某种设计方案（比如一种设计模式）并不是不可以在技术上用一种方式来实现，因为狭隘的设计模式之说的设计不过是根据设计方案产生一堆类文件而已，设计模式高于成码跟设计模式可以用一种技术来实现并不矛盾，你可以联系ISO网络参考模型来考虑，一种思想或协议的确可以用来实现。

。

就凭这点，我就十分佩服策略的提出者

策略是属于设计的而不是编码的，，，这是本质，明白这点非常重要

策略就是这样一种技术，模板技术天然就用于参数化类并产生类文件，这在设计期是一个天然的技术实现，

●真正的设计与编码

软件开发过程分设计和编码，组织这二者（以及对其它细节的工程可控性要求）的工程化方法就是XP啊，UPS啊什么的，设计阶段的工作是可以涵盖整个软件开发过程的，而且可以跟编码同步或异步进行，

与设计模式相比，算法体现的是一种更泛化的问题解决方法的说法，在《数学与算法》中提到的算法是数学界对于问题的Solution（VC7以上的工作空间被称为Solutiom）.

设计的严格意义是广泛的，，

我们这里说的设计是指定义某种思想上的架构（软件架构往往是一种思想构架，然而必须最终在代码上体现出来），然后在这种架构下编码构建应用（世俗的眼光里好像编码的地位一直要次于设计^^），这不是一种泛思想的活动（虽然严格意义上的设计的确是泛义的），而是面向产生类文件的设计，但我们正对事物或问题进行设计，所以在源端是非常不确知的高构，在目标端是一定要产生类文件，

因此编程界（注意这三个字）的设计有三种

1.基于通用设计传统的设计,比如采用一切语言级和非语言级的多范型设计

2.一开始并不直接面向编码的原语设计，后来才转为面向编码的范型设计

2.技术上用策略来实现的设计

3.混合了你自己创建出来的一些架构思想的设计

用原语设计去主导你的设计，再用修饰过的原语设计去主导你的多范型设计（有效的设计应分分这二步），最后才产生类文件。

。

●真正的构件库

构件是运用了组合的思想之一，然而组合是一种更大的思想，有些时候，组合的个体之间并不需要接口，，只是当它们运作起来，它们便突然构成了这个璀璨的世界。

就像这个世界，水，火，大海，高山并不是某个神预谋为了某种美感而创立的，神只是分别创立它们（没有留专门的接口吧？

），然而它们各自存在而已，然而突然有那么一天，神创建的人类突然发现这简单的组合也是这么美和合理。

（请原谅我用了这么一个不严格的神话来描述这种思想，然而作这种泛化思维有好处的）

在编程领域，库跟构件严格上是二不同概念，然而大体上等价，这里不区分二者。

按使用形式分构件一般有五种

1．C的库，可能是运行时库，语言函数库，用户发布的应用库，OS级的API库，等等，这些库由于往往只有函数级的接口，因此只要明白参数调用或入栈规则就可以了

2．C++的库，这种库也可以是上述四种库，这些库由于是用C++写成，可能采用了OO，因此其内可能含有某种架构，我们必须懂得其内置的架构才能更好地使用它们。

3．接口库，比如COM，这种构件就是严格意义上的构件，因为它直接内置接口定义，需要懂其内置的架构才能更好使用它们，更高级的还有DCOM等

4．构件套，比如ActiveX（主要用于网络分发）

5．类JavaBean直接为编程环境服务的组件。

这几种库一般都用DLL来实现，DLL是一种装载机制（它可以在运行期动态装卸，比起静态库的另外一个优点来说就是可以避免双份的库引入），而构件是构件，这种关系要明白

一个很重要的思想，千万不能让库的架构主导你的原先的架构，，你永远有你自己的大智慧，也不要做严格的学院派高手去研究某个库的架构（设计一个好的库的架构也是一项大工程），除非你是为了学习，库的架构不必复用到你的架构中，你永远只是库挑剔的顾客与使用者。

按组合关系来分有平等关系，上下关系，多对一关系，比如有三个库

库B

库C

如图，库A与B，C是上下引用,也是一对多引用，库B与库C是独立平等的关系

这种构架就是我们呆会在第四部分提到的总架构,库A是GameGeneric,库B是ShowGeneric,库C是LogicGeneric,当然在每个库下面还有很多库引用关系

什么是上下关系呢？

就是说谁更靠近应用谁就是上，平等关系就是它们作为中间逻辑靠近应用的程度是一样的（这主要是因为它们为共同一个库提供逻辑，而那个库更接近应用，比如这里的B，C对A的关系）

按性质来分有架构库和工具库（库都是中间逻辑的封装者,然而这中间逻辑也有是架构还是非架构之分）,非架构逻辑就是对其它库的引用逻辑（封装逻辑）或工具函数（实现逻辑），架构逻辑就是对一种思想模型的描述

我们在这里反复提到架构与实现，那么到底什么是架构呢，广义的架构就是逻辑互饰以构成最终应用的过程中，出现的一切中间逻辑（无论它有没有被封装成为库）就是架构，，，狭义的架构就是指反映设计中某种物体模型的逻辑层次（比如我提到的GameGeneric由表现和世界逻辑组成云云）

GameGeneric向你透露面向游戏和开发者的那些接口（包括它自己的一些逻辑，和一些对库B，C的封装逻辑也即入接口，库A向用户封装了B，C的细节而提供一个大接口给用户使用，当然库A可能也有它自己的逻辑和架构）,这些接口是直接面向高阶应用和开发的需要而创立的，既然GameGeneric建立在B，C之上，那么在引用A的时候（利用A进行编码实现的时候），B，C是不是变得无可访问呢？

不是，我们其实还是可以在这个步骤中访问到库B，与C的内节的（库的组合逻辑绝非一方屏蔽一方而是一方对一方的归纳简化和扩展）。

●真正的可复用

可复用到底追求一种什么样的效果，又能最终达到什么样的效果？

编程界的可复用主要是面向对象和构件复用和设计模式和设计复用，库也是语言内部的可复用（就跟你拥有库的源文件一样，因为你还至少清楚库的构架）,COM的复用就是纯粹的二进制的复用，因为有真正的接口的隔离作用（此时你根本不知道库的构架），在库定义的接口中，你必须透过接口才能深入接口更下面的逻辑（可能是另一个库的实现），因此接口一方面提供了方便性，另一方面也增加了屏蔽性，这是一对矛盾,接口的定义是为了引入某种架构或桥接二种架构，这种架构在提供了方便性的同时也增加了理解和使用上的复杂性和运行时空的代价。

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

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

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

●真正的DSL

声明性的语言是建立在编译语言之上的，编译语言的目标就是要产生机器码

像C++，ALGO，，PROLG这些语言都可以称之为领域语言，，，而YACC就是建立在他们上面的更高阶语言

如果你有过写编译器或语言的经历，你就会知道语义在这个过程中所发挥的作用