2009年5月31日
2009年5月31號下午2點半，我離開了我的學校，離開我的哥們，離開了生活了充實的4年的地方...
明天，我就正式成為程序員了。我是多么地幸運，能將興趣當成工作，我發(fā)誓，我盡我的能力好好干。
我沒忘記我的理想，沒忘記我的抱負。
明天，我掀開我人生的新一頁...
請看一個例子：
1
#include <windows.h>
2#include <tchar.h>
3
4
5int APIENTRY _tWinMain(
6 HINSTANCE hInstance,
7 HINSTANCE hPrevInstance,
8 LPSTR lpCmdLine,
9 int nCmdShow
10 )
11
{
12
UNREFERENCED_PARAMETER( hInstance );
13 UNREFERENCED_PARAMETER( hPrevInstance );
14 UNREFERENCED_PARAMETER( lpCmdLine );
15 UNREFERENCED_PARAMETER( nCmdShow );
16
17 HWND hwnd = ::GetDesktopWindow();
18
19 ::MessageBox( hwnd, _T( "First Windows" ), _T( "Example" ), MB_OK );
20
21 return 0;
22
}
這個例子是大山哥哥在他的BLOG中Windows API精講一日一練的例子。
奇怪吧，這次的WinMain函數(shù)又不一樣了。Windows編程難學，就是因為它那么多宏，它偉大之處也是因為它的宏，可以屏蔽硬件層、字符集對程序的影響。
一般的WinMain函數(shù)是這樣寫的: int WINAPI WinMain(...)，那現(xiàn)在的這種又是怎樣出來的呢？
APIENTRY在程序就是一個宏：#define APIENTRY WINAPI，那么我們就可以不管那個前綴了。
你肯定想不到的是，_tWinMain也是一個宏。它是定義在<tchar.h>中的。你可以試試將#include <tchar.h>去掉，你的程序肯定找不到入口點。
同樣的，_T也是一個宏。
這兩個宏其實是為了適應UNICODE和以前單字符的應用程序。
由于Windows這兩個API的定義是不一樣的，如下：
UNICODE的定義：
#define _tWinMain wWinMain
單字符的定義：
#define _tWinMain WinMain
只要經過這樣的宏定義后，就可以適應不同字符寬度的函數(shù)接口了。
好，看函數(shù)里面。
函數(shù)里面第一句又是一個宏，暈...怎么老是它...不過要在Windows編程，必須愛上它。
這個宏與Windows API無關，UNREFERENCED_PARAMETER 展開傳遞的參數(shù)或表達式，其目的是避免編譯器關于未引用參數(shù)的警告。當然你也可以在編譯器屬性那里
修改編譯的警告級別。
例子中的4句宏，就是為了關掉編譯器對WinMain函數(shù)4個參數(shù)未引用的報錯。避免了幾個警告的產生，呵呵。。。
GetDesktopWindow這個該不是宏了吧，哈哈。。。
MSDN上說：The GetDesktopWindow function returns a handle to the desktop window. The desktop window covers the entire screen.
The desktop window is the area on top of which other windows are painted.
這個函數(shù)返回了桌面的Handle，桌面大家都知道吧？
MessageBox想不到也是一個宏，它的定義是：
#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif // !UNICODE
很明顯是為了兼容字符集參數(shù)而定義的。難道Windows API函數(shù)的參數(shù)有字符串的，都是一個宏嗎？
MessageBox可能見得很多，最怕的大概就是“警告：內存出錯，程序退出”了。
這是MessageBox函數(shù)的聲明
int MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
);
參數(shù)一hWnd是一個HWND，它是這個MessageBox屬于的窗口的HWND,如果它為NULL,則MessageBox不屬于任何一個窗口。
參數(shù)二lpText是這個MessageBox顯示的消息內容，為了迎合Microsoft的好意，我們都應該用宏來傳入?yún)?shù)，來兼容字符串。
參數(shù)三lpCaption是這個MessageBox的標題內容。
參數(shù)四uType則是這個MessageBox的類型，它可以改變整個MessageBox的行為和樣式哦。它是一組符號標識(flags),如：MB_OK。可以用"|"操作符來進行組合
返回值呢？當然是你在MessageBox上的操作啦。返回值一般用宏來表示，如：IDABORT，IDOK。
誰是第一個Windows API？無可置疑，當然是WinMain Function啦。
MSDN上說：The WinMain function is the conventional name for the user-provided entry point for a Microsoft Windows-based application.
即：WinMain函數(shù)是Microsoft的一個傳統(tǒng)函數(shù)命名，它是提供給用戶的Windows應用程序的入口點。
它的函數(shù)聲明如下：
int WINAPI WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
寫慣C++ console程序的人可能會很奇怪，main函數(shù)一般不是這樣寫嗎（ int main() ）？怎么會在函數(shù)聲明中間加了個詞(WINAPI)呢？
其實WINAPI是一個宏，MSDN上說：Calling convention for system functions. This type is declared in WinDef.h as follows: #define WINAPI __stdcall
那么WINAPI就是指_stdcall了。
在網上查了一下，_stdcall還有其他同類，_cdecl _pascal _fastcall...怎么那么多的？
_stdcall _cdecl _pascal _fastcall這些關鍵字是什么意思，有什么區(qū)別呢？
在網上查了一下，總結一下答案：
（1）其實它們就是關于堆棧的一些說明，首先是函數(shù)參數(shù)壓棧順序，其次是壓入堆棧的內容由誰來清除，調用者還是函數(shù)自己？
這些開關用來告訴編譯器產生什么樣的匯編代碼。
（2）VC有兩種函數(shù)調用方式 一種是__stdcall，另一種是__cdecl
函數(shù)的調用方式有兩種一種是PASCAL調用方式(_stdcall)，另一種是C調用方式(_cdecl)
使用PASCAL調用方式，函數(shù)在返回到調用者之前將參數(shù)從棧中刪除
使用C調用方式，參數(shù)的刪除是調用者完成的
WinMain函數(shù)是由系統(tǒng)調用的，Windows系統(tǒng)規(guī)定由系統(tǒng)調用的函數(shù)都遵守PASCAL調用方式
但是VC中函數(shù)的缺省調用方式是__cdecl，也就是C調用方式
所以在WinMain前顯示的聲明。
在Windows編程中將遇到很多聲明修飾符，如CALLBACK,WINAPI,PASCAL這些在Intel CPU的計算機上都是__stdcall
（3）__cdecl是C/C++和MFC程序默認使用的調用約定，也可以在函數(shù)聲明時加上__cdecl關鍵字來手工指定。采用__cdecl約定時，
函數(shù)參數(shù)按照從右到左的順序入棧，并且由調用函數(shù)者把參數(shù)彈出棧以清理堆棧。
因此，實現(xiàn)可變參數(shù)的函數(shù)只能使用該調用約定。
由于每一個使用__cdecl約定的函數(shù)都要包含清理堆棧的代碼，所以產生的可執(zhí)行文件大小會比較大。
__cdecl可以寫成_cdecl。
__stdcall調用約定用于調用Win32 API函數(shù)。采用__stdcal約定時，函數(shù)參數(shù)按照從右到左的順序入棧，被調用的函數(shù)在返回前清理傳送參數(shù)的棧，
函數(shù)參數(shù)個數(shù)固定。由于函數(shù)體本身知道傳進來的參數(shù)個數(shù)，因此被調用的函數(shù)可以在返回前用一條ret n指令直接清理傳遞參數(shù)的堆棧。
__stdcall可以寫成_stdcall。
__fastcall約定用于對性能要求非常高的場合。__fastcall約定將函數(shù)的從左邊開始的兩個大小不大于
4個字節(jié)（DWORD）的參數(shù)分別放在ECX和EDX寄存器，其余的參數(shù)仍舊自右向左壓棧傳送，被調用的函數(shù)在返回前清理傳送
參數(shù)的堆棧。
__fastcall可以寫成_fastcall。
（4）thiscall僅僅應用于“C++”成員函數(shù)。this指針存放于CX/ECX寄存器中，參數(shù)從右到左壓。thiscall不是關鍵詞，因此不能被程序員指定。
（5）naked call。當采用其他的調用約定時，如果必要的話，進入函數(shù)時編譯器會產生代碼來保存ESI，EDI，EBX，EBP寄存器，
退出函數(shù)時則產生代碼恢復這些寄存器的內容。
·特別說明
1. 在默認情況下，采用__cdecl方式,因此可以省略.
2. WINAPI一般用于修飾動態(tài)鏈接庫中導出函數(shù)
3. CALLBACK僅用于修飾回調函數(shù)
4. 你可能已經發(fā)現(xiàn)，VC下和BCB下對WINAPI的定義不同，那么你至少理解了
為什么不能直接從BCB下調用VC的dll的一個原因了。
不查不知道，一查嚇一跳，怎么那么多規(guī)則的？整理了一下思路，其實并不復雜。
VC默認的是_cdecl方式，Win32 API函數(shù)是用_stdcall方式的，他們都是將函數(shù)參數(shù)從右到左入棧的。
_cdecl方式的每個函數(shù)都有清理堆棧的代碼，可以實現(xiàn)可變參數(shù)列表，但可執(zhí)行文件大小比較大。_stdcall方式是調用者清理堆棧的。
_fastcall的特點是它將參數(shù)左邊的兩個參數(shù)放在寄存器上，比較快。其余參數(shù)還是在堆棧中，堆棧還是由函數(shù)自己清除。
其它就不太清楚了。
好，該看看函數(shù)的參數(shù)了，hInstance是當前應用程序實例的Handle.
第二個參數(shù)hPrevInstance應用程序上一個實例的Handle。MSDN說：如果你要知道應用程序是否有另一個實例，建議使用Mutex（互斥體）來實現(xiàn)。此時，我想到了
單例模式，用Mutex來實現(xiàn)只運行一個實例。
第三個參數(shù)lpCmdLine是一個字符串，是命令行參數(shù)。
第四個參數(shù)nCmdShow是一個int，指明Window應該怎么現(xiàn)實，Windows定義了一系列宏，來幫助記憶，以SW開頭，如：SW_SHOW
最后是返回值，它是一個int。
MSDN說：If the function succeeds, terminating when it receives a WM_QUIT message, it should return the exit value contained in that message's wParam parameter. If the function terminates before entering the message loop, it should return zero.
如果它成功的話，它會一直運行，知道收到WM_QUIT消息，它應該返回消息的wParam參數(shù)的退出值。如果函數(shù)在進入消息循環(huán)前退出，它應該返回0。
2009年3月8日
現(xiàn)代生物遺傳學中描述的生物進化理論:
遺傳物質的主要載體是染色體(chromsome),染色體主要由DNA和蛋白質組成。其中DNA為最主要的遺傳物質。
基因(gene)是有遺傳效應的片斷,它存儲著遺傳信息,可以準確地復制,也能發(fā)生突變,并可通過控制蛋白質的合成而控制生物的狀態(tài).生物自身通過對基因的復制(reproduction)和交叉(crossover,即基因分離,基因組合和基因連鎖互換)的操作時其性狀的遺傳得到選擇和控制。生物的遺傳特性,使生物界的物種能保持相對的穩(wěn)定;生物的變異特性,使生物個體產生新的性狀,以至于形成了新的物種(量變積累為質變),推動了生物的進化和發(fā)展。
遺傳學算法和遺傳學中的基礎術語比較
| 染色體(chromosome) |
數(shù)據(jù),數(shù)組,序列 |
| 基因(gene) |
單個元素,位 |
| 等位基因(allele) |
數(shù)據(jù)值,屬性,值 |
| 基因座(locus) |
位置,iterator位置 |
| 表現(xiàn)型(phenotype) |
參數(shù)集,解碼結構,候選解 |
| 遺傳隱匿(epistasis) |
非線性 |
染色體又可以叫做基因型個體(individuals),一定數(shù)量的個體組成了群體(population),群體中個體的數(shù)量叫做群體大小。各個個體對環(huán)境的適應程度叫做適應度(fitness)
遺傳算法的準備工作:
1)數(shù)據(jù)轉換操作,包括表現(xiàn)型到基因型的轉換和基因型到表現(xiàn)型的轉換。前者是把求解空間中的參數(shù)轉化成遺傳空間中的染色體或者個體(encoding),后者是它的逆操作(decoding)
2)確定適應度計算函數(shù),可以將個體值經過該函數(shù)轉換為該個體的適應度,該適應度的高低要能充分反映該個體對于解得優(yōu)秀程度。非常重要的過程！
遺傳算法的基本步驟
遺傳算法是具有"生成+檢測"(generate-and-test)的迭代過程的搜索算法。
基本過程為:
1)編碼,創(chuàng)建初始集團
2)集團中個體適應度計算
3)評估適應度
4)根據(jù)適應度選擇個體
5)被選擇個體進行交叉繁殖,
6)在繁殖的過程中引入變異機制
7)繁殖出新的集團,回到第二步
一個簡單的遺傳算法的例子:求 [0,31]范圍內的y=(x-10)^2的最小值
1)編碼算法選擇為"將x轉化為2進制的串",串的長度為5位。(等位基因的值為0 or 1)
2)計算適應度的方法是:先將個體串進行解碼,轉化為int型的x值,然后使用y=(x-10)^2作為其適應度計算合適(由于是最小值,所以結果越小,適應度也越好)
3)正式開始,先設置群體大小為4,然后初始化群體 => (在[0,31]范圍內隨機選取4個整數(shù)就可以,編碼)
4)計算適應度Fi(由于是最小值,可以選取一個大的基準線1000,Fi = 1000 - (x-10)^2)
5)計算每個個體的選擇概率.選擇概率要能夠反映個體的優(yōu)秀程度.這里用一個很簡單的方法來確定選擇概率
P=Fi / TOTAL(Fi).
6)選擇.
根據(jù)所有個體的選擇概率進行淘汰選擇.這里使用的是一個賭輪的方式進行淘汰選擇.先按照每個個體的選擇概率創(chuàng)建一個賭輪,然后選取4次,每次先產生一個0-1的隨機小數(shù),然后判斷該隨機數(shù)落在那個段內就選取相對應的個體.這個過程中,選取概率P高的個體將可能被多次選擇,而概率低的就可能被淘汰.
下面是一個簡單的賭輪的例子
13% 35% 15% 37%
----------|----------------------------|------------|-*-------------------------|
個體1 個體2 個體3 ^0.67 個體4
隨機數(shù)為0.67落在了個體4的端內.本次選擇了個體4.
被選中的個體將進入配對庫(mating pool,配對集團)準備開始繁殖.
7)簡單交叉
先對配對庫中的個體進行隨機配對.然后在配對的2個個體中設置交叉點,交換2個個體的信息后產生下一代.
比如( | 代表簡單串的交叉位置)
( 0110|1, 1100|0 ) --交叉--> (01100,11001)
( 01|000, 11|011 ) --交叉--> (01011,11000)
2個父代的個體在交叉后繁殖出了下一代的同樣數(shù)量的個體.
復雜的交叉在交叉的位置,交叉的方法,雙親的數(shù)量上都可以選擇.其目的都在于盡可能的培育出更優(yōu)秀的后
代
8)變異
變異操作時按照基因座來的.比如說沒計算2萬個基因座就發(fā)生一個變異(我們現(xiàn)在的每個個體有5個基因座.也就是說要進化1000代后才會在其中的某個基因座發(fā)生一次變異.)變異的結果是基因座上的等位基因發(fā)生了變化.我們這里的例子就是把0變成1或則1變成0.
至此,我們已經產生了一個新的(下一代)集團.然后回到第4步,周而復始,生生不息下去:)
偽代碼實例(適合愛看代碼的朋友~):
//Init population
foreach individual in population
{
individual = Encode(Random(0,31));
}
while (App.IsRun)
{
//計算個體適應度
int TotalF = 0;
foreach individual in population
{
individual.F = 1000 - (Decode(individual)-10)^2;
TotalF += individual.F;
}
//------選擇過程,計算個體選擇概率-----------
foreach individual in population
{
individual.P = individual.F / TotalF;
}
//選擇
for(int i=0;i<4;i++)
{
//SelectIndividual(float p)是根據(jù)隨機數(shù)落在段落計算選取哪個個體的函數(shù)
MatingPool[i] = population[SelectIndividual(Random(0,1))];
}
//-------簡單交叉---------------------------
//由于只有4個個體,配對2次
for(int i=0;i<2;i++)
{
MatingPool.Parents[i].Mother = MatingPool.RandomPop();
MatingPool.Parents[i].Father = MatingPool.RandomPop();
}
//交叉后創(chuàng)建新的集團
population.Clean();
foreach Parent in MatingPool.Parents
{
//注意在copy 雙親的染色體時在某個基因座上發(fā)生的變異未表現(xiàn).
child1 = Parent.Mother.DivHeader + Parent.Father.DivEnd;
child2 = Parent.Father.DivHeader + Parent.Mother.DivEnd;
population.push(child1);
population.push(child2);
}
}
小結:
遺傳算法中最重要的過程就是選擇和交叉。
選擇要能夠合理的反映"適者生存"的自然法則，而交叉必須將由利的基因盡量遺傳給下一代(這個算法很關鍵！)
還有就是編碼的過程要能夠使編碼后的染色體能充分反映個體的特征并且能夠方便計算。
這篇文章是原來學習的一些回憶的整理,因為最近要實用了.不正確的地方還希望大家多多指出~
2009年3月5日
今天想練練手，所以寫了個螺旋數(shù)組：
1 #include <iostream>
2
3 using namespace std;
4
5 #define MAXSIZE 8
6
7 void left( int& x, int& y )
8 {
9 --y;
10 }
11
12 void right( int& x, int& y )
13 {
14 ++y;
15 }
16
17 void up( int& x, int& y )
18 {
19 --x;
20 }
21
22 void down( int& x, int& y )
23 {
24 ++x;
25 }
26
27 int main()
28 {
29 int numbers[MAXSIZE][MAXSIZE];
30 // 初始化數(shù)組，若數(shù)值為0，則代表還沒有被賦值
31 for( int i = 0; i<MAXSIZE; ++i )
32 for( int j = 0; j<MAXSIZE; ++j )
33 numbers[i][j] = 0;
34
35 enum Direction{RIGHT,DOWN,LEFT,UP}; // 移動方向
36 int x=0,y=0;
37 int Next = -1; // 下一個位置的值
38 Direction direct = RIGHT;
39 int count = MAXSIZE * MAXSIZE; // 還沒被賦值的數(shù)目
40 int value = 1; //將要被賦值的值
41
42 while( count > 0 )
43 {
44 Next = numbers[x][y];
45 if( Next == 0 && x<MAXSIZE && y<MAXSIZE ) // 無障礙，可以賦值
46 {
47 numbers[x][y] = value;
48 // 賦值成功，count減一, value加一
49 --count;
50 ++value;
51
52 // 設置Next
53 if( direct == RIGHT )
54 right( x, y );
55 else if( direct == DOWN )
56 down( x, y );
57 else if( direct == LEFT )
58 left( x, y );
59 else if( direct == UP )
60 up( x, y );
61 }
62 else // 有障礙，要轉彎
63 {
64 if( direct == RIGHT ) // 若原來方向是右的話，就轉彎向下
65 {
66 x = x + 1;
67 y = y - 1;
68 direct = DOWN;
69 }
70 else if( direct == DOWN ) //若原來方向是下的話，就轉彎向左
71 {
72 x = x - 1;
73 y = y - 1;
74 direct = LEFT;
75 }
76 else if( direct == LEFT ) //若原來方向是左的話，就轉彎向上
77 {
78 x = x - 1;
79 y = y + 1;
80 direct = UP;
81 }
82 else if( direct == UP) //若原來方向是上的話，就轉彎向右
83 {
84 x = x + 1;
85 y = y + 1;
86 direct = RIGHT;
87 }
88 }
89 }
90
91 for( int i = 0; i<MAXSIZE; ++i )
92 {
93 for( int j = 0; j<MAXSIZE; ++j )
94 {
95 cout<<numbers[i][j]<<" ";
96 }
97 cout<<endl;
98 }
99
100 return 0;
101 }
2009年3月4日
宏的單行定義
#define A(x) T_##x
#define B（x) #@x
#define C（x) #x
我們假設：x=1，則有：
A(1)------〉T_1
B(1)------〉'1'
C(1)------〉"1"
##代表“連接”
#@代表“轉為字符”
#代表 “轉為字符串”
define的多行定義
define可以替代多行的代碼，例如MFC中的宏定義（非常的經典）
#define MACRO(arg1, arg2) do { \
/* declarations */ \
stmt1; \
stmt2; \
/* ... */ \
} while(0) /* (no trailing ; ) */
關鍵是要在每一個換行的時候加上一個"\"
2009年3月3日
Win32應用程序有條明確的主線：
（1） 進入WinMain函數(shù)
（2） 設計一個Window
（3） 注冊這個Window
（4） 建立這個Window
（5） 顯示和更新這個Window
（6） 進入消息循環(huán)
好，我就先找WinMain函數(shù)吧。
我在C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc的appmodul.cpp的23行中找到了以下代碼：
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
_In_ LPTSTR lpCmdLine, int nCmdShow)
#pragma warning(suppress: 4985)
{
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}
_tWinMain是一個宏，詳細為： #define _tWinMain WinMain
所以這個確實是我們要找的WinMain函數(shù)
從代碼中看出，WinMain將參數(shù)全部交給AfxWinMain，來處理。
好，我又找AfxWinMain這個函數(shù)。
我在winmain.cpp的19行找到了AfxWinMain函數(shù)。
代碼：
int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
_In_ LPTSTR lpCmdLine, int nCmdShow)
{
ASSERT(hPrevInstance == NULL); // ASSERT在程序運行時它計算括號內的表達式，如果表達式為FALSE (0),
// 程序將報告錯誤，并終止執(zhí)行。如果表達式不為0，則繼續(xù)執(zhí)行后面的語句。
// ASSERT只有在Debug版本中才有效，如果編譯為Release版本則被忽略。
// assert()的功能類似，它是ANSI C標準中規(guī)定的函數(shù)，它與ASSERT的一個重要區(qū)別是可以用在Release版本中。
int nReturnCode = -1;
// AfxGetThread和 AfxGetApp 都是全局函數(shù)
CWinThread* pThread = AfxGetThread(); // 獲得正在執(zhí)行的線程，Must be called from within the desired thread.
CWinApp* pApp = AfxGetApp(); // 獲得A pointer to the single CWinApp object for the application
// AFX internal initialization
// This function is called by the MFC-supplied WinMain function, as part of the CWinApp initialization of a GUI-based
// application, to initialize MFC.
if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
goto InitFailure;
// App global initializations (rare)
if (pApp != NULL && !pApp->InitApplication()) //InitApplication已經過時，用InitInstance代替,完成MFC內部管理方面的工作
goto InitFailure;
// Perform specific initializations
if (!pThread->InitInstance()) // 初始化Instance，在每個 a copy of the program runs的時候，虛函數(shù)
{
if (pThread->m_pMainWnd != NULL)
{
TRACE(traceAppMsg, 0, "Warning: Destroying non-NULL m_pMainWnd\n");
pThread->m_pMainWnd->DestroyWindow(); // m_pMainWnd holds a pointer to the application's main window.返回一個CWnd.
// cWnd Destroys the attached Windows window.
}
nReturnCode = pThread->ExitInstance(); // to exit this instance of the thread
goto InitFailure;
}
nReturnCode = pThread->Run();
InitFailure:
#ifdef _DEBUG
// Check for missing AfxLockTempMap calls
if (AfxGetModuleThreadState()->m_nTempMapLock != 0)
{
TRACE(traceAppMsg, 0, "Warning: Temp map lock count non-zero (%ld).\n",
AfxGetModuleThreadState()->m_nTempMapLock);
}
AfxLockTempMaps();
AfxUnlockTempMaps(-1);
#endif
AfxWinTerm();
return nReturnCode;
}
找到了WinMain函數(shù)后，看了下MFC為我生成的類：
1. CTestApp 2. CTestView 3. CMainFrame 4. CTestDoc 5. CAboutDlg
查看CTestApp.cpp，發(fā)現(xiàn)了一個全局的CTestApp theApp，因為全局對象必須在main函數(shù)之前產生并初始化，所以應用程序調用的順序應該是
CTestApp的構造函數(shù) -> WinMain函數(shù)
又發(fā)現(xiàn)class CTestApp : public CWinApp,子類的構造函數(shù)在父類的構造函數(shù)調用之后調用，所以就搜索CWinApp吧。
在appcore.cpp的368行發(fā)現(xiàn)以下代碼：
CWinApp::CWinApp(LPCTSTR lpszAppName) // 此處的lpszAppName有個默認參數(shù)NULL
{
if (lpszAppName != NULL)
m_pszAppName = _tcsdup(lpszAppName); // 為lpszAppName分配內存
else
m_pszAppName = NULL;
// initialize CWinThread state
AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();
ENSURE(pModuleState);
AFX_MODULE_THREAD_STATE* pThreadState = pModuleState->m_thread;
ENSURE(pThreadState);
ASSERT(AfxGetThread() == NULL);
pThreadState->m_pCurrentWinThread = this; // 如果有子類繼承了CWinApp, this就是子類
ASSERT(AfxGetThread() == this);
m_hThread = ::GetCurrentThread();
m_nThreadID = ::GetCurrentThreadId();
// initialize CWinApp state
ASSERT(afxCurrentWinApp == NULL); // only one CWinApp object please
pModuleState->m_pCurrentWinApp = this; // 如果有子類繼承了CWinApp, this就是子類
ASSERT(AfxGetApp() == this);
// in non-running state until WinMain
m_hInstance = NULL;
m_hLangResourceDLL = NULL;v
m_pszHelpFilePath = NULL;
m_pszProfileName = NULL;
m_pszRegistryKey = NULL;
m_pszExeName = NULL;
m_pRecentFileList = NULL;
m_pDocManager = NULL;
m_atomApp = m_atomSystemTopic = NULL;
m_lpCmdLine = NULL;
m_pCmdInfo = NULL;
// initialize wait cursor state
m_nWaitCursorCount = 0;
m_hcurWaitCursorRestore = NULL;
// initialize current printer state
m_hDevMode = NULL;
m_hDevNames = NULL;
m_nNumPreviewPages = 0; // not specified (defaults to 1)
// initialize DAO state
m_lpfnDaoTerm = NULL; // will be set if AfxDaoInit called
// other initialization
m_bHelpMode = FALSE;
m_eHelpType = afxWinHelp;
m_nSafetyPoolSize = 512; // default size
}
然后是CTestApp的構造函數(shù)的調用。
在CTestApp的聲明中，它重寫了InitInstance函數(shù)，如下：
BOOL CTestApp::InitInstance()
{
AfxEnableControlContainer(); //Call this function in your application object's InitInstance function
//to enable support for containment of ActiveX controls
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
// In MFC 5.0, Enable3dControls and Enable3dControlsStatic are obsolete because their functionality is incorporated
// into Microsoft's 32-bit and 64-bit operating systems.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
// Change the registry key under which our settings are stored.
// TODO: You should modify this string to be something appropriate
// such as the name of your company or organization.
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
LoadStdProfileSettings(); // Load standard INI file options (including MRU)
// Register the application's document templates. Document templates
// serve as the connection between documents, frame windows and views.
CSingleDocTemplate* pDocTemplate; // 單文檔程序的模板生成
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTestDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CTestView));
AddDocTemplate(pDocTemplate);
// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo; // 對命令查詢分析
ParseCommandLine(cmdInfo);
// Dispatch commands specified on the command line
if (!ProcessShellCommand(cmdInfo))
return FALSE;
// The one and only window has been initialized, so show and update it.
m_pMainWnd->ShowWindow(SW_SHOW); //顯示和更新窗口
m_pMainWnd->UpdateWindow();
return TRUE;
}
有了WinMain函數(shù)，也找到了顯示和更新窗口的語句，但是從哪里開始設計窗口，注冊窗口，建立窗口呢？
我又搜索了WNDCLASS，在wincore.cpp的4495行發(fā)現(xiàn)了與設計窗口時很像的函數(shù)BOOL AFXAPI AfxEndDeferRegisterClass(LONG fToRegister)
發(fā)現(xiàn)MS已經在里面為我注冊了一些窗口，我只要選擇自己想要的樣式就可以了。
那么如何建立一個窗口呢？我又搜索了CreateWindow，在wincore.cpp的675行中有個BOOL CWnd::CreateEx函數(shù)。
里面有調用CreateWindowEx。這個函數(shù)還調用了一個叫PreCreateWindow的函數(shù)，這個函數(shù)主要是確定在建立窗口之前，確保要建立的窗口已經注冊了。
好了，一切都準備好了。最后就是進入消息循環(huán)。
2009年3月2日
轉自CSDN
在所有的預處理指令中，#Pragma 指令可能是最復雜的了，它的作用是設定編譯器的狀態(tài)或者是指示編譯器完成一些特定的動作。#pragma指令對每個編譯器給出了一個方法,在保持與C和C++語言完全兼容的情況下,給出主機或操作系統(tǒng)專有的特征。依據(jù)定義,編譯指示是機器或操作系統(tǒng)專有的,且對于每個編譯器都是不同的。
其格式一般為: #Pragma Para
其中Para 為參數(shù)，下面來看一些常用的參數(shù)。
(1)message 參數(shù)。 Message 參數(shù)是我最喜歡的一個參數(shù)，它能夠在編譯信息輸出窗
口中輸出相應的信息，這對于源代碼信息的控制是非常重要的。其使用方法為：
#Pragma message(“消息文本”)
當編譯器遇到這條指令時就在編譯輸出窗口中將消息文本打印出來。
當我們在程序中定義了許多宏來控制源代碼版本的時候，我們自己有可能都會忘記有沒有正確的設置這些宏，此時我們可以用這條指令在編譯的時候就進行檢查。假設我們希望判斷自己有沒有在源代碼的什么地方定義了_X86這個宏可以用下面的方法
#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
當我們定義了_X86這個宏以后，應用程序在編譯時就會在編譯輸出窗口里顯示“_
X86 macro activated!”。我們就不會因為不記得自己定義的一些特定的宏而抓耳撓腮了
。
(2)另一個使用得比較多的pragma參數(shù)是code_seg。格式如：
#pragma code_seg( ["section-name"[,"section-class"] ] )
它能夠設置程序中函數(shù)代碼存放的代碼段，當我們開發(fā)驅動程序的時候就會使用到它。
(3)#pragma once (比較常用）
只要在頭文件的最開始加入這條指令就能夠保證頭文件被編譯一次，這條指令實際上在VC6中就已經有了，但是考慮到兼容性并沒有太多的使用它。
(4)#pragma hdrstop表示預編譯頭文件到此為止，后面的頭文件不進行預編譯。BCB可以預編譯頭文件以加快鏈接的速度，但如果所有頭文件都進行預編譯又可能占太多磁盤空間，所以使用這個選項排除一些頭文件。
有時單元之間有依賴關系，比如單元A依賴單元B，所以單元B要先于單元A編譯。你可以用#pragma startup指定編譯優(yōu)先級，如果使用了#pragma package(smart_init) ，BCB就會根據(jù)優(yōu)先級的大小先后編譯。
(5)#pragma resource "*.dfm"表示把*.dfm文件中的資源加入工程。*.dfm中包括窗體
外觀的定義。
(6)#pragma warning( disable : 4507 34; once : 4385; error : 164 )
等價于：
#pragma warning(disable:4507 34) // 不顯示4507和34號警告信息
#pragma warning(once:4385) // 4385號警告信息僅報告一次
#pragma warning(error:164) // 把164號警告信息作為一個錯誤。
同時這個pragma warning 也支持如下格式：
#pragma warning( push [ ,n ] )
#pragma warning( pop )
這里n代表一個警告等級(1---4)。
#pragma warning( push )保存所有警告信息的現(xiàn)有的警告狀態(tài)。
#pragma warning( push, n)保存所有警告信息的現(xiàn)有的警告狀態(tài)，并且把全局警告
等級設定為n。
#pragma warning( pop )向棧中彈出最后一個警告信息，在入棧和出棧之間所作的
一切改動取消。例如：
#pragma warning( push )
#pragma warning( disable : 4705 )
#pragma warning( disable : 4706 )
#pragma warning( disable : 4707 )
//.......
#pragma warning( pop )
在這段代碼的最后，重新保存所有的警告信息(包括4705，4706和4707)。
（7）pragma comment(...)
該指令將一個注釋記錄放入一個對象文件或可執(zhí)行文件中。
常用的lib關鍵字，可以幫我們連入一個庫文件。
2009年2月3日
關于23種設計模式的有趣見解
創(chuàng)建型模式
1、FACTORY—追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產雞翅的Factory
工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何創(chuàng)建及如何向客戶端提供。
2、BUILDER—MM最愛聽的就是“我愛你”這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出“我愛你”這句話了，國外的MM也可以輕松搞掂，這就是我的“我愛你”builder。（這一定比美軍在伊拉克用的翻譯機好賣）
建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品對象。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節(jié)。建造模式可以強制實行一種分步驟進行的建造過程。
3、FACTORY METHOD—請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般采用Factory Method模式，帶著MM到服務員那兒，說“要一個漢堡”，具體要什么樣的漢堡呢，讓MM直接跟服務員說就行了。
工廠方法模式：核心工廠類不再負責所有產品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現(xiàn)的接口，而不接觸哪一個產品類應當被實例化這種細節(jié)。
4、PROTOTYPE—跟MM用QQ聊天，一定要說些深情的話語了，我搜集了好多肉麻的情話，需要時只要copy出來放到QQ里面就行了，這就是我的情話prototype了。（100塊錢一份，你要不要）
原始模型模式：通過給出一個原型對象來指明所要創(chuàng)建的對象的類型，然后用復制這個原型對象的方法創(chuàng)建出更多同類型的對象。原始模型模式允許動態(tài)的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用于任何的等級結構。缺點是每一個類都必須配備一個克隆方法。
5、SINGLETON—俺有6個漂亮的老婆，她們的老公都是我，我就是我們家里的老公Sigleton，她們只要說道“老公”，都是指的同一個人，那就是我(剛才做了個夢啦，哪有這么好的事)
單例模式：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例單例模式。單例模式只應在有真正的“單一實例”的需求時才可使用。
結構型模式
6、ADAPTER—在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助于我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)
適配器（變壓器）模式：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據(jù)參數(shù)返還一個合適的實例給客戶端。
7、BRIDGE—早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的發(fā)型，要說你的頭發(fā)好漂亮哦。不要問我“早上碰到MM新做了個發(fā)型怎么說”這種問題，自己用BRIDGE組合一下不就行了
橋梁模式：將抽象化與實現(xiàn)化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯(lián)變成弱關聯(lián)，也就是指在一個軟件系統(tǒng)的抽象化和實現(xiàn)化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。
8、COMPOSITE—Mary今天過生日。“我過生日，你要送我一件禮物。”“嗯，好吧，去商店，你自己挑。”“這件T恤挺漂亮，買，這條裙子好看，買，這個包也不錯，買。”“喂，買了三件了呀，我只答應送一件禮物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。”“……”，MM都會用Composite模式了，你會了沒有？
合成模式：合成模式將對象組織到樹結構中，可以用來描述整體與部分的關系。合成模式就是一個處理對象的樹結構的模式。合成模式把部分與整體的關系用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。
9、DECORATOR—Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面寫上“最好的的禮物，就是愛你的Fita”，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，我們都是Decorator，最終都在修飾我這個人呀，怎么樣，看懂了嗎？
裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態(tài)給一個對象增加功能，這些功能可以再動態(tài)的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。
10、FACADE—我有一個專業(yè)的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業(yè)，但MM可不懂這些，教了半天也不會。幸好相機有Facade設計模式，把相機調整到自動檔，只要對準目標按快門就行了，一切由相機自動調整，這樣MM也可以用這個相機給我拍張照片了。
門面模式：外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的門面對象進行。門面模式提供一個高層次的接口，使得子系統(tǒng)更易于使用。每一個子系統(tǒng)只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統(tǒng)可以有多個門面類。
11、FLYWEIGHT—每天跟MM發(fā)短信，手指都累死了，最近買了個新手機，可以把一些常用的句子存在手機里，要用的時候，直接拿出來，在前面加上MM的名字就可以發(fā)送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特征，根據(jù)上下文情況使用。
享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是區(qū)分內蘊狀態(tài)和外蘊狀態(tài)。內蘊狀態(tài)存儲在享元內部，不會隨環(huán)境的改變而有所不同。外蘊狀態(tài)是隨環(huán)境的改變而改變的。外蘊狀態(tài)不能影響內蘊狀態(tài)，它們是相互獨立的。將可以共享的狀態(tài)和不可以共享的狀態(tài)從常規(guī)類中區(qū)分開來，將不可以共享的狀態(tài)從類里剔除出去?？蛻舳瞬豢梢灾苯觿?chuàng)建被共享的對象，而應當使用一個工廠對象負責創(chuàng)建被共享的對象。享元模式大幅度的降低內存中對象的數(shù)量。
12、PROXY—跟MM在網上聊天，一開頭總是“hi,你好”,“你從哪兒來呀？”“你多大了？”“身高多少呀？”這些話，真煩人，寫個程序做為我的Proxy吧，凡是接收到這些話都設置好了自動的回答，接收到其他的話時再通知我回答，怎么樣，酷吧。
代理模式：代理模式給某一個對象提供一個代理對象，并由代理對象控制對源對象的引用。代理就是一個人或一個機構代表另一個人或者一個機構采取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創(chuàng)建被代理對象，被代理對象必須有系統(tǒng)的其他角色代為創(chuàng)建并傳入。
行為模式
13、CHAIN OF RESPONSIBLEITY—晚上去上英語課，為了好開溜坐到了最后一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上“Hi,可以做我的女朋友嗎？如果不愿意請向前傳”，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽說是個老處女呀，快跑!
責任鏈模式：在責任鏈模式中，很多對象由每一個對象對其下家的引用而接
起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求?？蛻舨⒉恢梨溕系哪囊粋€對象最終處理這個請求，系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。
14、COMMAND—俺有一個MM家里管得特別嚴，沒法見面，只好借助于她弟弟在我們倆之間傳送信息，她對我有什么指示，就寫一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過來一個COMMAND，為了感謝他，我請他吃了碗雜醬面，哪知道他說：“我同時給我姐姐三個男朋友送COMMAND，就數(shù)你最小氣，才請我吃面。”，:-(
命令模式：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發(fā)出命令的責任和執(zhí)行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發(fā)送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執(zhí)行，何時被執(zhí)行以及是怎么被執(zhí)行的。系統(tǒng)支持命令的撤消。
15、INTERPRETER—俺有一個《泡MM真經》，上面有各種泡MM的攻略，比如說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要做一個Interpreter，照著上面的腳本執(zhí)行就可以了。
解釋器模式：給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器?？蛻舳丝梢允褂眠@個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規(guī)則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。
16、ITERATOR—我愛上了Mary，不顧一切的向她求婚。
Mary：“想要我跟你結婚，得答應我的條件”
我：“什么條件我都答應，你說吧”
Mary：“我看上了那個一克拉的鉆石”
我：“我買，我買，還有嗎？”
Mary：“我看上了湖邊的那棟別墅”
我：“我買，我買，還有嗎？”
Mary：“你的小弟弟必須要有50cm長”
我腦袋嗡的一聲，坐在椅子上，一咬牙：“我剪，我剪，還有嗎？”
……
迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態(tài)可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。
17、MEDIATOR—四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸虧當時我在旁邊，按照各自的籌碼數(shù)算錢，賺了錢的從我這里拿，賠了錢的也付給我，一切就OK啦，俺得到了四個MM的電話。
調停者模式：調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發(fā)生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協(xié)作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。
18、MEMENTO—同時跟幾個MM聊天時，一定要記清楚剛才跟MM說了些什么話，不然MM發(fā)現(xiàn)了會不高興的哦，幸虧我有個備忘錄，剛才與哪個MM說了什么話我都拷貝一份放到備忘錄里面保存，這樣可以隨時察看以前的記錄啦。
備忘錄模式：備忘錄對象是一個用來存儲另外一個對象內部狀態(tài)的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態(tài)捉住，并外部化，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態(tài)。
19、OBSERVER—想知道咱們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責搜集情報，他發(fā)現(xiàn)的新情報不用一個一個通知我們，直接發(fā)布給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦
觀察者模式：觀察者模式定義了一種一隊多的依賴關系，讓多個觀察者對象同時監(jiān)聽某一個主題對象。這個主題對象在狀態(tài)上發(fā)生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。
20、STATE—跟MM交往時，一定要注意她的狀態(tài)哦，在不同的狀態(tài)時她的行為會有不同，比如你約她今天晚上去看電影，對你沒興趣的MM就會說“有事情啦”，對你不討厭但還沒喜歡上的MM就會說“好啊，不過可以帶上我同事么？”，已經喜歡上你的MM就會說“幾點鐘？看完電影再去泡吧怎么樣？”，當然你看電影過程中表現(xiàn)良好的話，也可以把MM的狀態(tài)從不討厭不喜歡變成喜歡哦。
狀態(tài)模式：狀態(tài)模式允許一個對象在其內部狀態(tài)改變的時候改變行為。這個對象看上去象是改變了它的類一樣。狀態(tài)模式把所研究的對象的行為包裝在不同的狀態(tài)對象里，每一個狀態(tài)對象都屬于一個抽象狀態(tài)類的一個子類。狀態(tài)模式的意圖是讓一個對象在其內部狀態(tài)改變的時候，其行為也隨之改變。狀態(tài)模式需要對每一個系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個狀態(tài)類的子類。當系統(tǒng)的狀態(tài)變化時，系統(tǒng)便改變所選的子類。
21、STRATEGY—跟不同類型的MM約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，單目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。
策略模式：策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。策略模式把行為和環(huán)境分開。環(huán)境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環(huán)境獨立開來，算法的增減，修改都不會影響到環(huán)境和客戶端。
22、TEMPLATE METHOD——看過《如何說服女生上床》這部經典文章嗎？女生從認識到上床的不變的步驟分為巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八大步驟(Template method)，但每個步驟針對不同的情況，都有不一樣的做法，這就要看你隨機應變啦(具體實現(xiàn))；
模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現(xiàn)，然后聲明一些抽象方法來迫使子類實現(xiàn)剩余的邏輯。不同的子類可以以不同的方式實現(xiàn)這些抽象方法，從而對剩余的邏輯有不同的實現(xiàn)。先制定一個頂級邏輯框架，而將邏輯的細節(jié)留給具體的子類去實現(xiàn)。
23、VISITOR—情人節(jié)到了，要給每個MM送一束鮮花和一張卡片，可是每個MM送的花都要針對她個人的特點，每張卡片也要根據(jù)個人的特點來挑，我一個人哪搞得清楚，還是找花店老板和禮品店老板做一下Visitor，讓花店老板根據(jù)MM的特點選一束花，讓禮品店老板也根據(jù)每個人特點選一張卡，這樣就輕松多了；
訪問者模式：訪問者模式的目的是封裝一些施加于某種數(shù)據(jù)結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數(shù)據(jù)結構可以保持不變。訪問者模式適用于數(shù)據(jù)結構相對未定的系統(tǒng)，它把數(shù)據(jù)結構和作用于結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者對象中，而不是分散到一個個的節(jié)點類中。當使用訪問者模式時，要將盡可能多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類。
=====================================================================
另一種解釋
==創(chuàng)建型模式==
1、 =SIMPLE FACTORY=
打完籃球真累，正好邊上有個小攤。
“來杯可樂。”
“我要芬達。”
“一瓶礦泉水。”
工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。有了小攤這個工廠，我們口渴的問題就很easy的解決了。
2、 =FACTORY METHOD=
以前每次下午打完籃球后一般很晚，回來再洗個澡，食堂就關門了。我們就集體跑過西三門外吃牛肉面（呵呵，人生之一大爽事啊），每個餐廳的風味還不一樣，這無所謂啦，我們只要說一句“來碗牛肉面“就行了。
工廠方法模式：核心工廠類不再負責所有產品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現(xiàn)的接口，而不接觸哪一個產品類應當被實例化這種細節(jié)。每一個餐廳就是一個具體的工廠，可惜現(xiàn)在西三門已經關掉了，郁悶ing！
3、 =SINGLETON=
Kobe就是Kobe，不管你是從電視上看到，還是從報紙上看到，其實就是他一個人
單例模式：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例單例模式。組織后衛(wèi)可以有幾個，但Kobe只能有一個，廢話！
4、 =BUILDER=
NBA中強隊頗多，且各有自己的特點，因此對付不同的隊有不同的打法，但你只要說“今天打國王”就行了，具體該怎么打由教練去安排（build）就行了。
建造模式：將產品的內部表象和客戶端分來，客戶不必知道產品內部組成的細節(jié)，因此當產品的表象一般很復雜時才用。戰(zhàn)術安排的確是個比較專業(yè)的任務，所以…。
5、 =PROTOTYPE=
今年全明星賽真不錯，真想再看一遍。
“小陳，把serv-u開一下，我下你的全明星賽。”
“OK！不過先上傳兩部好片。”
“啊，我暈~~!”
原始模型模式：實際上就是復制啦。原始模型模式允許動態(tài)的增加或減少產品類，產品類適合于任何的等級結構。缺點是每一個類都必須配備一個克隆方法。還好，Windows里面的東東只要點右鍵，都有個復制選項。
==結構型模式==
6、 =ADAPTER=
姚明剛去火箭時，交流有點不便，但通過經紀人Adapter，姚明很快就和火箭的其他人混熟了。
適配器模式：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。通過經紀人Adapter，主教練就可以把姚明看作本土人（會說e文的人）。如今姚明已經加強了功能，使得不要經紀人也可以和主教練交流，呵呵，str man！
7、 =COMPOSITE=
上半場被灌了個50：25，趁中場暫停，大家一起來安排下半場怎么打：
“方案A：6號太準，要專人盯防。”―“就是就是！”
“方案B：左邊防守太弱，把XX換上來。”－“好耶好耶！”
“方案C：進攻太差，多打一些擋差。”－“不錯不錯！”
“方案D：上半場方案X其實還是不錯的，下半場go on。”－“OKOK！“
…
一聲哨響，下半場開始，我們把方案A，B，C…結合，定為方案Y。＠＃￥%＾＆＊（！~等一系列后，我們終于以51:50戰(zhàn)勝對手，哈哈…??！白日夢＃＆＠＊！
合成模式：合成模式使得客戶端把單獨的成分對象和由他們復合而成的合成對象同等看待，因此合成模式使得客戶端增加新的構件變得容易。方案A是一條簡單的方案，方案D是由不同的方案結合而成的復雜方案，但我們不管這些，我們只知道它們都是我們所要的方案。
8、 =DECORATOR=
記得西邊操場沒修好時，我們踢球沒有地盤，還好，有個籃球場是空的，我們便撿來幾塊磚頭，擺上兩個門，哈哈，這樣，籃球場也就變成小足球場了。
系里舉辦一個舞會，得找塊大點的地盤，我們又看中了籃球場，掛起一盞燈，搬來兩個音箱，ok，一切搞定。這樣，籃球場便變成了舞會廳了，哈哈。
裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。其實，籃球場還可以變成很多其它的東東，只要發(fā)揮你的想像，嘻嘻。
9、 =PROXY=
玩NBA正happying。
突然，小付跑過來說：“你的電話，X系說明天下午兩點要跟俺們系干一場，怎么樣？”
－“OK，就跟他們說沒問題！”玩Games要緊。
小付作為一個代理倒省了俺不少事，呵呵。
代理模式：代理就是一個人或一個機構代表另一個人或者一個機構采取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創(chuàng)建被代理對象，被代理對象必須有系統(tǒng)的其他角色代為創(chuàng)建并傳入。X系只知道我們同意和他們干一場，但并不知道是回答他們的就是小付。
10、 =FLYWEIGHT=
上次說到吃牛肉面，我們當中有幾個還特挑剔。這不：
“老板，我要麻辣的。”－“好咧！”唰唰，老板放了些辣醬。
“我要川味的。”－“好咧！”唰唰，老板放了些泡菜。
“我也要川味的。”－老板按剛才的樣式又做了一遍。
小陳一看大家都要，不服，就說：“老板，俺要黑的。”
“黑的？黑的是什么樣的。”老板納悶了。
“黑的，黑的就是多放些醬油…”－全場狂暈＃＆＊%
享元模式：享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是其狀態(tài)存儲在享元內部，不會隨環(huán)境的改變而有所不同。將可以共享的狀態(tài)和不可以共享的狀態(tài)從常規(guī)類中區(qū)分開來，把不可以共享的狀態(tài)從類里剔除出去?？蛻舳藦墓S中獲得對象時，工廠會先檢查其是否有該對象，如果有則直接返回給客戶，沒有才創(chuàng)建新的實例。享元模式大幅度的降低內存中對象的數(shù)量。那些麻辣啦，川味啦，都是享元，要的牛肉面有很多，但口味卻就那么幾種。后來，我們打玩籃球又去了那家店，還沒等過小陳開口，老板就說：“這位同學，你是要黑牛肉面吧。”－小陳“……”
11、=FACADE=
又要和X系開始一季一度的比賽了，具體時間和地點還得靠俺這個隊長來搞定，好，no problem！給X系籃球隊隊長一個call：“星期六下午3：00，我們一見高下。”
門面模式：門面模式提供一個高層次的接口，使得子系統(tǒng)更易于使用，它將客戶端和一些子系統(tǒng)分離，提高子系統(tǒng)的獨立性和可移植性。X系籃球隊隊長就是個Facade，通過他，免得我要去跟他們系隊員（子系統(tǒng)）一個個去通知。
12、=BRIDGE=
我是個學生，但在籃球隊里，我又是個隊員，那你說我是什么，超級賽亞人？呵呵。
橋梁模式：將抽象化與實現(xiàn)化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯(lián)變成弱關聯(lián)，也就是指在一個軟件系統(tǒng)的抽象化和實現(xiàn)化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。哈哈，多虧這個模式，不然我還真不知道該怎么稱呼我自己呢，嘻嘻。
==行為模式==
13、=STRATEGY=
足球里有很多戰(zhàn)術，比如，一般情況用442，打強隊可以用451，打弱隊可以用343。
當然籃球里面也有的，比如，你可以選擇打中鋒，或者遠投，當然我們平時最多用的可能就是獨干，哈哈。
策略模式：策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。策略模式把行為和環(huán)境分開。環(huán)境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環(huán)境獨立開來，算法的增減，修改都不會影響到環(huán)境和客戶端。
14、=TEMPLATE METHOD=
不同的籃球班有不同的老師，但他們上課的內容都是一樣的，一般都分為運球，傳球，投籃，上籃這么幾堂課，估計體育師范學院教書的模版就是這樣。具體運球怎么教，上籃怎么教就依不同的老師自己了。
模板方法模式：模板方法模準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現(xiàn)，然后聲明一些抽象方法來迫使子類實現(xiàn)剩余的邏輯。不同的子類可以以不同的方式實現(xiàn)這些抽象方法，從而對剩余的邏輯有不同的實現(xiàn)。先制定一個頂級邏輯框架，而將邏輯的細節(jié)留給具體的子類去實現(xiàn)。
15、=OBSERVER=
“今天下午去打籃球啊。”－A
“好啊，到時叫上我。” －B
“也叫上我。” －C
“還有我。”－D
…
我們班的號召力可見一斑，呵呵。
觀察者模式：觀察者模式使觀察者和被觀察者之間的耦合抽象化，被觀察者會向所有的登記過的觀察者發(fā)出通知。當A要去打籃球時，便會通知B，C，D…
16、=ITERATOR=
大一時上籃球課，體育老師要清名單：“小王（體育委員），你們班到了多少人？”
小王：“立正－－，報數(shù)。”
“1，2，3，4，…”
迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態(tài)可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。小王真聰明，不必查詢任何一個人就知道到了多少人。
17、=CHAIN OF RESPONSIBLEITY=
現(xiàn)在湖人隊進攻，佩頓將球交給馬龍，馬龍再傳給奧尼爾，奧尼爾一記重扣，湖人再添2分。
責任鏈模式：在責任鏈模式中，很多對象由每一個對象對其下家的引用連接起來而形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶并不知道鏈上的哪一個對象最終處理這個請求，系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。其實剛才那個球，奧尼爾可以再傳給科比來個空中接力大風車灌籃的，那就PERFECT了！
18、=COMMAND=
一場關鍵比賽最后一秒由俺的三分決定了勝負，不過，可累壞了俺。
“來杯水。”真聽話，我同學A馬上叫一靚MM給我倒了杯水。
“背好酸。”真聽話，我同學A馬上又叫那個靚MM給我錘背。
“真想洗個澡。”真聽話…“等等，我不是那個意思，哇哇…＾￥＆＃＊。”
命令模式：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發(fā)出命令的責任和執(zhí)行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發(fā)送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執(zhí)行，何時被執(zhí)行以及是怎么被執(zhí)行的。如果早知道那個命令怎么執(zhí)行，俺就不會說那句話了，嗚嗚…
19、=MEMENTO=
下了一個NBA小游戲，里面可以自動調關，但要改注冊表，當然，先找到鍵值“總決賽”，右鍵，導出為final.reg，剩下來你就可以隨便改了，萬一改錯了，還可以雙擊final.reg，呵呵。
備忘錄模式：備忘錄對象是一個用來存儲另外一個對象內部狀態(tài)的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態(tài)捉住，并與該對象分離，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態(tài)。
20、STATE
今天打球真沒勁，投籃老委掉。
忽然，一靚MM走過來… ?。?，超級賽亞人第三階，變身！
變身之后果然不同凡響，輕松幌過兩個人，在三個人的夾擊下出手命中，同時加罰?。ê呛?，就會吹）
狀態(tài)模式：狀態(tài)模式允許一個對象在其內部狀態(tài)改變的時候改變行為。這個對象看上去像是改變了它的類一樣。狀態(tài)模式需要對每一個系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個狀態(tài)類的子類。當系統(tǒng)的狀態(tài)變化時，系統(tǒng)實際改變所選的子類。當一個對象行為依賴其所處狀態(tài)時，就可以考慮用該模式。靚MM沒來時，狀態(tài)差，導致投籃委。靚MM一來，狀態(tài)奇佳，就是打手也能進，哈哈。
21、=VISITOR=
下學期籃球課換了個老師，當然，他對我們全然不熟，于是第一節(jié)課他拿著花名冊找到體育委員小王：“小陳技術怎樣？”－“一般般，”
“小羅呢？”－“還可以，不過上籃不行。”
“小何呢？”－“他啊…”
等等，俺趕緊咳嗽一聲。
“他怎么樣？”－“他，他不錯不錯！” 哈哈。
“就是投籃老委!”－啊，你這小樣，耍我。
訪問者模式：訪問者模式的目的是封裝一些施加于某種數(shù)據(jù)結構元素之上的操作，使得增加新的操作很容易，一旦這些操作需要修改的話，接受這個操作的數(shù)據(jù)結構可以保持不變，比如，老師還可以通過小王得到我們每個人的身高等。訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類（比迭代子強），但增加一個新的節(jié)點就變得很困難，如果我們班來了個新同學，小王就沒那么管用了。
22、=INTERPRETER=
想知道怎么玩出酷呆了的假動作么，我這兒有AND1的經典集錦，按照上面練習就行了。
解釋器模式：給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器?？蛻舳丝梢允褂眠@個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規(guī)則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。
23、=MEDIATOR=
俺一高中同學小D到我這兒來玩，當然，打球是必不可少的。叫上小王就出去K別人，但小D和小王不熟，所以幾乎沒什么配合，結果被CAI了個5：0。只好下場“休息”。
小王：“叫你那個同學少單干，多傳球。”－“OK。”我過去把意見傳給了小D。
小D：“你那個同學防守有問題，要盯人，不要盯球。”－“NO PROBLEM。”我又過去把意見傳給了小王。
調停者模式：調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發(fā)生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協(xié)作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。
果然，依靠我這個MEDIATOR，我們馬上還了對方一個雞蛋。哈哈！
2009年1月25日
（1）找到理想的工作
（2）每天能看1小時的書
（3）下年這時候能給爸媽孝順錢過年