软件开发中的理想与现实（十二）——作坊的经理失业了

2月22日，转眼就开发的第三天。
项目刚开始的时候会遇到很多问题，特别是架构的设计会出现很多变故。昨天刚经历了“过度设计”的事件之后，使我更加认识到真实项目的艰险——这仅仅是一个实验项目，难度也不高，但前两天过的就那么的有声有色，还是有点出乎意料。嗯，可以想象，今天也绝对不会平淡。
果然，“作坊”出事了！

还是先回顾一下“作坊”的作用吧。作坊主要的工作是把词元（零件）进行分类，而分类的原理则是基于以下事实（请原谅我们最初对ASN的肤浅认识吧，以后我会用正确的认识更正这些误解）：
所有用ASN语法的定义数据结构都能够规约成 typereference ::= Type Definition Constraint 的形式，而其中的Type包括 SEQUENCE、CHOICE和SET，以及其他更加简单的格式（SET和其他的格式我并没有介绍，不过没关系，这不影响本文叙述），Definition是大括号之间的Constraint则可以为空。
例如：

A ::= SEQUENCE
{
    b BOOLEAN,
    c INTEGER
}

其中，typereference = "A"，Type = "SEQUENCE"，Definition = "{ b BOOLEAN, c INTEGER }"，Constraint = ""。
又例如：
 B ::= INTEGER (1..255)
其中，typereference = "B"，Type = "INTEGER"，Definition = ""，Constraint = "(1..255)"。这个 Constraint 表明，B 类型的变量只能是范围在 [1, 255] 的整数。
既然有这个前提假设了，那么再来看看 Definition 怎么解析比较好。注意到去掉大括号之后 Definition 就变成"b BOOLEAN, c INTEGER"，而且事实上 c INTEGER 还可以扩充为 c INTEGER (1..255) 这样的形式，也可以写成 c SEQUECE {...}，这正表明，c INTEGER 这样的式子也可以表达为 typereference Type Definition Constraint 的形式。
于是，作坊中很自然的出现了专门处理类型的工人（就是处理带有“::=”的式子）和专门处理成员的工人（就是处理不带“::=”的式子），然后界定工人的处理范围和收集工人的处理结果就由经理来负责。经理可以仅通过大括号和逗号就能方便的界定工人工作的范围。
这看起来很好，但是在真正工作的过程中，经理突然失业了。主要是因为出现了这种情况：

A ::= SEQUENCE
{
    b SEQUENCE
    {
        c INTEGER
    } OPTIONAL
}

请注意看这个 b 和 OPTIONAL，其实 OPTIONAL 是用来修饰 b 的，那么我如何界定工作范围好呢？不知道！这个东西似乎更应该变成递归调用方式比较好，也就是，处理类型的工人遇到大括号就停止手头的工作去找处理成员的工人帮忙，而处理成员的工人遇到大括号就停止手头的工作找另外的处理成员的工人帮忙，这样一直处理下去就可以。这样看来，似乎还是需要经理来协调各个工人的输出，但是工人在工作的时候本来就需要以前工作的资料才行，所以工人本身就可以把输出整理的很好。
看来控制生产资料的经理失业了，工人当家作主了！

回过头来再想想，经理的存在本身就违反了单一职责原则，他既界定工作范围又收集资料，而且在这种特定的语法之下，他还需要带有一定的递归（或者用栈来模拟递归），实在太累了！况且工人工作的时候本身就可以获得几乎跟经理一样多的信息，这样的工人当然要造反了！不过现在的工人也同时拥有多种职责，但是只要从基类上进行划分应该就能解决问题，这已经比经理存在时好多了。