《Linux程序设计模式(机制与策略).docx》由会员分享，可在线阅读，更多相关《Linux程序设计模式(机制与策略).docx（8页珍藏版）》请在三一办公上搜索。
1、Linux程序设计模式机制与策略什么是设计模式（Design pattern）?设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、软件设计经验的总结。使用设计模式是为了提高代码或模块的重用、让程序更容易被他人理解、提高代码可靠性和可维护性。同时，通过学习设计模式可以降低解决一般性问题的开发难度。Linux程序设计模式的起源和发展Linux程序的设计模式起源于Unix文化，是Unix哲学的重要组成部分，而Linux本身就是Unix的一个发展分支。Unix哲学说来不算是一种正规设计方法，它是自下而上的，而不是自上而下的。Unix哲学注重实效，立足于丰富的经验。
2、你不会在正规方法学和标准中找到它，它更接近于隐性的半本能的知识，即Unix文化所传播的专业经验。它鼓励那种分清轻重缓急的感觉，以及怀疑一切的态度，并鼓励你以幽默达观的态度对待这些。什么是Unix哲学？Unix管道的发明人、Unix传统的奠基人之一Doug McIlroy在McIlroy78中曾经说过：I. 让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。II. 假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。III. 尽可能早地将设计和编译的软件
3、投入试用, 哪怕是操作系统也不例外，理想情况下, 应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。IV. 优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事，必先利其器。后来他这样总结道（引自Unix的四分之一世纪）：Unix哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。从整体上来说，可以概括为以下几点：01.模块原则：使用简洁的接口拼合简单的部件。02.清晰原则：清晰胜于机巧。03.组合原则：设计时考虑拼接组合。04.分离原则：策略同机制分离，接口同引擎分离。05.简洁原则：设计要简洁，复杂度能低则低。06.吝啬原则：除非确无它法
4、，不要编写庞大的程序。07.透明性原则：设计要可见，以便审查和调试。08.健壮原则：健壮源于透明与简洁。09.表示原则：把知识叠入数据以求逻辑质朴而健壮。10.通俗原则：接口设计避免标新立异。11.缄默原则：如果一个程序没什么好说的，就沉默。12.补救原则：出现异常时，马上退出并给出足够错误信息。13.经济原则：宁花机器一分，不花程序员一秒。14.生成原则：避免手工hack，尽量编写程序去生成程序。15.优化原则：雕琢前先要有原型，跑之前先学会走。16.多样原则：决不相信所谓“不二法门”的断言。17.扩展原则：设计着眼未来，未来总比预想来得快。给大家推荐一本书UNIX 编程艺术这不是一本讲如何
5、编程的书，而是一本讲UNIX设计哲学的书，当然也适应于Linux。这本书是我来威胜工作后，同事们推荐我读的第二本书(范律推荐)。第一本书是UNIX环境高级编程(邱云松推荐)，第三本书是UNIX网络编程 第2卷 进程间通信（张栋推荐），第四本书是Linux设备驱动程序第三版（刘利方推荐）,第五本书是linux程序设计第三版（我推荐）。什么是机制与策略？我们通过下面文字来理解什么是机制与策略：设备驱动程序的作用在于提供机制，而不是提供策略。X(windows)致力于提供一套机制，而不是策略。策略相对短寿，而机制才会长存。前端实现策略，后端实现机制。策略和机制是按照不同的时间尺度变化的，策略的变化要
6、远远快于机制。把策略同机制揉成一团有两个负面影响：一来会使策略变得死板，难以适应用户需求的改变，二来也意味着任何策略的改变都极有可能动摇机制。相反，将两者剥离，就有可能在探索新策略的时候不足以打破机制。另外，我们也可以更容易为机制写出较好的测试（因为策略太短命，不值得花太多精力在这上面）。机制与策略的实例：（下面的讲解过程中，我会提出一些问题。如果回答错误将会有一个小小的惩罚）1.Uboot的环境变量(bootcmd)2.Linux驱动程序(examples/scull)3.cmdline中的mtdparts解析程序(linux-2.6.32.2/drivers/mtd/cmdlinepart
7、.c)4.udev的rules文件自动执行U盘脚本(60-removable-storage.rules)5.udev的net.agent，实现USB网卡的自动挂接(80-drivers.rules)6.BusyBox工具集介绍（sed，awk，inetd，chat，crond，find，grep，getty-login-bash，start-stop-daemon，run-parts）7.嵌入式数据库（TokyoCabinet，Sqlite3）8.脚本语言（SHELL，TCLSH，Lua，TCC，python）9.图形界面库(qt,pyGTK)MCU嵌入式系统中的机制与策略：MCU（Micr
8、o Control Unit，微控制器单元）片上集成外围器件，没有外扩总线，不带MMU单元是其的主要特征，比如ARM7，Cortex-M3系列等。与之相对的是MPU（Micro Processor Unit，微处理器单元）不带外围器件（例如存储器），是高度集成的通用结构的处理器，比如ARM926，Cortex-A8系列等。在资源非常紧张的深度嵌入式系统中，同样也有使用机制与策略设计模式的成功案例与成熟方案。例如：1.pForth，eForth，RetroForthForth是六十年代末期，由Charles H. Moore发展出来在天文台使用的电脑自动控制系统及程序设计语言，允许使用者很容易组
9、合系统已有的简单指令，定义成为功能较复杂的高阶指令。forth是一种可扩展的，交互式的语言。最初为小型的嵌入式电脑设计的，现在它几乎可以在任何主流的芯片上解译和编译，甚至已有多种可直接运行forth指令的芯片。http:/retroforth.org/2. Pawn, Pawn+freeRTOSAn embedded scripting language formerly called Small.pawn is a simple, typeless, 32-bit extension language with a C-like syntax. A pawn source program i
10、s compiled to a binary file for optimal execution speed. The pawn compiler outputs P-code (or bytecode) that subsequently runs on an abstract machine. Execution speed, stability, simplicity and a small footprint were essential design criteria for both the language and the abstract machine.3. eLua, n
11、utlua(Lua+Nut/OS)eLua stands for Embedded Lua and the project aims to offer the full implementation of the Lua Programming Language to the embedded world, extending it with specific features for efficient and portable software embedded development.http:/www.ethernut.de/en/firmware/nutlua.htmlForth、P
12、awn和Lua在其他领域的应用：Atari 的许多投币游戏机都是用 Forth 开发的。他们相信开发高性能代码的最快方法是使用 Forth ，加上使用汇编语言来重写最内层的循环。按照最近与著名的 Infocom 高级游戏开发者的谈话，他们的游戏解释器也是用 Forth 写成的。Unison World 为 CP/M 操作系统开发了许多游戏，全部都是用 FIG-Forth 编写的。按他们技术总监 Marc de Groot 的说法，把一个基于 Z80 的游戏移植到 6502 或者 MC6809 上，典型的时间不多于 3 个月。美国 Federal Express （联邦快递）公司的手持式行李分捡
13、系统的程序是用 Forth 编写的。项目经理 Gene Farrar 说，他可以按需要在几个星期内升级新固件，相比而言，其它的小组维护 C 语言代码则至少需要 6 个月的时间。1990 年 11 月哥伦比亚航天飞机的 4 个载荷中有 3 个是用 Forth 编程的。按设计团队之一Johns Hopkins Universitys Applied Physics Laboratory的 John Hayes 说法，他们选择 Forth 来解决飞行中的硬件问题，灵活性是一个主要的因素。SUN 公司把 Forth 用于它的工作站可编程 Boot ROM 中，以每天 500-1000 台的速度发货，是
14、可编程 Forth 系统中数量最大的。 1994 年 IEEE 1275-1994 将 Forth 用于 BOOT （初始配置） 固件的标准，这也是 POWER PC 通用硬件平台的基础。在电影终结者 II ：世界末日中， Cyberdyne Systems T1000 系统的特技效果是基于 Morphing 软件包 Forth 产生的。Pleo是一只可爱的小恐龙，是由富士康公司研发的电子宠物，所有Pleo的个性都是通过PAWN的脚本实现。官方网站：著名的第一人称射击类游戏CS反恐精英就是使用了Pawn脚本语言来控制游戏。而另两款著名的3D即时策略类游戏魔兽争霸3和RPG类在线游戏魔兽世界中也
15、大量使用lua脚本。还有在移动设备上一直很火热的游戏愤怒的小鸟也使用lua脚本。机制与策略设计模式在游戏中的应用是最为广泛的，常常关卡的设计和场景的变换都是利用脚本语言来完成策略部分。而画面的渲染和动画的着色这交给图形引擎库来完成机制功能。Terminal中的机制与策略：Terminal平台大量使用了机制与策略的设计模块。在这些方案中，有些做到很简单，有些则做得很灵活。但不管怎样，它们都为解决实际问题做出了重要的贡献。1. analysis统计分析模块实时库中的部分数据是通过分析计算从电表上采集的数据而得来的，Analysis.ini就是用来配置这些数据项以及这些数据项的处理方法。2. tas
16、kmanage任务管理任务管理的工作是在特定的时间将实时库中的数据转存到数据库中。从而生成对应的日月冻结数据、曲线数据等等。这些数据在376.1规约中被称为二类数据。3. cparam参数管理参数管理使用的是gdbm+xml的配置方式，主要实现规约解析要求的各类参数，同时也管理部分内部参数。db2xml和xml2db两个工具实现参数文件格式的转换。4. dbmanage数据管理数据管理使用的是sqlite数据库，并且将运行时的数据库创建也做成了配置文件的形式。通过修改和增加配置文件的内容就能扩展终端运行时的数据库。5. shmemory实时库模块实时库的创建是通过定义C语言中对应的结构体数组来
17、完成的。它提供了抄表程序、统计分析和任务管理需要使用到的数据项，以及这些数据项在共享内存中保存的空间。6. readmeter总表抄表模块抄表模块根据readmeter.ini的配置信息决定哪种电表类型抄读哪些数据项。配置文件中的数据项已扩展成为内部规约，与电表规约中的数据项已无一一对应的关系。7. menu菜单界面模块菜单界面显示内容是通过XML文件格式来配置的，其中包括shift-acmp.xml,shift-auto.xml,menu.xml三大部分，各地的差异通过变量LOCALE区分开来。8. proparse规约解析模块规约解析使用了两套配置文件ini和xml。前者用于配置AFN&F
18、N的数据解析，后者是根据各地情况使用插件对差异项进行配置。前者配置文件还与实时库和数据库有关联。9. TaskManage抄表管理抄表管理模块开始时使用ini文件配置，后转为gdbm+xml方式。配置文件主要是设置定时抄读的数据项，这其中使用了一套内部标识，抄读上来数据直接保存到数据库。10. TaskExecutor抄表执行抄表执行模块使用了ini文件配置，实现内部标识到电表规约数据标识的转换。抄表程序根据电表标识抄读电表的数据，根据内部标识保存从电表抄读上来的数据。11. watchdog运行程序监控通过watchdog.conf配置文件决定要启动哪些程序，以及这些程序的执行方式。当有程序
19、异常退出时，watchdog需要根据配置文件再次启动这些程序。尽管从开发技术的角度看，机制与策略在Terminal平台上的应用是成功的，但是从维护管理的角度看，这些应用考虑得却不是很够。有以下几点原因：1. 策略没有形成统一的风格。各模块之间的配置风格迥异，没有一位开发员敢说已经掌握了所有模块的配置。掌握这些配置的学习曲线很高，有些模块的配置文件甚至比代码还难搞懂。帮助文档也相当滞后，开发人员基本没有整理这类相关的文档或手册。所以注定这类策略只能由开发模块的人员自己维护。2. 解析策略的机制各有千秋。我们的配置文件有sqlite格式的、gdbm格式的、xml格式的、ini格式的、自定义格式的、
20、自定义C语言结构数组等等，这样情况最终导致了代码的冗余，同时抬高了代码维护的成本。各类配置文件的解析性能也参差不齐，程序对修改的监控也只是轮询方式，也有些配置文件使用起来还比较麻烦，需要经过几次转换才能生效。3. 机制与策略分离不够彻底。部分模块的策略没有完全从机制中分离出来，其中或多或少还是存在一些特殊处理的情况。这些特殊处理是对需求不确定的保留，同时也破坏了机制与策略模式的设计原则，直接的坏处是影响到代码的维护，有时一个新的功能需要修改多处代码和配置文件才能实现。4. 策略仅仅是低层次的配置。大部分模块设计的策略仅仅是停留在简单设置，没有什么逻辑上的功能，或者说它不像是脚本更像是配置，这种
21、思路限制了策略的灵活性。但是如果要提高策略的处理层次，势必需要设计更复杂的处理程序。而事实上，另外一个原因是参与开发的人员也缺乏相关的经验。5. 借鉴开源项目的经验不足。设计一套优秀的机制与策略的模式需要花费不少时间和精力，而一般项目不可能会有如此集中的投入。在此情况下本应该最大可能的借鉴开源项目的代码，但实际上我们却没有这么做，而是选择重新发明新的轮子，尽管这样做也可以实现功能，但是我们并没有从中获得好处。目前的情况并不是项目缺乏机制与策略模式的运用，而是对这种模式运用太多太杂，而且总体技术水平偏低，维护成本又偏高。就好比花了很大的力气和很多的时间，却搞了大量的低层次的重复建设一样。现在te
22、rminal平台已经逐渐稳定下来，如果再进行大的改进必定是违背了经济原则，维护成本也会随之陡增。这就是设计规划欠下债，越往后偿还代价越大。而就目前的情况来说，我们最重要的不是忙着考虑如何还债，而是要让大家学会如何才能不欠下新的债。这样终有一日欠债才可能真正还清。机制与策略的测验：现在我们开始做一个体验项目，目的是通过这个项目深刻理解机制与策略的特点，并能够将其内涵转化为自己的思想，同时运用到实际的工作中。以下是项目的一些情况：项目名称：远程升级工具(upgrade)项目经理：(负责考核成员，以及分配任务)项目成员：(参与培训的所有员工，分为12人一组)开发时间：(有效工时两周)项目背景：刚来公
23、司不久的小蒋最近接到一个棘手的新任务。这一次领导要求他开发一个用于给2000台集中器进行远程升级的软件工具。但由于时间紧迫，他必须在两周时间内完成，并且还要马上出差去现场调试。下面的一段对话描述了当时的情况：小蒋：“这事看起来很困难，两周时间内完成似乎不可能。”领导：“是的，所以你要想办法，在现有的测试系统上改，这样做会快一些。”小蒋：“那套代码我完全不熟，况且系统文档不全，编程也非常不规范，很多地方完全搞不懂。我还是要先好好熟悉一下吧。”领导：“没有那么多考虑的时间，你赶紧去办吧。”虽然小蒋很委屈，也给自己找了很多理由，但最后还是得接下这个任务。从上面的对话可以看出，领导可能并不了解事情的真
24、相，要在现有的系统上改一改就能用，那只是在理想状态下，如果开发人员对原有代码不够熟悉，可能会犯更多的错误从而将时间花费在反复调试和修改中。当然，我们也了解到这个项目确实很麻烦，首先，小蒋对于维护这套代码缺乏必要的自信；其次，抛弃它又更需要足够的勇气。如果这个任务交给你，现在又该如何做呢？ （嗯，我想我别无选择。因为我甚至都不知道那个糟糕的测试系统长啥样。） 项目名称：通信报文解析器(msgdump)项目经理：(负责考核成员，以及分配任务)项目成员：(参与培训的所有员工，分为12人一组)开发时间：(有效工时两周)项目背景：最近新手小赵遇到一个烦心的问题，每次分析或调试终端时都会遇到要解析通信报文
25、的问题。他希望能够有一个这样的小工具：能够解析主站与终端或终端与电表之间的通信报文。这件事很有意义，因为手动分析十六进制通信报文不仅费劲、速度慢而且容易出错。他在自己的日记中是这样描述的：“我快发疯了。今天同时接到5现场技支人员的电话，其中2个要求分析终端与主站通信的问题，3个要求分析终端抄表的问题。而他们都提供的一堆十六进制通信报文足够我分析2两天了，我简直就成了分析报文的工具。这种事情难道不能交给机器来做吗？“事实上，现场集中器的问题分析离不开通信报文。试想一下，如果这些烦琐的工作交给机器来做将是一件多么美好的事情。甚至不需要我们出马，现场工程人员就能轻松搞定。当然，这样的软件工具应该设计
26、得非常灵活，既可以在PC机上使用，又可以在终端中运行。而终端中的应用也只要提供接口或者管道连接，就能将分析报文的工作交给这个小工具来完成。这就是我们想要的：一款通用的报文解析器。开发步骤：第一步，确定目标。用几句简短的话概括性的说清楚自己要做的事或对开发软件的描述。目标要明确且务实，如果目标不实际，宁可降低一些也要保证切实可行。第二步，分析需求。使用TodoList or MindMaps的方式罗列出软件需要开发的功能点，想得越多表明你考虑得越全面。除此之外，我们还要罗列出相关的测试工作和准备工作等等。第三步，设计方案。进一步分解需求，并评估每一项工作任务的时间投入和任务规模。最后对所有的工作
27、任务进行优先级排序，并根据实际情况设立项目各阶段的里程碑。第四步，实现功能。所有功能点应该按照里程碑的要求分阶段实现，并且遵循“短，平，快”的原则。尽可能早的发布中间版本，让测试与研发的工作能够并行起来。第五步，开始测试。测试工作从分析需求开始就要考虑，并在第一个里程碑到来时，就应该开始着手实施。尽可能早的开展现场测试，现场才是产品应用的真实环境。考试环境：项目管理平台：http:/192.168.240.8/redmine/projects/upgradehttp:/192.168.240.8/redmine/projects/msgdump请提前（在本周内）注册帐号http:/192.16
28、8.240.8/redmine/account/register软件开发环境：192.168.247.3(ssh登录)，没有帐号的人员请提前申请。版本管理软件：GIT，服务器192.168.247.3个人将项目建立在 192.168.247.3用户根目录下，例如用户liyao：upgrade项目：/home/liyao/upgrade/ 目录下。msgdump项目：/home/liyao/msgdump/ 目录下。准备工作：在开始练习前我们还需要学习一些新工具的使用。我会将相关资料罗列在书籍资料中，剩下的就需要靠参与人员自行学习了。这个课件会提前一周发给大家，在这之前我还会以项目经理的身份先完
29、成第一步和第二步(部分)，并参与到第三步的讨论，之后的任务才会被分解到每个人手中。建议2人一组结对参与，但组与组之间严禁抄袭。如果发现抄袭者或者拒绝参加者，名单将会交由公司领导处理。书籍资料：GIT是一个分布式版本管理工具，被作者称为“傻瓜内容跟踪器”。git中文教程.pdfRedmine是一个集成的项目管理平台，使用非常简单，如同论坛发贴一样。redmine_admin_guide.pdfredmine_user_guide.pdfwww. redmine.orgTcl是一种脚本语言，常用于作为自动测试的工具，本项目将使用Tcl脚本实现。系统学习TCL脚本入门教程.pdf华为TCL培训教程_全_.pdfTcl教程.pdf以上三个新工具简单易学，使用也非常方便，是参加本次测验需要学习的。一般人花费23天时间就能基本掌握，此次测验同时也在考验参与人员接受并运用新知识的能力。如果一周准备时间都不能让你上手，那就证明你的自学能力较差或者学习态度存在问题。其他与本次培训有关的参考文档，还包括推荐给大家的书籍和相关资料等有时间也可以看看。考核内容：测验将考核参与人员以下六个方面：理解沟通，学习总结，技术创新，开发设计，管理规范，工作态度。每项能力最高得分为100分，初试70分及格，补考85分及格。补考方式为延期1周开发时间。评分标准是以完成工作内容的时间、数量和质量进行评判的。
