2月22日，轉眼就開發的第三天。
項目剛開始的時候會遇到很多問題，特別是架構的設計會出現很多變故。昨天剛經歷了“過度設計”的事件之後，使我更加認識到真實項目的艱險——這僅僅是一個實驗項目，難度也不高，但前兩天過的就那麼的有聲有色，還是有點出乎意料。嗯，可以想象，今天也絕對不會平淡。
果然，“作坊”出事了！
還是先回顧一下“作坊”的作用吧。作坊主要的工作是把詞元（零件）進行分類，而分類的原理則是基於以下事實（請原諒我們最初對ASN的膚淺認識吧，以後我會用正確的認識更正這些誤解）：
所有用ASN語法的定義數據結構都能夠規約成 typereference ::= Type Definition Constraint 的形式，而其中的Type包括 SEQUENCE、CHOICE和SET，以及其他更加簡單的格式（SET和其他的格式我並沒有介紹，不過沒關係，這不影響本文敘述），Definition是大括號之間的Constraint則可以爲空。
例如：
{
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 的形式。
於是，作坊中很自然的出現了專門處理類型的工人（就是處理帶有“::=”的式子）和專門處理成員的工人（就是處理不帶“::=”的式子），然後界定工人的處理範圍和收集工人的處理結果就由經理來負責。經理可以僅通過大括號和逗號就能方便的界定工人工作的範圍。
這看起來很好，但是在真正工作的過程中，經理突然失業了。主要是因爲出現了這種情況：
{
b SEQUENCE
{
c INTEGER
} OPTIONAL
}
請注意看這個 b 和 OPTIONAL，其實 OPTIONAL 是用來修飾 b 的，那麼我如何界定工作範圍好呢？不知道！這個東西似乎更應該變成遞歸調用方式比較好，也就是，處理類型的工人遇到大括號就停止手頭的工作去找處理成員的工人幫忙，而處理成員的工人遇到大括號就停止手頭的工作找另外的處理成員的工人幫忙，這樣一直處理下去就可以。這樣看來，似乎還是需要經理來協調各個工人的輸出，但是工人在工作的時候本來就需要以前工作的資料才行，所以工人本身就可以把輸出整理的很好。
看來控制生產資料的經理失業了，工人當家作主了！
回過頭來再想想，經理的存在本身就違反了單一職責原則，他既界定工作範圍又收集資料，而且在這種特定的語法之下，他還需要帶有一定的遞歸（或者用棧來模擬遞歸），實在太累了！況且工人工作的時候本身就可以獲得幾乎跟經理一樣多的信息，這樣的工人當然要造反了！不過現在的工人也同時擁有多種職責，但是隻要從基類上進行劃分應該就能解決問題，這已經比經理存在時好多了。
