第六章 分解因子（Factoring）
───────────────────────────────────────
在本章中我們將繼續研討實現階段，這次的重點是在「分解因子」。 拆解元件與分解因子就像同一個功能區塊中的二個晶片。二者都涉及到分割和組 合。拆解元件發生在初步的設計階段；而分解因子則發生於細部的設計與實現。 既然每一個冒號定義都反映出了需要做分解的決定，了解優良的分解技術也許是一 個符式程式設計師最重要的技巧了． 什麼是「分解因子」呢？分解意味著將程式碼組織成為有用的片段。要使一個片 段成為有用的，你通常必須將「可以再度使用的部份」從「不能再度使用的部份」分離 出來。這「可以再度使用的部份」就變成新的定義，而這「不能再度使用的部份」就成 為定義的引數或參數。 做成這樣分離的結果通常被稱為「分解」（factoring out）。本章的第一部份將 談論各種分解的技巧。 決定有多少東西要放到一個定義內，以及有些什麼是要放到定義之外的，則是分解 因子的另一個話題。本章的第二部分將概述一些有效的分解因子的準則。
分解的技巧
假如從系統內的另一個地方看來，一個模組似乎是，但並不全然是，有用的，那麼 就應試著識別並隔離出這些有用的副功能。模組的剩餘部份也許可以合併到它原來 的呼叫者之內（摘錄自 〈結構化的設計[1]〉 一文）。
這「有用的副功能」當然就變成了最新分解出來的定義。至於那個「不是那麼有用的」 部份呢？這就得看它是什麼了。
分解出資料（Factoring Out Data）
能被分解出來的最簡單的東西就是資料，這得感謝符式的資料堆疊。例如，要計算出 1,000的2/3，我們寫
1000 2 3 */
要定義一個詞來計算任何數值的2/3，我們就將這個引數從定義中分解出：
: 三分之二 ( n1 --n2 ) 2 3 */ ;
當資料存在於一個"有用的片語"的中間部位，就必須使用到堆疊操作。例如，要將一段 10個字元長度的文字放在一個80行寬的螢幕中央位置，我們可能寫：
80 10 - 2/ SPACES
但文句未必都是10個字元長。要使這個片語對任何字串都是有用的，你就得分解出 "長度"這項資料：
:~FBBB1;置中~I; ( ~FBBB1;長度 -- ) 80 SWAP - 2/ SPACES ;
資料堆疊也能被用來傳遞地址。因此，被分解出來的或許是一個資料的指標而非資料本 身。資料可以是數值或甚至是字串，而仍然能經由堆疊的使用而被分解出來。 有時，差異的地方看起來像是一個功能，但你仍能簡單地將它視為一個堆疊上的數 值而分解出來。例如：
~FB7T64BY1BB1;段落一： WILLY NILLY PUDDIN' PIE AND
~FB7T64BY1BB1; 段落二： WILLY NILLY 8 * PUDDIN' PIE AND
你如何分解出這個『8 *』的運算？經由將『*』置於分解出的因子之中並傳送一個 1或8給這個新定義：
: NEW ( n--) WILLY NILLY * PUDDIN' PIE AND ;
~FB7T64BY1BB1; 段落一： 1 NEW
~FB7T64BY1BB1;段落二： 8 NEW
（當然，如果『WILLY NILLY』改變了堆疊，你就需要加上適當的堆疊運作） 如果運算涉及到加法，你也能經由傳送一個0來平衡它。
─────────────────────────────────────
提示
為了簡單，嘗試使用數字（數值或地址）上的差異來表示這些相似片段間的差別， 而不要以程序上的差異來表示。
─────────────────────────────────────
分解出功能（Factoring Out Functions）
在另一方面，有時是一種功能上的差別。例如：
~FB7BB1;段落一： BLETCH-A BLETCH-B BLETCH-C BLETCH-D BLETCH-E BLETCH-F ~FB7BB1;段落二： BLETCH-A BLETCH-B PERVERSITY BLETCH-D BLETCH-E BLETCH-F
錯誤的分解方式是：
: BLETCHS ( t=do-BLETCH-C | f=do-PERVERSITY -- )
BLETCH-A BLETCH-B IF BLETCH-C ELSE PERVERSITY THEN
BLETCH-D BLETCH-E BLETCH-F ;
~FB7BB1;段落一： TRUE BLETCHS
~FB7BB1;段落二： FALSE BLETCHS
一個較好的方式：
: BLETCH-AB BLETCH-A BLETCH-B ;
: BLETCH-DEF BLETCH-D BLETCH-E BLETCH-F ;
~FB7BB1;段落一： BLETCH-AB BLETCH-C BLETCH-DEF
~FB7BB1; 段落二： BLETCH-AB PERVERSITY BLETCH-DEF
─────────────────────────────────────
提示 不要向下層傳遞"控制旗號"。
─────────────────────────────────────
為何不？第一，你是在要求那個執行中的程式做一個無意義的決定 --一個你在程式 設計時就已經知道答案的事--
因此減低了程式執行的效率。第二，這樣的用語和概 念上的模型並不匹配。『FALSE BLETCHES』片語在對照著『TRUE BLETCHES』時是什麼
意思呢？
從控制結構之內分解出程式碼
對一個『IF ELSE THEN』結構的兩邊重覆出現的敘述要有所警惕。例如：
... ( c ) DUP BL 127 WITHIN
IF EMIT ELSE DROP ASCII . EMIT THEN
這段程式碼平常會送出一個ASCII字元，但如果這個字元是一個控制碼，它就改送出一個 點。不論走那一條路徑，它都會執行『EMIT』的動作。將『EMIT』自這個條件結構中分解 出，像這樣：
... ( c ) DUP BL 127 WITHIN NOT
IF DROP ASCII . THEN EMIT
當二個定義的差異是在結構之中的一個功能時，就會是最困擾的情況，而使得要將這 "半個片段"分解出來成為不可能的事。在這樣的情況中，就要使用到堆疊引數、變數、 或甚至向量等技巧。我們將在第7章中「使用 DOER/MAKE」的部份看出如何使用向量來 處理這種情況。 下面是一個關於從『DO LOOP』迴路中分解出程式碼的一個提示：
─────────────────────────────────────
提示 要分解出一個『DO
LOOP』的內容為一個新的定義，必須重新考慮碼的寫法，以使 『I』不會在這個新定義內被使用到，而應將它以堆疊引數的方式傳遞過來。
─────────────────────────────────────
將控制結構分解出來
這裡有二個定義，它們的差異存在於一個『IF THEN』的結構內：
: ACTIVE A B OR C AND IF TUMBLE JUGGLE JUMP THEN ;
: LAZY A B OR C AND IF SIT EAT SLEEP THEN ;
其中的條件與控制結構都是相同的；只有要做的事不同。既然你不能分解『IF』到一個字 而『THEN』到另一個字，那麼最簡單的方式就是分解出這個條件：
: CONDITION? ( -- ? ) A B OR C AND ;
: ACTIVE CONDITION? IF TUMBLE JUGGLE JUMP THEN ;
: LAZY CONDITION? IF SIT EAT SLEEP THEN ;
依這種相同的條件與控制結構重複出現的次數而定，你甚至可能想要將兩者都分解出來。 注意下面的做法：
: CONDITIONALLY A B OR C AND NOT IF R> DROP THEN ;
: ACTIVE CONDITIONALLY TUMBLE JUGGLE JUMP ;
: LAZY CONDITIONALLY SIT EAT SLEEP ;
『CONDITIONALLY』這個字 --視條件而定--
可能會改變控制流程以跳過定義中跟在後面 的那些字。但這種方式也有一些缺點。我們將在第8章中談論這個技巧的優劣。
還有更多將控制結構分解出來的例子，包括『CASE』敘述 --它消除了巢狀的『IF ELSE THEN』結構，及多重出口的迴圈（ BEGIN WHILE
WHILE WHILE ... REPEAT的結構） 。我們將在第8章中談論這些主題．
分解出名字（Factoring Out Names）
當一些名字幾乎是，但不全然是，相同時，分解它們似乎是種較好的做法。檢視下面這 個可怕的例子，這些碼是用來設定與八個頻道中每個頻道相關的三個變數的初值：
VARIABLE 0STS VARIABLE 1STS VARIABLE 2STS
VARIABLE 3STS VARIABLE 4STS VARIABLE 5STS
VARIABLE 6STS VARIABLE 7STS VARIABLE 0TNR
VARIABLE 1TNR VARIABLE 2TNR VARIABLE 3TNR
VARIABLE 4TNR VARIABLE 5TNR VARIABLE 6TNR
VARIABLE 7TNR VARIABLE 0UPS VARIABLE 1UPS
VARIABLE 2UPS VARIABLE 3UPS VARIABLE 4UPS
VARIABLE 5UPS VARIABLE 6UPS VARIABLE 7UPS
: INIT-CH0 0 0STS ! 1000 0TNR ! -1 0UPS ! ;
: INIT-CH1 0 1STS ! 1000 1TNR ! -1 1UPS ! ;
: INIT-CH2 0 2STS ! 1000 2TNR ! -1 2UPS ! ;
: INIT-CH3 0 3STS ! 1000 3TNR ! -1 3UPS ! ;
: INIT-CH4 0 4STS ! 1000 4TNR ! -1 4UPS ! ;
: INIT-CH5 0 5STS ! 1000 5TNR ! -1 5UPS ! ;
: INIT-CH6 0 6STS ! 1000 6TNR ! -1 6UPS ! ;
: INIT-CH7 0 7STS ! 1000 7TNR ! -1 7UPS ! ;
: INIT-ALL-CHS INIT-CH0 INIT-CH1 INIT-CH1 INIT-CH2 INIT-CH3
INIT-CH4 INIT-CH5 INIT-CH6 INIT-CH7 ;
首先這些變數的名字都很相似；其次，每個頻道的『INIT-CH』的定義也都很相似。
下面是一個改善了的解答。這些相似的變數名稱被分解成三個資料結構，而這些冗長的『INIT-CH』字也被分解為一個『DO LOOP』結構：
: ARRAY ( #cells --) CREATE 2* ALLOT
DOES> ( i -- 'cell) SWAP 2* + ;
8 ARRAY STATUS ( channel# -- adr )
8 ARRAY TENOR ( " )
8 ARRAY UPSHOT ( " )
: STABLE 8 0 DO 0 I STATUS ! 1000 I TENOR ! -1 I UPSHOT ! LOOP ;
這就是我們所需要的全部的碼。
即使在最無辜的案件中，一點點的資料結構也能消除多餘的名字。在習慣上，符式是以"帶著長度的字串" 來處理文句（將字串長度存放在第一個字元的地址內）。任何一個傳回字串的字，實際上是傳回那個字串的起始地址，也就是字串的計數值存放之所在。使用這種"二種成分"的資料結構，不僅消除了因分開字串與計數所需的不同名字，也使得在記憶體中移動字串變得容易些，因為單一個『CMOVE』的命令就能讓你複製這個字串與它的計數值。
當你開始在各處都發現到同一種相同的笨拙時，你就能經由將事情組合以使這種笨拙消失。
分解出功能到定義字之中~T64BY1;（Factoring Out Functions into Defining Word）
─────────────────────────────────────
提示 如果一系列的定義都含有相同的功能，祗是資料的內容有變，則使用一個"定義字"。
─────────────────────────────────────
檢視下面這些碼的結構（先別管它們的用途 --你在稍後會看到這相同的例子）：
: HUE ( color -- color' ) 'LIGHT? @ OR 0 'LIGHT? ! ;
: BLACK 0 HUE ;
: BLUE 1 HUE ;
: GREEN 2 HUE ;
: CYAN 3 HUE ;
: RED 4 HUE ;
: MAGENTA 5 HUE ;
: BROWN 6 HUE ;
: GRAY 7 HUE ;
上面的方式在技術上說來是正確的，但比起下面使用定義字的方式，在記憶體使用的效 率上就差了一些：
: HUE ( color --) CREATE ,
DOES> ( --color ) @ 'LIGHT? @ OR 0 'LIGHT? ! ;
0 HUE BLACK 1 HUE BLUE 2 HUE GREEN
3 HUE CYAN 4 HUE RED 5 HUE MAGENTA
6 HUE BROWN 7 HUE GRAY
經由使用定義字，我們可以省下每個編譯完成的冒號定義在結束時所需要的『EXIT』的地 址。（在16位元的符式系統上，8個定義共省下14字元的記憶體）而且，在冒號定義 中每參考到一個數值，則會多編入一個『LIT』的地址。（再加2個字元） 在可讀性上，因為經由這個定義字所定義出的所有顏色，都屬於同一家族，在 意義上更是絕對的清晰。 定義字最強而有力之處在，當一系列的定義都共享著相同的「編譯時區的行為」時， 就會凸顯出來。這個主題是一個稍後的章節"編譯時區的分解"所要討論的。
分解的準則
在對分解的技巧有所了解之後，現在讓我們討論一些分解符式定義的準則。它們包 含了：
1. 限制一個定義的大小 2. 限制重複出現的碼 3. 命名的能力 4. 資訊隱藏 5. 簡化"命令的介面"
─────────────────────────────────────
提示 保持定義短小
─────────────────────────────────────
───────────────────────────────────────
我們問Moore，「一個符式的定義應該是多長呢？」
一個字的定義應該是一行長。那是目標。
當你有一堆字，它們在自己的理由上全都是有用的 --也許是在除錯上、或為了探究 事情，但不可避免的總有它們存在的理由--
你能感覺到你已經擷取到了問題的本質 ，而這些字也正恰當的表達出它了。 短小的定義會給你一種好的感覺。
───────────────────────────────────────
對Moore先生的一個應用程式所做的一項非正式的檢查顯示出，他在每個定義中，平均用 到7個詞和數值。這很明顯地是一個短小的定義。（實際上，在他的碼中，一行的定義和 二行的定義，分別佔有約50％的比例） 心理學上的試驗顯示，人類的心靈同一時刻只能集中它的意識到七件左右的事情 上[2]。但是，不分晝夜的，心靈的巨大資源卻潛意識地儲存下巨量的資料，並建立其間 的關聯，及解決問題。 即使我們的潛意識心靈知道一個應用程式的每個部份，我們狹窄觀點的意識心靈也 只能同時使其中七個元素相關聯。超過這點，我們的注意力就會動搖。短小的定義 與我們心智的能力是相互吻合的。 誘使很多符式程式設計師寫出過度冗長的定義，部份原因是因為他們知道一個定義 的"頭部"會佔用一些詞典的空間。分解做的愈少，名字就愈少，記憶體的浪費也愈少。 的確是會用去較多的記憶體，但很難說那些用來幫助你測試、除錯和交談的東西 是一種"浪費"。如果你的應用程式很大，那麼試著去使用"三個字元長度的命名"方式 （但仍保留恢復使用全名的能力，以避免在特別情況下，名字上的衝突）。 如果這樣做之後，應用程式仍然太大。那麼考慮轉換到一個有延伸記憶體的多個 詞典的符式系統，或者另一個更好的方式，使用一個有32位元定址空間的符式系統。 另一個相關的顧慮是，害怕過多的分解將會 --因為符式內部解譯器運作的時間 耗費-- 造成性能上的降低。這點也是對的，每一層呼叫的確是要付出一些代價。但在 正常狀況下，經由適當的分解，這額外的呼叫所付出的代價是查覺不到的。如果執行速 度的需求真的這麼沒有伸縮餘地，那麼真正的解決方式，還是應該把一些字改寫為組合 語言定義，才較為妥當。
─────────────────────────────────────
提示
在你對你的碼感覺不確定的地方進行分解（在那裡，事情的複雜度已經接近了意識上 的極限）。
─────────────────────────────────────
不要讓你的自傲站出來說：「雖然複雜，但我還是能以這樣地方式來解決它！」。符式碼 絕不應該讓人感受到那種令人不快的複雜度。分解它！
───────────────────────────────────────
Moore說：
進行分解的情況之一是當你感覺好像會引入一個錯誤時。祗要看到一個雙層的『DO
LOOP』結構出現，那就是一個"不對勁了"的警示，因為它將是難以除錯的。我幾乎 一定會將內層的『DO LOOP』迴路分解出來成為一個字。
為了測試的目的而分解出來的字，沒有理由再將它塞回去。你在它第一次出現 的地方發現，將它分解出來是個正確的做法。沒有人能保証你不會再次地需要它。
───────────────────────────────────────
這裡是同一個原則的另一面：
─────────────────────────────────────
提示 在似乎需要做註解的地方分解。
─────────────────────────────────────
特別是當你感覺好像需要提醒你自己有些什麼東西在堆疊上時，這或許正是"斷開來"的 好時機。 假設你有
... BALANCE DUP xxx xxx xxx xxx xxx xxx xxx
xxx xxx xxx xxx xxx ( -- balance ) SHOW ...
這段碼以計算帳目的平衡開始，並以顯示它做為結束。在其間，同時另有幾行碼，因為 需要而使用著這個平衡值。能夠看出當『SHOW』執行時，這個值還仍然留在堆疊上，並 不容易，所以程式設計師就插入一個堆疊註解。 這樣的解答通常代表著一種不良的分解。比較好的寫法是：
: REVISE ( balance -- ) xxx xxx xxx xxx xxx xxx xxx
xxx xxx xxx xxx xxx xxx ;
... BALANCE DUP REVISE SHOW ...
它不需要敘事式的堆疊圖畫。而且，程式設計師現在有了一個可以再度使用的、可被測試 的副定義。
─────────────────────────────────────
提示 限制程式碼的重複。
─────────────────────────────────────
分解的第二個理由 --消除程式碼的重複段落-- 這要比減小定義的尺寸更為重要。
───────────────────────────────────────
Moore說：
當一個詞只是一堆東西的時候，它對程式在意思上的清晰度、或者除錯上的方便，雖 然是有用的，但總比不上那種能被多次使用的詞那麼好。一個詞若是只被使用一次，
你就該考慮它是否值得存在。 有許多次，當一個程式的尺寸變得太大的時候，我就回頭尋找那些會引起我的注意
的片語，看看是否能夠將它們分解出來。電腦做不了這件事；因為其中有太多的變 數。
───────────────────────────────────────
在回顧你的工作時，你經常能發現相同的片語、或重複出現了好幾次的詞句。在我寫一 個編輯器時，我發現下面這個片語重複出現了好幾次：
FRAME CURSOR @ +
因為它出現了好幾次，所以我將它分解出來成為一個新字『AT』 。 你自己要能分辨出那些寫出來不同，但功能上卻是相同的碼，例如：
FRAME CURSOR @ 1- +
其中『1-』的出現使這個片語看似不同於『AT』的定義，但事實上，它能被寫成：
AT 1-
另一方面：
─────────────────────────────────────
提示 當分解出重複的碼時，要確定這個分解出的碼只具有單一目的。
─────────────────────────────────────
不要盲目地抓住那些重複的東西，它們也許沒什麼用處。例如，在某一個應用中的一 些地方，我使用到下面的片語：
BLK @ BLOCK >IN @ + C@
我把它定義為一個新字『LETTER』，因為它傳回被解譯器所指著的字母。 在一個稍後的版本中，我意外地必須寫出：
BLK @ BLOCK >IN @ + C!
我無法使用已經存在的『LETTER』，因為此處不是以『C@』做為結束。我不願在新版本中 重複的使用這一大塊的片語，而選擇重新將『LETTER』分解的更細緻些 --把『C@』拿 出來。然後，用法就變成了是『LETTER C@』或者『LETTER C!』。這個改變需要我搜尋 整個程式，找出所有出現『LETTER』之處，並以『LETTER C@』來取代它。我應該在 一開始就做對它，要將"地址的計算"與"對這個地址的運作"這二件事分開來。 類似於我們對抗重複碼的情況是：
─────────────────────────────────────
提示 尋求重複的式樣（pattern）。
─────────────────────────────────────
假如你發現你自己在參考先前程式中所寫的某些部份，並將它們拷貝來使用，那麼你也許 已將一個特定的應用混在一個平常的看法之中。你所拷貝的那份式樣也許可以分解出來， 作為一個獨立的定義，而被使用在所有類似的情況中。
─────────────────────────────────────
提示 要確定能為分解出的部份取個名字。
─────────────────────────────────────
───────────────────────────────────────
Moore說：
假如你有一個概念，但是卻不能給它一個單一的名字（不是指那種用連字符號連接
著的複合名稱），那麼它就不是一個"恰當成形"的概念。拆解（decomposition）的 要件之一就是有命名的能力。這樣，當然你就會對你的概念更具信心。
───────────────────────────────────────
把這個觀點與第一章中"結構化設計"所提出的模組拆解的準則做一比較。根據那個方法， 一個模組將展現"功能性的組合"，而這點是可以經由能夠使用單一的、非複合性的句子 ，來描述出它的功能而得以驗證。符式的"原子"，一個名字，更具有10倍以上的細緻。
─────────────────────────────────────
提示 分解定義，以便隱藏"可能被改變的細節"。
─────────────────────────────────────
在前幾章中，我們已經看到了資訊隱藏的價值，特別是在初步設計的階段。在實現階段 中，能夠記住這個準則，也是很有幫助的。 下面這個非常短的定義，它除了隱藏資訊之外，幾乎沒做什麼事：
: >BODY ( acf -- apf ) 2+ ;
這個定義允許你不用依賴字在字典中的實際結構，而就能將一個"執行碼區"的地址 （address of code field）轉換為一個參數區地址（address of parameter field）。 如果你在程式中使用了『2+』而不是『>BODY』，那麼當程式需要轉移到一個字的頭部 （header）與身部（body）是分開的符式系統時，你將失去移轉性。（這是Kim Harris 所建議的一套字 --它被包含在符式83標準的一個實驗性提議中[3]-- 其中的一個字）。 下面是一群可能被用來寫出一個編輯器程式的定義：
: FRAME ( -- a ) SCR @ BLOCK ;
: CURSOR ( --a ) R# ;
: AT ( -- a ) FRAME CURSOR @ + ;
這三個定義形成了所有為了移動文句所需的位址的計算基礎。經由它們，你可以將編輯 上的演譯法從對符式區塊（blocks）的依賴完全地分開來。 這有什麼好處？萬一在發展的過程中，你決定要建立一個編輯緩衝區，以保護使用者 不小心犯錯時，不會毀掉區塊內的資料。你只需重新定義其中的二個詞，或許像這樣：
CREATE FRAME 1024 ALLOT
VARIABLE CURSOR
其餘的碼可以完全不做任何修改。
─────────────────────────────────────
提示 從顯示結果的定義中，分解出計算它的演繹法。
─────────────────────────────────────
它其實是個屬於拆解上的問題。 這裡有個例子。下面這個詞，讀做"people-to-paths"，是用來計算出一群人之間 所有可能的通訊路徑的數量。（這是一個程式設計小組的經理人員所需要知道的好東西 ，通訊路徑的數量會隨著每個新組員的加入而快速的增加。）
: PEOPLE>PATHS ( #people -- #paths ) DUP 1- * 2/ ;
這個定義只是做計算。下面這個"使用者的定義"會呼叫『PEOPLE>PATHS』去進行計算， 然後再將結果顯示出來：
: PEOPLE ( #people -- ) ." = " PEOPLE>PATHS . ." PATHS" ;
這就會產生：
2 PEOPLE = 1 PATHS
3 PEOPLE = 3 PATHS
5 PEOPLE = 10 PATHS
10 PEOPLE = 45 PATHS
即使你認為，你只是要做一個特殊的計算，而且就祗一次而已，然後再以一種方式顯示其 結果。相信我，你是錯的。你將來還是會需要再回過頭來，將做計算的部份分解出來。 也許是為了要能以右邊對齊的方式顯示這個資料，也許是為了要將結果記錄在一個資料庫 內，你不可能事先知道。但是，既然你早晚是要分解它的，何不在第一次就做對這件事。 （不值得為了那些少數的、能免除這項需要的情況，而引進這種麻煩。） 『. 』是一個基本的例子。『.』在大約99％的時候，都是很不錯的，但是它偶爾是 做的太多了些的。事實上，它所做的是（在符式83'中）：
: . ( n--) DUP ABS 0 <# #S ROT SIGN #> TYPE SPACE ;
假設你想要將一個堆疊上的數值轉換為一個ASCII字串，並且將它儲存在一個緩衝區內， 等待稍後再印出。『.』會轉換它，但卻也會印出它。或者假設你要以"10C"的格式來編 排紙牌，你不能用『.』來顯示這個10，因為它會在後面加上一個空格。
在有些符式系統中，你能發現到一種較好的分解：
: (.) ( n -- a # ) DUP ABS 0 <# #S ROT SIGN #> ;
: . ( n --) (.) TYPE SPACE ;
我們在第四章的羅馬數字的例子中，發現另一個未能將計算功能自輸出功能中分解出的 例子。在我們的解答裏，我們不能將一個羅馬數字存到一個緩衝區內，或甚至於以中 間對齊的方式印在一個欄位中。一個較好的方式是使用『HOLD』代替『EMIT』。） 有時也可能為了"資訊隱藏"，而不去做分解。例如，如果你分解出這個片語
SCR @ BLOCK
成一個定義
: FRAME SCR @ BLOCK ;
要記得，你之所以這樣做，只因為你為了可能要改變編輯的框架（editing frame）的 位置。不要盲目的將所有這樣出現的片語都以『FRAME』來取代，因為稍後你可能會需要 改變『FRAME』的定義，而程式中也有真正需要使用『SCR @ BLOCK』的地方。
─────────────────────────────────────
提示
假如一個重複出現的片段，在有些地方看來像是會改變，但有些卻不會變，那麼就 只分解出那些可能會改變的地方。如果這個片段可能有好幾種改變的方式，就將它
分解為不同的定義。
─────────────────────────────────────
想要知道何時該隱藏資訊是需要直覺和經驗的。在你的生涯中經歷了許多設計規格的變更 之後，你就會學到，事情在將來總是傾向於要被改變的。 當然，你是絕對無法預測到每件事的。做這樣的嘗試將會是徒勞無功的，就如我們將 在後面的"在實現階段中的反覆作為"一節中所見。
─────────────────────────────────────
提示 經由減少命令的數量來簡化命令的介面（command interface）。
─────────────────────────────────────
它是似非而是的。良好的分解經常能產生更少的名字。在第五章，我們見到6個簡單的名 字（左，右，馬達，電磁閥，開，關）如何取代8個分解不良的複合名字。 另一個例子是，在一個剛引進符式的部門中，我發現有二定義徜遊其間。它們的 目的純粹是教學性質的，用來提醒程式設計師目前的『CURRENT』字彙和『CONTEXT』字 彙各是哪個：
: .CONTEXT CONTEXT @ 8 - NFA ID. ;
: .CURRENT CURRENT @ 8 - NFA ID. ;
假如你鍵入
.CONTEXT
系統將反應
.CONTEXT FORTH
（它們動作正確 --至少在那裏所使用的系統中是如此-- 經由往回找到字彙的名稱區， 並將它顯示出來。） 這段很明顯重複的碼引起了我的注意，因為它傳達出分解不良的信息。我們能將 重複的部份做成第三個定義：
: .VOCABULARY ( pointer --) @ 8 - NFA ID. ;
並縮短原來的定義為：
: .CONTEXT CONTEXT .VOCABULARY ;
: .CURRENT CURRENT .VOCABULARY ;
但是，在這個方法裡，這二個定義的唯一差別祗在所要顯示的指標上。既然好的分解應該 是產生更少的，而不是更多的定義，那麼，若是只有一個定義，讓它取得『CONTEXT』或 『CURRENT』作為引數，就會比較合理了。 為了遵循取好名字的原則，我建議：
: IS ( adr --) @ 8 - NFA ID. ;
它允許這樣的語法出現：
CONTEXT IS ASSEMBLER ok
或：
CURRENT IS FORTH ok
最初的線索是重複的碼，但最後的結果卻來自企圖簡化命令的介面。
這裡有另一個例子。IBM PC有四種文字顯示模式：
40 column monochrome
40 column color
80 column monochrome
80 column color
我所使用的符式系統，提供了『MODE』這個詞。它取得一個0到3之間的引數來改變顯示模 式。當然，片語『0 MODE』或『1 MODE』並不能讓我想起哪個模式是哪個樣子。 因為我需要能在這些模式之間轉換，所以我就需要有一組方便而又好用的詞，來實現 這些轉換。這些詞也必須能同時設定一個變數，它存著目前螢冪的行數 --40或80。 下面是達到這個需求的最直接的方式：
: 40-B&W 40 #COLUMNS ! 0 MODE ;
: 40-COLOR 40 #COLUMNS ! 1 MODE ;
: 80-B&W 80 #COLUMNS ! 2 MODE ;
: 80-COLOR 80 #COLUMNS ! 3 MODE ;
經由分解以消除重複的碼，我們就能做出這樣的版本：
: COL-MODE! ( #column mode -- ) MODE #COLUMNS ! ;
: 40-B&W 40 0 COL-MODE! ;
: 40-COLOR 40 1 COL-MODE! ;
: 80-B&W 80 2 COL-MODE! ;
: 80-COLOR 80 3 COL-MODE! ;
但是，經由試著減少命令的數目，也經由試著消除那種"數字前導"和"使用連字號"的名 字，我們認識到，可以將行寬做為一個堆疊引數，並據以計算出它的模式：
: B&W ( #cols --) DUP #COLUMNS ! 20 / 2- MODE ;
: COLOR ( #cols --) DUP #COLUMNS ! 20 / 2- 1+ MODE ;
因此我們就有了這樣的語法：
40 B&W
80 B&W
40 COLOR
80 COLOR
我們已將命令的數目由4個減少為2個。 但仍然還有一些重複的碼。如果我們分解出這段碼，就能得到：
: COL-MODE! ( #columns chroma? -- )
SWAP DUP #COLUMNS ! 20 / 2- + MODE ;
: B&W ( #columns --) 0 COL-MODE! ;
: COLOR ( #columns --) 1 COL-MODE! ;
現在我們已經獲得了一個較好的語法，同時也減小了目地碼的尺寸。在這個例子中，省去 了二個命令所獲得的利益或許不算什麼，但若是較大的命令組，這個好處就會以幾何級數 的增加。 最後一個例子是，在一個特別的系統中，用來表示色彩的一組字。使用像是"藍色" 、"紅色"這樣的名字會比使用數字好。解答之一可能是像這樣的定義：
0 常數 黑色 1 常數 藍色
2 常數 綠色 3 常數 靛色
4 常數 紅色 5 常數 橙色
6 常數 棕色 7 常數 灰色
8 常數 暗灰 9 常數 淡藍
10 常數 淡綠 11 常數 淡靛
12 常數 淡紅 13 常數 淡橙
14 常數 黃色 15 常數 白色
這些色彩能配合像是背景、前景、框界這一類的詞一起使用：
白色 背景 紅色 前景 藍色 框界
但這樣的解答需要16個名字，而且其中很多是帶有連字符號的（譯註：指英文的寫法， 如"淡藍"會被寫成 LIGHT-BLUE）。有辦法簡化嗎？ 我們注意到顏色8到15是顏色0到7的"較明亮"的版本。（這二組詞在硬體上唯一的差 別祗在一個"強度位元"的設定與否）如果我們將"亮度"分解出來，我們也許就能有下面 這個解答：
變數 亮度
: 色彩 ( 顏色 -- ) 建造 逗入
行為 ( -- 顏色 ) 讀取 亮度 讀取 OR 0 亮度 存入 ;
0 色彩 黑色 1 色彩 藍色 2 色彩 綠色
3 色彩 靛色 4 色彩 紅色 5 色彩 橙色
6 色彩 棕色 7 色彩 灰色
: 淡 8 亮度 存入 ;
在這樣的語法下，『藍色』這個詞將在堆疊上傳回一個"1"，但是片語『淡 藍色』將會 傳回一個"9"。（這個緊鄰的『淡』會設定一個旗標，然後它被『色彩』所使用，並且 再被清除為0。）如果真要考慮到可讀性，我們也許會定義出：
8 色彩 暗灰
14 色彩 黃色
再一次地，經由這種方式，我們又完成了一個較令人愉快的語法與較短小的目的碼。
─────────────────────────────────────
提示 不要為了分解而分解。使用原本的陳腔濫調（cliches）。
─────────────────────────────────────
這個片語
OVER + SWAP
在一些應用中很常見。（它轉換一個地址與計數值為一個結束地址與起始地址，以適 合『DO LOOP』的結構使用。） 另一個常用的片語是
1+ SWAP
（它將"第一個索引值"及"最後一個索引值"的順序重新安排為"最後一個索引值加一" 及"第一個索引值"的新順序，以供『DO』這個詞所需。） 把這些片語分解出來做成一個詞，像是『RANGE』（前面那一個片語），是有些令人 心動。
───────────────────────────────────────
Moore說：
那個特別的片語『OVER +
SWAP』就恰在"是否要成為一個有用的詞？"的邊緣上。經 常的，你把某一些東西定義成一個詞，而結果是你只使用它一次。如果你把這樣的
一個片語定出名字，你會很難記住『RANGE』確實做了什麼。在你的心中，你看不到 這個操作。『OVER +
SWAP』片語比起『RANGE』這個詞有較大的助憶性（mnemonic value）。
───────────────────────────────────────
我稱這類片語為"陳腔濫調"。他們黏在一起，以表示一種有意義的功能。你不必去"記住" 這個片語是如何工作的，只要記住它做了什麼就好了。而且你也不需要再多記一個額外 的名字。
編譯時區內的分解（Compile-Time Factoring）
在最後這一節，我們將檢視很多種用來組織程式碼和資料的技巧，以減少重複性 （redundance）。 我們也能將有限重複（limited redundance）的原則用在編譯上，讓符式為我們 做一些煩人的工作。
─────────────────────────────────────
提示 為了能得到最大的可維護性，就要限制重複的東西，甚至是在編譯時區中。
─────────────────────────────────────
假設在我們應用中需要畫出像圖6-1的9個盒子。
圖6-1 我們所要的顯示
在這個設計中，我們需要常數來代表每個盒子的尺寸，盒子間的空隙，第一個盒子 的左上角座標等等的資訊。很自然地，我們能定義：
8 常數 盒寬
5 常數 盒高
4 常數 路寬
2 常數 街寬
（街為東西向；路為南北向。） 現在，為了要定義它的左邊界限，我們也許先在心中計算出它。我們想要把這些盒 子放在一個80行寬的螢幕中間位置。我們先將它的寬度從80中減去，再除以2以得到左邊 界。全部盒子所佔的寬度為
8 + 4 + 8 + 4 + 8 = 32
（三個盒寬加上二條路寬）。 (80-31) / 2 = 24. 所以，我們很自然地定義：
24 常數 左邊界
同樣的方法也用來計算『右邊界』。 但是，萬一將來我們需要重新設計這個圖案，盒寬改變了，也許盒間的空隙也改變 了？我們就要重新再計算出邊界。 在符式的環境下，即使在編譯時區中，我們也能充份地運用符式的全部能力。為 何不讓符式為我們做計算呢？
盒寬 3 * 路寬 2 * + 80 對調 - 2/ 常數 左邊界
盒高 3 * 街寬 2 * + 24 對調 - 2/ 常數 上邊界
─────────────────────────────────────
提示 如果一個常數值是依賴著另一個稍早的常數值，就利用符式來計算出這第二個值。
─────────────────────────────────────
當應用程式在執行時，這些計算並不出現，所以執行的速度不受影響。 這裡是另一個例子。圖6-2的碼是用來畫出一個外形。詞『DRAW』會在『POINTS』 表中的每一個xy座標位置上畫上一個星號。（注意：詞『XY』會將游標定位到堆疊上 所指的 ( x y )座標上。） 注意跟在表後面的那一行碼：
HERE POINTS - ( /table ) 2/ CONSTANT #POINTS
圖6-2 "編譯時區"中有限重複的另一個例子
: P ( x y --) C, C, ;
CREATE POINTS
10 10 P 10 11 P 10 12 P 10 13 P 10 14 P
11 10 P 12 10 P 13 10 P 14 10 P
11 12 P 12 12 P 13 12 P 14 12 P
HERE POINTS - ( ?table ) 2/ CONSTANT #POINTS
: @POINTS ( i --x y ) 2* POINTS + DUP 1+ C@ SWAP C@ ;
: DRAW #POINTS 0 DO I @POINTS XY ASCII * EMIT LOOP ;
片語『HERE POINSTS -』用來計算出表格所用掉的字元數。將這個值除以2，就會得到表中的點的數量；這個值就變成常數『#POINTS』，被『DRAW』中的『DO LOOP』所使用。
這種做法讓你能在表中加入或刪除一個點，而不用去修改點的總數。符式為你做出這個計算。
經由定義字來實現編譯時區的分解
讓我們對同一個問題 --定義出一組相關的地址-- 檢視一系列的做法。下面是第一種嘗試：
HEX 01A0 CONSTANT BASE.PORT.ADDRESS
BASE.PORT.ADDRESS CONSTANT SPEAKER
BASE.PORT.ADDRESS 2+ CONSTANT FLIPPER-A
BASE.PORT.ADDRESS 4 + CONSTANT FLIPPER-B
BASE.PORT.ADDRESS 6 + CONSTANT WIN-LIGHT
DECIMAL
這個主意是正確的，但是做法卻很難看。唯一改變的元素是一個位移值和要被定義的埠的名字；其它每件事都是重複的。這種重複性建議我們使用一個定義字。
下一個方式的可讀性較高。它把所有重複的碼組合成一個定義字中的"DOES"部份：
: PORT ( offset --) CREATE ,
DOES> ( -- 'port ) @ BASE.PORT.ADDRESS + ;
0 PORT SPEAKER
2 PORT FLIPPER-A
4 PORT FLIPPER-B
6 PORT WIN-LIGHT
在這個解答中，我們在每次呼叫這些名字的時候，才進行位移值的計算（執行時區）。
如果我們能在編譯時就做這個計算，則執行會更有效率，像這樣：
: PORT ( offset -- ) BASE.PORT.ADDRESS + CONSTANT ;
\ DOES> ( -- 'port )
0 PORT SPEAKER
2 PORT FLIPPER-A
4 PORT FLIPPER-B
6 PORT WIN-LIGHT
在這裡我們建造一個定義字『PORT』，它有一個獨特的"編譯時區"的行為，就是把位移值加到『BASE.PORT.ADDRESS』上，並且用它定義出一個常數。
我們甚至可以更進一步。假設全部的輸出入埠的地址都是相隔著二個byte。那麼在這個例子中，我們就沒有理由必須說出這個位移值。這組依序的數值
0 2 4 6
本身就是多餘的。
在下面這個版本，我們從堆疊上是『BASE.PORT.ADDRESS』開始。定義字『PORT』複製這個地址，將它定為一個常數，然後加2到這個仍然留在堆疊的地址上，給下一個輸出入埠使用。
: PORT ( 'port -- 'next-port ) DUP CREATE , 2+ ;
\ DOES> ( -- 'port )
BASE.PORT.ADDRESS
PORT SPEAKER
PORT FLIPPER-A
PORT FLIPPER-B
PORT WIN-LIGHT
DROP ( port.address )
注意，在我們定義第一個輸出入埠之前，必須先在堆疊上提供那個初始的地址，然後，當我們完成了定義所有的輸出入埠之後，再用『DROP』除去最後仍留在堆疊上的地址。
最後一個建議。這個基礎埠（base-port）的地址是很有可能會改變的，因此應該只被定義在一個地方。這並不是說它必須被定義成一個常數。只要這個基本地址不會被這個埠的詞集之外用到，即使它是以數值的形態被參考，也是無礙的。
實現階段中的反覆作為
在本書中的前面部份，我們討論過反覆作為的方式，特別注意到它對設計階段的影響。現 在我們正討論到實現階段，讓我們看看這種方式如何真正地被使用在寫碼上。
─────────────────────────────────────
提示 一次處理問題的一面
─────────────────────────────────────
假設我們被交付一個寫碼的工作，要建一個詞來畫出或拭除在x-y座標上的盒子。（這是 我們在"編譯時區的分解"一節中所提過的相同問題。） 我們首先集中注意力在畫盒子上，暫時不要管拭除它這件事。我們可能做出：
: LAYER WIDE 0 DO ASCII * EMIT LOOP ;
: BOX ( upper-left-x upper-left-y -- )
HIGH 0 DO 2DUP I + XY LAYER LOOP 2DROP ;
在經過測試並確定它能正常工作之後，我們現在轉向如何使用相同的碼來擦拭盒子的問題 上。這個答案是簡單的：我們只要將送出的碼由一個星號改為一個空白就可以了。這需 要增加一個變數和一些設定它內容的詞。所以：
VARIABLE INK
: DRAW ASCII * INK ! ;
: UNDRAW BL INK ! ;
: LAYER WIDTH 0 DO INK @ EMIT LOOP ;
BOX 的定義，和應用程式中的剩餘部份，都保持不變。 這個方式允許下面的語法
( x y ) DRAW BOX
~FB7BB1; 或~I;
( x y ) UNDRAW BOX
經由從一個明確的值轉變為一個包含著一個值的變數，我們增加了一層的間接（a level of indirection）。在這個例子，我們"反向"地加上了這層間接，也就是在『LAYER』的 定義中加上一層新的複雜性，而不是增加這個定義的長度。 經由一次只致力於一個問題面上，你就能更有效率的解決問題的每個面相。如果你 的想法裏有個錯誤，它就不會被那些尚末經測試及驗証的另一面相的碼所掩蓋，因而也 就能較容易地被發現出來。
─────────────────────────────────────
提示 不要一次改正太多。
─────────────────────────────────────
當你在編輯你的應用程式時 --加上一個新的功能或者修正一些地方-- 經常會被誘惑 著一次就把它們同時都做完或改正過來。我們的忠告是：不要這樣做。 在每個「編輯--編譯」的循環中，在你能接受的範圍內，儘可能地少做改變。在你 繼續下一步之前，要確定測試過了每個修正後的版本。你會驚訝，在做了三個看似簡單的 修改，再重新編譯之後，竟然發現沒有一個是能正確工作的，而這種情況卻經常的發 生。 一次只做一個改變，就能保証當事情不對的時候，你知道原因何在。
─────────────────────────────────────
提示 不要嘗試著太早去預設分解的方式。
─────────────────────────────────────
有些人奇怪為什麼大部份的符式系統都沒有定義一個陣列的詞。這條規則就是理由。
───────────────────────────────────────
Moore說：
我經常有陣列這種等級的東西。最簡單的陣列只是付予一個地址一個標記，而這個 標記會傳回這個地址給你。你能像下面這樣地定義出一個陣列
CREATE X 100 ALLOT
然後說
X +
或者你能說
: X X + ;
最困擾我的一個問題是，是否值得為那個特別的資料結構做出一個定義字來？我會 有足夠多的地方來使用它，而使我那多付出的工作變的值得嗎？
我很難事先知道將來是否會需要超過一個以上的陣列。所以，通常我並不定義 ARRAY 這個字。 當我發現我需要二個陣列之後，問題就在邊緣上了。
假如我需要三個，那麼答案就很清楚了。除非他們是不同的。而經常地，他們卻真 是不同的。你可能需要它為你取得內容，你也可能需要字元的陣列，或位元的
陣列。你可能想要做上下限的檢查，或存下它目前的長度以便你能加上東西到它的 尾端。
我咬緊牙根並且說，「我應該將這個字元陣列做成一個胞元（cell）陣列，以便能 讓這個資料結構適用於我現在已經有的詞嗎？」
問題愈複雜，你就愈不容易找到一個能適用的一種通用型的資料結構。一個真正 複雜的資料結構，能夠被普遍地使用著的機會是很小的。一個成功的這種例
子是符式的詞典。它的結構堅固，又很有彈性。它在符式裡到處被使用著。但是這 種例子畢竟少見。
如果你選擇去做出陣列的定義字，其實你就是完成了一個分解的步驟。你已經從將來 所有會包含陣列的字中，分解出陣列這個概念。你已經到達了另一層次的抽象。
建造抽象的層次是一種動態的過程，它不是你能事先預知的。
───────────────────────────────────────
─────────────────────────────────────
提示 今天，讓它能工作。明天，再將它最佳化。
─────────────────────────────────────
───────────────────────────────────────
在有一天和Moore的面談中，那時他已經完成了一個電路板級（board level）的符式
電腦的設計，它使用一般市面上現成可用的IC來組成。做為設計那片板子的工具箱的 一部份，他用符式建了一個模擬器，來測試板子上的邏輯電路：
直到這個早上我才認識到，我一直將"對晶片的描述"與"對這些晶片在板子上的配置 的描述"混在一起。在當時，它非常的方便於用來達到我的目的，但是當我要在另一
片板子上使用這些相同的晶片時，才發現到我把事情安排的很糟。 我應該將對晶片的描述與對晶片的使用分解到不同的地方。這樣我就會有一個晶片
描述語言了。好吧，也許是因為當我正在做這件事的時候，我對那種層次的最佳化 並不感興趣。
即使後來這個念頭曾經出現過，我也可能會說：「讓我晚一點再去做這件事」， 然後就投入到我正在做的事情當中。在那時，最佳化對我來說並不是最重要的。
當然，我會試著做出良好的分解。但是，如果在那時還看不出個好方法，我就會說 ：「先讓它能工作再說」。
我並不是懶惰，我只是知道將來會有一些東西以某種方式來影響這個決定，而怎麼 影響卻是我現在無法預知的。現在就試著最佳化是愚蠢的。除非整個情況清楚地
出現在我面前，我是無法知道那個最佳化應該是什麼樣子的。
───────────────────────────────────────
在這一節中所做的這些觀察，是不會與在這之前所談論的資訊隱藏和預測將來會改變的 元素這些事相衝突的。一個好的程式設計師會不斷地嘗試平衡於「先花費時間來建構出 具有接受變化性的事物」和「以後如果有需要，再花費時間來修改它」這二種選擇上。 做這些決定需要經驗。但是，做為一個一般性的規則：
─────────────────────────────────────
提示 要經由組織資訊（organizing
information）來預測可能會變化的事物，而不是以增 加複雜度來達成。只有在為了使目前的反覆週期能正確工作的需要下，才能增加複 雜度。
─────────────────────────────────────
結語
本章中我們討論了分解因子所使用的各種技巧和準則。也檢視了反覆作為的方式如何應 用在實現階段中。
參考書籍
1. W.P. Stevens, G.J. Myerg, and L.L. Constantine, IBM Systems Journal, vol. 13, no. 2, 1974, Copyright 1974 by Intermltional Buginess Machines Corporation.
2. G.A. Miller, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing.Information," Psychol. Rev., vol. 63, pp. 81-97, Mar. 1956.
3. Kim R. Harris, "Definition Field Address C,onversion Operators," FORTH-83 Standard, FORTH Standardg Team.