dup

模块化是迄今为止对付复杂软件系统的最好的办法。

问题并不在于上面这句话。问题在于怎么模块化。这儿的“怎么模块化”并不是说不知道模块化是把系统分拆成几个模块，组合而成系统。而是说不知道以什么规则指导我们进行模块分拆。

当然，关于模块化，有很多非常著名的指导原则，最著名的莫过于“高内聚，低耦合”。可是这个原则有点太过空泛。即便如此，我们也很有必要研究一下这个原则。高内聚的好处是什么？为什么要高内聚？我个人的感觉是，高内聚降低了模块的理解成本，同时潜在的降低了模块组合的困难程度，因为高内聚比较倾向于产生一致性好的接口。低耦合呢？低耦合有一个非常直接的目的，就是为了降低模块的相互依赖程度，以便于：一、更容易替换模块和重用模块；二、强迫模块的接口简单直白。

有了这些铺垫，我准备暂时岔开话题，说说分层体系。

分层逻辑上是把同类【注意：这里是同类而不是同种，以后这儿的差别会被区分的非常清楚】的模块放置到一个叫做层的逻辑模块容器中的一种分拆方式。举例来说：把所有数据库访问类的模块放入到DAL，所有的业务逻辑放入Logical，所有的用户交互放入UI，就是一个经典的分层模式。

对于分层体系，我最大的质疑就是它简直就是低耦合，高内聚的完美反例。首先，它是低内聚的，同一层的子模块，除了逻辑上的同类性，没有别的任何需要聚合在一起的理由。其次，它是高耦合的，层与层之间的耦合关系显然典型的比层内子模块的内聚程度还要高。

那为什么分层模式是如此的流行呢？理由如下：

一、分层给了老板一个完美的项目延期的理由。也因而受到广大的受剥削受压迫的程序的大力吹捧。

二、分层流行的，所以采用分层的风险是小的，所以一定要采用分层，否则自己得全部承担反抗分层的后果，有可能是失败的后果。

三、分层在一定程度上确实解决了某些复杂性问题。

在我看来，第三个理由才是真正的好理由，虽然第一和第二个理由才是最强有力的分层理由。我说说第三个。

我要举ISO的OSI模型为例。OSI是开放系统互联的意思。先假设我们没有任何相关的背景。我们需要制作出一个可扩展的机器系统互相通信的系统。我们可以参考人类已经有的通信系统，当时已经有了语言、电话、电报、IP等等系统可供参考。通信方式从线路交换到包交换都有。问题很快区分出来了。有定址问题，有路由问题，有会话的建立和拆除等控制问题，传输问题，流量控制问题，差错控制问题，进一步还有编码问题，表示问题等等。

所有的这些问题纠缠在一块，并不很容易解决，其复杂度也超出了人类处理复杂度的极限。这时候模块化就来救驾了。由于所有的这些模块是为了一个共同的问题，所以区分出来的模块难免会有很强的耦合。而为了能够控制耦合的强度，采用了分层这种模式，用于限制模块之间任意的耦合，只允许部分模块与另部分模块耦合，也就是所谓的分层。分层就是限制了耦合关系的模块系统，只允许模块跟其上层模块和下层模块有耦合。

所以，分层，模式是为了控制耦合度的一种模块化系统。因此，它确实拥有模块化应该拥有的好处，同时还强迫系统中的模块耦合关系不能是任意的，只能是规定的。

但是，任何把分层模式推往极限的做法都不一定再是对的了。真理往前再走一小步就是谬误了。现在好多系统都是为了分层而分层，结果导致本来该存在于一个模块中的东西却被硬生生的拆分成多个模块，分布在多个层中。形成一种很强的耦合关系，而为了减轻或者消弭这种人为造成的耦合，不断的加入更多的层次，比如我们经常见到的关于VO和DAL，贫血和充血之类的争论就是这方面的争论，这不仅是搬石头上山，而且严重的降低了开发和运行效率。

再岔开一步，我们说说OO。

OO有很多有点，也有一些缺点，当年OO很火很拉风的时候，人人以OO为尊为荣，现在OO成了主流，在理论家或者先行者眼中就成了落魄者了，所以开始很批OO，以OO为卑为耻。其实无论是崇尚还是鄙夷，OO还是OO，它的优点依然存在，跟刚刚被提出来一样有效。而其缺点也依然存在，也跟其刚刚被提出来一样有害。

OO是一种模块化方式。其基本思路就是希望尽可能自然的表达模块，对象作为一个有状态有功能的模块，确实比以前更容易处理模块化这个高深的技术活了。

上面关于OO的讨论，其实可以套用到OB上【或者也叫做ADT】，OO还有个核心的思想是“分类”。其实对于OO的批判主要集中在这个分类上。由于人类思维的飘忽性，昨天认可的分类方式今天却发现不适合，所以OO的分类提供了“继承”来完成这个所谓的思维进化。可是问题是继承只是子类化，只是在类【或者在数学上叫做集合】分拆出一部分作为子类【或者在数学上叫做子集合】。由于人人都有自己的观点，这样就难免会有见仁见智的问题。而且最大的问题就是其实这个所谓的继承根本没有办法完成思维进化，只能在一定程度上完成概念精化的模拟。后来就引入了接口【或者叫做契约、概念】之类的方式{《这儿我并不准备区分编译时还是运行时等等细节问题，所以Cpper也不要吹毛求疵了》}，允许多继承，也就是允许了从多个维度进行分类。比如从大小这个维度进行分类，分出：大、中、小三个类别，从颜色这个维度进行分类，分出：红、绿、蓝三个类别，组合这两个维度【多继承】就能得到一个新的类别出来。有了多继承的引入，OO已经比较完善了。

