//19:39 2007-8-21 錦天
問題分解示意圖：
方案1：
1
問題
|
+———————+
| |
子問題1 子問題2
2
問題
|
+—————————+
| |
子問題1 子問題2
| |
+————+ +————+
| |
子問題11 子問題21
3
問題
|
+—————————+
| |
子問題1 子問題2
| |
+————+ +————+
| | | |
子問題11 子問題12 子問題21 子問題22
方案2：
1
問題
|
+———————+
| |
子問題1 子問題2
2
問題
|
+—————————+
| |
子問題1 子問題2
|
+————+
| |
子問題11 子問題12
3 問題
|
+—————————+
| |
子問題1 子問題2
|
+————+
| |
子問題11 子問題12
|
+——+
111 112
區別：
1 方案1同時進行所有子問題，那麼，一邊出問題，其他的相關地方馬上停止；
方案2深入進行一個子問題，一直到這個子問題被解決纔開始其他子問題，不容易與其他部分集成；
2 方案1使開發者思路不斷切換，容易紊亂；
方案2始終專注一個問題，符合常規思考習慣，但容易讓人忘了大局；
建議：最好不要使用方案2，儘量使用方案1，畢竟是在做大的開發作業。
//2007-10-8 18:12:20
class A
{
protected:
void funA();
};
class B : public A
{
A* a;
public:
void funB()
{
a->funA(); //錯誤，VS2005編譯通不過！
this->funA();//OK
}
};
就這個問題把我鬱悶了好久！
//2007-10-9 12:28:10
做事情要又計劃,看看別人的項目經驗,學習一下吧.
//19:21 2007-10-29
基於接口的開發的缺陷：你總是將工作交個接口，卻忽略了內在數據結構的設計，這必然在進行接口實現的時候被大量的問題所淹沒。所以，在UML中需要流程圖，類圖，對象圖，狀態圖，活動圖等這麼多手段來對一個問題進行建模。
那麼得出的結論是：在設計的時候，需要考慮下重點對象的數據結構，這有利於作出更好的設計。畢竟，程序最後都是一堆數據。
還有，如果面對的問題比較複雜，可以考慮UML的問題描述手法，多角度看問題。
UserInterface 項目
( 06-9-11 )
關於鼠標和鍵盤事件的處理方式上，使用這樣的接口：
// 第一種類型
class EventListener
{
public:
void processEvent (void *event) = 0;
};
然後的代碼：
class Button : public EventListener
{
public:
void processEvent (void *e)
{
KeyEvent *ke = (KeyEvent*)e;
if (ke->keypressed==true)
{
處理鍵盤按下事件
}
else
{
處理鍵盤松開事件
}
}
}
// 第二種類型
class KeySensor
{
public:
void onKeyDown (int key) = 0;
void onKeyUp (int key) = 0;
};
class Button: KeySensor
{
public:
void onKeyDown (int key)
{
處理鍵盤按下事件
}
void onKeyUp (int key)
{
處理鍵盤松開事件
}
}
分析：
方案一
》缺點：
將各種狀態集中在一個接口裏面處理，容易使代碼混亂，更重要的是，降低了Button類
被第三者繼承的方便性，他必須重寫的方法全部實現，即便是想改變一個狀態。
》優點：
這種非常通用的接口可以減少一些重複的代碼，建立統一的接口標準。
方案二
》缺點：
管理接口的InputManager 需要編寫特殊的代碼來維護監聽器表。也就是說這個特殊化的接口類需要特殊的管理類。
》優點：
各個狀態單獨處理使思路清晰，而且有更大的靈活性。擴展類的時候按需要更換代碼，非常方便。
