The U-D-C-L feedback loop

應用 How To Solve It方法寫程式時，並不期望將四個步驟實施一次即能解決問題；通常這四個步驟需重複實施，構成一個U-D-C-L迴授圈(feedback loop)：

U--D--C--LU--D--C--LU ... U--D--C--L
1---------2---------3-... n--------done!               

每一U-D-C-L迴授圈為一輪(one iteration)。在每次實施L步驟時，手邊得到程式必須是一個可執行、可驗證是否完成的 working software。L步驟執行就是迴授：你想確認問題是否已經解決？如L步驟回顧的程式仍不能滿足做完(done)的條件，則找出待解決的議題，並進入下一輪 -- 仍以U步驟為首，因為前一次L可能讓你對問題有了新的理解。

你可能要問：為什麼不一次做完？原因很多，例如程式具相當規模，你想先完成關鍵架構，再完成其他部份；問題夠複雜，你決定先加以分解成數個子問題，逐步個別解決與整合，直到整個問題被解決為止；程式中使用到一個關鍵的技術，你仍不知道會花多少間才能完成，故你想先以一個簡單的作法實現；等等。

對已熟悉C語言但初學C++者而言，這個作法可讓他先以已知的C language features先將問題大致解決，暫不去理會C++特有的 language features，然後在回顧中，列出必要的C++ language features 學習議題，並在稍後的U-D-C-L迴授圈加以完成。從學習的角度來說，這讓學習者在學習相關C++ language features時有特定的目標。


舉個例子。初學者第一次撰寫C++ class時的建構元（constructor）時，經常會被引導去讀完不同建構元的定義方式與規則，如default constructor、copy constructor、data member 初值化等。這些規則可以輕易的塞滿教科書的一整章！你可以查看常見的C++教科書，輕易的印證這個觀察。


我並不是說C++教科書不應該把建構元相關的規則、例子集中在同一章，因為這樣作有它的好處，例如便於查閱。但身為學習者，你必須瞭解這樣的編排並非要你從 第一頁讀到最後一頁；在適度的引導下，你應該可以選擇性的閱讀必要的內容--以完成當下這一個工作為範圍--漸漸的學完大部分的C++ language features。

How To Solve It的目的之一是提供這樣的一個導引。下一篇文章，我將用一個例子來說明。

© Y C Cheng, 2013. All rights reserved.