2007-8-21，06-9-11

//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 需要编写特殊的代码来维护监听器表。也就是说这个特殊化的接口类需要特殊的管理类。
 》优点：
 各个状态单独处理使思路清晰，而且有更大的灵活性。扩展类的时候按需要更换代码，非常方便。