??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
1Q过滤器cd的程序:
由命令行参数传递控制命令;
由标准输入传递输入数据,数据而已Q?br />从标准输出流出的也只能是qo后的数据Q过滤的成果Q发生错误的话,输出到标准错误,必须是错误,不包括程序的执行信息Q?br />Z调试之类的目的,需要喋喋不休的执行信息的话Q要有关闭执行信息的选项Q要有控制输出等U的选项Q要把这些信息输出到不会影响下游E序的地方,比如log文g。(前两个要求通常Z性能压力Q喋喋不休的输出是奢侈的Q?br />
2Q不要轻易请求确认。我个h比较反感的例子就是导入注册表的时候,会弹Z个确认对话框···我不打算导入的话Q会双击.reg文g吗?
除非有够的理由怀疑用户可能会选NOQ或者取消该行ؓ的时候,才给出确认对话框?br />所以MessageBox慎用?img src ="http://m.shnenglu.com/darkdestiny/aggbug/11627.html" width = "1" height = "1" />
]]>
Ҏ(gu)口的优劣评h(hun)?Ҏ(gu)标,不过归结只是3个词而已Q简单,直观Q脚本化?br />脚本化是UNIX文化中最重要的东西了吧,在整本书中一直可以看到相关的概念Q这U组件的表达方式比v链接库之cȝh更大的独立性,即出错也不会轻易的crash主进E?br />
不说废话了。下面简单列丑ƈ评述一下这一章所描述的接口模式?br />
1Q过滤器模式。从stdin接受数据Q{换成另一U格式后输出到stdout。需要注意的是,q里是指接受数据Q而非命o。该模式h“单向流”的特点Q完全是本化而存在的?br />我近D|间曾使用q几ơ这U模式,不过不是Z脚本化,而仅仅是Z转换格式。我所参与的project中,有些看v来很重复的代码需要重构,比较W合自动化的条gQ于是书写了qo器,协助重构工作?br />实际的经验中要考虑的是Q过滤器的过滤粒度问题,也就是吸收多大一捆数据后Q才执行一ơ格式{换(可以UCؓbatchQ。根据实际问题的条gQbatch的大有可能是一行,也有可能是几行,也有可能是所有的数据都到辑才能执行Q不q这U情形比较少见?br />使用qo器还有些潜规则是Q?br />宽进严出Q想必第一ơ看到这4个字的时候都以ؓ是要限制输出内容的意思,我也是这栗不q实际上q不是指内容Q而是指格式。能最大程度容忍格式不太规范的输入Q而自w对输出格式要良好定义,q按q种格式输出Q以便方便下一个程序解析用?br />qoӞ不要丢弃不需要的信息。这个信息是指从stdind的数据。我觉得Q这个不能丢弃的信息的粒度是以batch为单位的。某个batch没有qo处理Q就直接发送到stdoutQ如果只是batch中的某一行数据没有过滤处理,实际上整个batch已经利用q了Q而还要把那行数据保留输出Q只会引起下游程序的困惑?br />qoӞ决不增加无用数据。沉默的法则Q待会说?br />
2Q接下来一口气?个模式,是因些模式或多或是qo器的q亲Q缺背腿的,又没有自q特色Q就能有自己的一个模式名Q什么世道啊?br />cantrip,没输入没输出Q只能通过启动命o行指定运行;
源模式,没输入,但有输出Q?br />接收器模式,有输入,但没输出Q?br />看完以上Q你觉得无聊吧,q?个东西也能有自己的名字··?者有脚本化能力?br />
3Q编译器模式···在启动命令行中指定输入数据文件和输出数据文gQ没有stdin和stdout。编译器模式和过滤器模式几乎做同L工作Q但是ؓ什么编译器模式不用标准输入输出呢QUNIX没有把标准输入输出重定向到文件的能力吗?事实上,在windows下,把过滤器模式变成~译器的样子Q大概只需要重定向一下,例如Qfilter.exe < input.txt > output.txt?br />
4Qed模式。第一ơ看到ed模式Q简直毫不理解ؓ什么过滤器模式要跑到这来换一个名字l骗人。回到刚才聊qo器模式提到要注意的地方,没错了,两者虽然很像,但有两个区别Q?br />ed模式接受的是命oQ而不是数据。每行一个命令,回R后会执行该命令所代表的功能,同时可能会变q程序的状态?br />ed模式需要维护会话状态。过滤器一ơ性的接受输入数据Q一ơ性的处理Q一ơ性的输出数据Q在会话度上可以说是瞬间的。但是ed模式一ơ接受一条命令,执行后输出执行结果,同时E序状态可能会q移?br />ed模式也可以脚本化的,只是调用E序很可能要认使用该模式程序的状态,q且脚本中的命o也要遵@q种状态才可以?br />不过话说回来Qed模式是我们windows用户学习~程最先用到的E序了。回忆一下曾l写q的东西Q都是输入回车,然后得到某种执行。呵?br />
5QRoguelike模式。字W阵列GUIQ如果这也可以称为GUI的话Q,通过单键出发Q像游戏手柄一PQ废弃?br />
6Q接口和引擎分离模式。引擎是指应用程序专用定义域的数据结构和逻辑Q比Mؓ工作者进E也怼更脓(chung)切大Ӟ接口负责接受用户命oQƈ昄l果QGUI的或者CLI的?br />C/S模式是大家最熟?zhn)的接口和引擎分离模式了。不q本章对此的划分可是比较l致Q我看区却只是引擎部分的接口模式不同而已Q接口部分还是一L。以下模式名U都U定前者ؓ接口Q后者ؓ引擎?br />配置?执行者模式。白话的说就是配|者负责配|执行者的执行行ؓQ引擎一般用类gcantripq种无需接口兛_其输出的模式Qƈ且需要接口主动调用?br />假脱?守护q程l合。脱机程序和守护者进E有一个约定的地方Q脱机程序就是往那个地方扔东西,而守护者进E就是只打扫那个地方的东ѝ甚臛_以说Q接口和引擎完全不需要认识对方,也就不必兛_Ҏ(gu)的状态,反正把东西扔那里没错了?br />驱动/引擎l合QC/Sl合。把两个合v来说Q因为我觉得他们是一L。同时由于大家对于C/S的熟(zhn)程度,也无需多说。重要的问题在设计引擎所接受的命令和q回的状态的语法上,q可以称为应用协议或者微型语a。接口需要向引擎发送命令,q获得引擎的状态,以便q回l用戗?br />lg所qͼ接口/引擎分离模式Q接口只需要关心协议,而协议指定的工作怎么完成Q就无所谓了?br />
7QCLI服务器模式。不知道q样一U模式是什么意思···它要说明的只是Q服务器使用标准输入输出Q然后由一个守护程序,把这些输入输接到套接字上。这Q就像是对引擎程序的拆分Q服务器使用标准输入输出Q可以很方便的在~Z接口/客户端程序的情况q行本地试与调试,{接?客户端弄好之后,l服务器一个守护进E,守护q程启动服务器,把服务器的输入输出都q接到套接字上,pȝ搭v来了。此外,守护q程一般有做安全门卫的能力?br />与其说这是一个模式,倒不如说是解决C/S模式调试的好Ҏ(gu)?br />
8Q感谢上帝,l于到多L序模式了Q这U模式在windows下相当的普遍。也是Q程序的应用逻辑被封存在一个API库中Q可以被Ʋ用其功能的程序编译链接?br />
9Q策?机制模式。不知道q是不是接口模式Q本章没有多_但是在别的章节中老说到这个短语?br />{略/机制模式Q其核心是可配置性,可配|一切一切跟外观有关的东西,从每一根头发到每一滴血Q从w体到灵(局外hQ“那是解放者之契约”。偶Q“实现汝的愿望”)?br />无论是XQ还是CEGUIQ或者windowsQ其界面都可以配|。机制是工作的核心逻辑Q而策略是一个具体的配置?br />说CEGUIQ有XXXLookq样的东西,不同的xxxLookQ所看到的是不一L东西Q但是代码本wƈ没有变?br />又如WindowsQ各U主题,Mac的,番茄花园的,都是一些指定了配置的文本行主题文gQ而Windows下的昄机制Qƈ不需要改变?br />
10Q写太多了,累了?img src ="http://m.shnenglu.com/darkdestiny/aggbug/11527.html" width = "1" height = "1" />
]]>
UNIX倡导多进E编E?而不是大家所熟?zhn)的多U程~程.
׃q程有自q立的地址I间,因此多进E之间的协作与交?通关操作pȝ提供的各UIPCҎ(gu)实现.
在讨论IPC的那个章节里,提出了管?信号,临时文g,׃n内存,套接字几个模?
我一般写东西玩的时?L喜欢建立控制台程?因ؓ输入输出库都比较?q且所见即?道/重定向之c?都是建立在标准输?输出的基?q里所描述的管?重定?q不是在一个进E中调用CreatePipe,改变道方向,然后用CreateProcess建立一个子q程.UNIX所用的方式cM?bat命o,比如 dir | more,用符?|"q接两个q程的管?事实?一般能用上道/重定向的q程,都是一个过滤器,数据从标准输入进?l过加工后从标准输出跑掉.因此,道/重定向技术对于流水线般加工的d,是一个相当棒的模?
需要注意的?使用道模型的程?通常数据?协议(在某个Q务下)是单向的.
M?在WINDOWS下像UNIX那样使用道/重定向机?通常是用C/C++写许多独立但是可以连接的E序,然后用bat的方?其按所需dl合.如果希望在程序中可以像bat那样启动其他q程,只要用简单的system(command)函数好?WINAPI通常都是复杂而篏赘的.
UNIX下的信号,是对q程发出?pE的相应回调函数处理,E序可以重蝲自己的实?q和WINDOWS下的消息比较相像,只是WM通常都需要窗?׃信号/消息能传递的数据都比较薄q?所以这通常作ؓ一U辅助机?和其他IPC模型共同协作.
临时文g,是一U能解决双向沟通的模型,但是q不利于做复杂的事情,最好的用途是在简?需要双Ҏ(gu)?大数据量的情形下.使用Ҏ(gu)大概描述?Aq程调用执行某个d的Bq程,Bq程执行结果写入Aq程指定的文?Aq程使用该文?
一个隐(zhn)是,一旦破坏程序知道时文件的位置,可能破坏该文g.
其实临时文g和接下来所说的׃n内存在功能上q无太大区别.唯一不同的是,临时文g所使用的API,都是很容易跨q_?
׃n内存,是一个和操作pȝ密切相关的IPC模型,作ؓ生?消费者系l的一个性能优化的解x?其最大的优势便是对大型数据传递所提供的效?但是,预防竞争/死锁是必考虑的问?我觉?׃׃n内存的API通常是专有的,不易于跨q_,所以用共享内存的条g应该比较严格,必须要在性能需求高和一ơ数据交换量巨大的情况下才可以考虑,而且,临时文g是一个可以考虑的替代模?
套接?是一个直观ƈ且在众多操作pȝ中广泛用的模型,不用说也知道是一个好东西?
在《UNIX~程艺术》中,认ؓ大多数的IPCҎ(gu)都是可以怺替代?因此最重要的是选择一个尽可能使系l简单的模型.此外,特别说多U程不该是最先考虑到的Ҏ(gu),而是最后一?
多线E将子Q务糅合在一个程序中,而不是分开,增加了全局复杂?此外,多线E带来的2个不可避免的BUG:时序问题,q有竞争/死锁的问?U늄全局变量提升了Q务之间的沟通效?但是通常q种效率都被昂贵的锁?解锁所抉|?
特别?使用多线E的E序所依赖的库,q都是U程安全?其中一旦生的问题,会得你ȝ重重,特别?多线E的E序调试......׃时序问题,你自己想想都知道?
因此,非要使用多线E?理想(意味着不可能存?的约束是,U程量不用全局变量;每个变量只被一个线E?被线E用的变量不再被主q程使用;U程中不使用static变量.....q种U束,Ҏ(gu)没有办法实现?