class//BkMaker

其實，我一直覺得，這一個類別的創造是好設計，但是這一個類別的內部，是不好的設計，因為創造它的過程，是一次的程式大改。為了讓Cartridge2內可以記載的背景資訊，留下一個一致的介面讓CPartternDialog啟動背景繪圖，剩下的細節都交給它。

• 一個ColorRef是背景色，每一個背景都適用。
• 一個ColorRef是給CrossTalk中間的方塊。
• Ca210*是給Nits做自動亮度追縱用的。

在此有一個特別的要講一下，就是BkMaker本身是一個SmartPointer，可以計數自己指向的物件數，讓nits的點位，可以都用同一個BkMaker物件(中心點以外的背景色和中心點追縱到的背景色為同一筆資料)，並且不會隨著Cartridge2物件複製(只複製BkMaker的address)而銷毀BkMaker的物件。

最後，可以發現，在*.h檔中，罕見的出現了空函數。這樣的設計在於這些特殊的函數，必須在BkMaker有virtual的介面，可以配合「繼承」使用「動態連結」的方式操作其它的子類別的函式實作。

BkMaker.h

#ifndef BKMAKER_H
#define BKMAKER_H

#include "CColorRef.h"
#include "CA210.h"

enum NitsDirect{ND_NoDefine = 0, ND_Pos, ND_Neg};

class BkMaker
{
//smart ptr
    int* ptr_i;
    int* cnt;
public:
    const BOOL IsPtrToNull() const;
    const int GetPtrCnt() const;
public:
    BkMaker();
    BkMaker(const BkMaker& bkN);
    ~BkMaker();
    BkMaker& operator=(const BkMaker& sp);

//背景色
private:
    ColorRef m_BkColor;
public:
    const ColorRef _GetBkColor() const;
              void _SetBkColor(const ColorRef&);
//共用介面
public:
    virtual void Draw(CPaintDC& dc);

//Crosstalk的介面
protected:
    ColorRef  m_rectColor;
    CRect     m_centerRect;
public:
    virtual void CT_SetRect(const CRect& _rect, const ColorRef& clr){ };

//Nits的介面
protected:
    CWnd*  m_pdlgcWnd;
    Ca210* m_pCa210;
public:
    virtual void NT_SetWnd(CWnd* cWnd){ };
    virtual void NT_SetCa(Ca210* pCa){ };

protected:
    NitsDirect m_NitsDirect;
    int m_NitsLv;  //參數
public:
    virtual    void NT_SetNitsLv(const int&){  };
    virtual    void NT_colorReviseByNits(ColorRef&){  };

};

#endif