OO就是上面说的那样。其实OO还有一个比较强的隐含假设，那就是，作为一个Object，它是自足的。也就是说，它要能自我存在而不需要强依赖于别的实体。或者换一句话说：它要是完备的。

那么，我们结合OO和分层就能看出，现在UI、Logical、Data这样的分层机制跟OO机制是冲突的。从OO角度来说，订单就是订单，产生订单，收集订单信息，检验订单，签署订单，订单相关交易【现金和商品】，订单完成等等都是订单的功能，订单有其自身的状态，比如：货物的数量、单价、约定时间等等。从分层角度来说，订单的填写属于UI层，订单的处理属于Logical层，订单的永久化属于Data层。

现在，Java界的业务对象慢慢的获得重视，就是要把各个层次的东西组合起来形成一个完备的自足的对象。而Ruby这类语言由于类的动态可扩充性，自然而然的更能采用OO的思路来思考问题。C#语言也提供了扩展类和扩展方法以便于支持LINQ，同时也自然的提供了类Ruby的解决思路。Java界有一个项目叫做Qi4j，就完全是基于组合开发软件的思路，提供的是纯Java接口，而不是JRuby，Jython，Groovy之类新语言【它们都算是Java界的】，对于坚持咬定Java不放松的那些Programmer来说，应该有些吸引力吧。

一个定时器队列
实现了一个高性能的定时器队列处理系统，基本的实现思路是把所有的定时器请求按超时的前后顺序排入队列中，然后不断的查看是否开始的定时器超时已经到达，如果到达则调用回调处理函数。
这个定时器队列依赖于时间处理的函数和线程，这两个都是平台相关的，不过幸运的是我把他们包装起来了，也就意味着这儿有一个简单的线程包装库。同时有一个小小的可用的可池化的线程的实现。

只适合在Windows系统下[包括WinCE]使用。主要是因为依赖于Windows平台的CString和FindFirstFile、FindNextFile以及FindClose系列函数。其实对于CString的依赖并不是必要的，只是方便了Find*系列函数的调用而已。
examples里面是一些使用这个简单遍历器的例子。包括删除目录中所有文件，复制到另一个目录，生成vector或者一个别的表达等等。
StringOp实现了std::string和CString之间的转换。

当然，我知道，boost实现了一个更漂亮的目录访问器，并且显然功能更强，适应性更好，但是由于我想到我仍然不得不在自己的平台上实现一个目录遍历器，因此我觉得它可能仍然是有用的。我就没有办法把boost的实现在WinCE上编译通过，它的代码如同天书般晦涩，我知道这是由于要适应多个平台导致的，可是这仍然阻止不了我不喜欢读它。希望你能喜欢这个简单的实现，虽然有很多限制，但是在相应平台上立即可用的一个小巧实现。

有限状态机
实现了一个确定型的有限状态机，可以向它注册状态跃迁规则和动作，然后在事件发生的时候通知它，别的都由它实现了。动作的原型是一个void (*)(void* params)的函数指针。
FSM的实现不依赖于任何超越标准C++的内容，也就是说，它可以使用在任何支持标准C++的环境中。顺便说一下，我在WinCE和Windows上都使用过它。

HTML2TEXT
一个简单的例子使用有限状态机，它能够实现快速的把HTML文件转换为TEXT文件，具体的说，就是把标签（头尾tag）去掉，同时其属性也被去掉，把注释内容去掉，把脚本和内嵌样式单中的内容去掉，把实体引用转换为实体代表的内容本身。该例子只是为了展现有限状态机的使用方式，没有考虑HTML中的标签的大小写的问题，如果要考虑也不会复杂多少。
HTML2TEXT的实现也完全是标准语言和库实现的，只是采用了*_s之类的安全的函数，在某些环境下不可实现，不过可以简单的替换成没有_s的相应版本。

实现的基本描述：
顺次的扫描HTML文件（当作一个以零结尾的内存区域），碰到标签<字符，开始忽略其内容，碰到>字符，重新开始记录。碰到<!--开始忽略其内容，而到-->时重新开始记录，同时，碰到<script时开始忽略，碰到</script>时重新开始，style也是一样的处理方式，状态机的状态相当少，包括Normal、Tag、Comment、Style、Script、Entity、End，状态机的开始状态是Normal，最后状态是End，中间可以在这些状态之间跳转。可能的事件包括：    eFindScriptBegin，eFindScriptEnd，eFindStyleBegin，eFindStyleEnd，eFindCommentBegin，eFindCommentEnd，eFindTagStart，eFindTagStop，eFindEntityStart，eFindEntityStop，eFindEnd。它们都很清晰直白，尤其是参看了initFSM_的时候更是如此。它的输出文件也是一个以零终止的内存区域，不需要由客户分配，在析构该对象时自动释放。

其中比较差的一点是我对Parameter结构的使用，我是特意这样演示的，主要是想展现对于FSM灵活的使用方式，其实最常见也最实用的方式是只使用this作为参数。

显然，HTML2TEXT可以非常容易得扩展成一个完整的HTML Parse【可以加上DOM支持】，再加上HTML Render【包括CSS的支持】，Javascript支持和HTTP支持，就是一个Web Browser了。