摘要: Builder模式仍然屬于創建型模式，主要體現了OO中“封裝”和“多態”兩個特性。還是引一個簡單的例子來說明Builder模式的意義。假設我們設計的游戲中需要創建一個比較復雜的房屋對象，房屋對象有很多部分組成，比如說有門，窗戶，墻，地板等等。當我們在將這個房屋實現之后，可能隨著需求的改變需要對門進行更換，將原來的木門換成鐵門。這時候的問題就是：如何改...
閱讀全文
摘要: FactoryMethod模式屬于23種設計模式中的創建型模式，解決的是如何“new”的問題。引例：還是先從簡單的例子入手FactoryMethod模式吧，現在需要一個汽車測試的環境來對汽車進行測試，我們很容易會這樣設計
1/**/////////////////////////////////////////////// 2//汽車類 3...
閱讀全文
摘要: 設計模式的目的就是盡量減少“變化”對程序的影響，尤其是對客戶程序的影響。AbstractFactory模式作為創建型模式的一種，解決的就是“new”在變化中可能引起的問題。先來看看new有何種不好，舉個創建汽車的車門的例子：很自然的一種想法是：Door *door = new Door();但是如果遇到創建老爺車的車門，創建現代車的車門，這段代碼就無...
閱讀全文
摘要: Strategy模式是設計模式中非常常用的一種設計模式，甚至在你沒有學習過設計模式之前就已經使用過這種模式。先看個簡單的例子吧：比如說你要寫個List的容器，需要有一個Sort方法。但是對于容器中不同類型的對象Sort方法可能會不一樣，比如說Point類型可能根據point到原點的距離或者point的xy之和來比較大小。一種很自然的想法就是：
1void sort()2{3 ...
閱讀全文
摘要: 引例：銀行現在的業務大多有提醒業務，比如我們用信用卡消費的時候銀行會有短信通知和Email通知等方法立即提醒客戶賬戶發生了變化。這就是典型的Observer模式，A（賬戶）發生變化之后通知B（手機）和C（Email），以后也許還會通知D（電話）等等。。。程序設計中也會遇到很多這樣的問題，比如說MFC中的Document/View架構，Document中的數據變化會立即通知View的顯示也相應變化，...
閱讀全文
上C++課程的時候老師總是鼓吹模板如何重要，但是真正上課時候卻將該部分跳過。平時做項目寫程序雖然天天接觸STL，但說到如何實現模板真的是道不出其一二。現將這幾天看C++Primer中的一些重要概念提取出來，以備不時之需。
1，模板的用處。
模板其實也是多態思想的一種體現，不過不是C++那個運行時多態，而是編譯時多態。那么用在什么地方呢？個人感覺用的最多的是在數據結構中，一些經典的數據結構（Queue，Stack）用模板類實現確實事半功倍。至于其他地方嘛。。。也許是自己的功力不夠，幾乎就沒有用過（設計模式不也是一樣的道理嘛，囧）
2，模板定義
模板函數定義：
template<typename T>
int compare(const T &v1,const T &v2);
內聯函數：
inline template<typename T> int compare(const T &v1,const T &v2);
模板類定義：
template<class Type> class Queue
{
public:
Queue();
Type T& front();
//......
}
3，模板類實例化
Queue<int> qi;
其實這個不就是和STL一模一樣嘛？確實是的，STL不就是幫我們這些經典的數據結構一一實現了嘛？
4,友元的在模板類的使用
friend class Queue<Type>;
這樣就將Queue這個模板類設為了友元，之前必須要有Queue<Type>的聲明，如template<class Type> class Queue;
5,static在模板類中
一個模板類會有多個static實例成員，但每種類型的模板類只有一個static成員！
比如說Queue<int>有一個static成員，Queue<string>也有一個static成員
討論：
如果你討厭鏈接錯誤，那么你一定覺得模板這個東西是讓人討厭的，起碼編譯器是很討厭模板的，要知道在實例化時才會確定模板中T的類型，再根據他生成相應的代碼是件很麻煩的事情，模板類在這個問題上顯得尤其麻煩。
一般寫類都是將定義和聲明放在兩個文件中的，這樣清晰明了，但是在模板類中絕對不可以！編譯器會找不到你定義的那些方法！
所以說，寫模板類的話就請寫在一個文件中吧，MS到現在還把export留作未來使用的關鍵字在，我們暫時就不要指望這個了吧！
看模板類的時候發現有些地方使用到了友元，上課學的記不得了，趕緊溫習下。。。
友元概念就不羅嗦了，使用也簡單，就兩種形式：
1.友元函數：friend ret-type classname::funname(....);
2.友元類：friend class classname;
唯一要注意的就是不管是友元函數還是友元類，定義友元關系前必須先聲明
友元類其實還是有些故事要說的，一旦類繼承起來友元關系還是有些小復雜的，下面簡單說明：
C中聲明A是其友元類，那么最基本的就是A可以使用C中的private方法或者對象。
圖中可見，A是B的基類，C是D的基類。ABCD中就有如下關系：
1.B新增的方法不能訪問Ｃ的私有成員
2.B從Ａ繼承而來的方法可以訪問Ｃ的私有成員
3.A只能訪問D中從C中繼承而來的私有成員，D中新增的私有成員不能訪問！
總結起來就是友元關系不可以繼承，但對已有的方法來說訪問權限不改變。如果改寫基類的方法則訪問權限改變
PS ： 要特別謝謝有朋友留言糾正了我的錯誤，這次將測試用代碼一并貼出
class C
{
friend class A;
private :
int numC;
};
class D : public C
{
private:
int numD;
};
class A
{
public:
//A是Ｃ的友元，可以訪問Ｃ的私有成員
void getFromC()
{
C c;
c.numC = 100;
cout<<"getFromC in A : numC = "<<c.numC<<endl;
};
//Ａ不是Ｄ的友元，不能訪問Ｄ中新增的私有成員，但可以訪問Ｄ從Ｃ中繼承而來的私有成員
void getFromD()
{
D d;
d.numC = 23;
cout<<"getFromD in A : numC = "<<d.numC<<endl;
//d.numD = 24;
//cout<<"getFromD in A : numD = "<<d.numD<<endl;
}
};
class B :public A
{
public:
//友元關系不能繼承，新增的方法不能訪問Ｃ的私有成員
// int getNumB()
// {
// C c;
// c.numC = 100;
// return c.numC;
// }
//改寫方法后對Ｃ訪問權限改變，不能訪問Ｃ的私有成員
// void getFromC()
// {
// C c;
// c.numC = 100;
// cout<<"getFromC in B : numC = "<<c.numC<<endl;
// }
};
int _tmain(int argc, _TCHAR* argv[])
{
A a;
a.getFromC();//輸出——getFromC in A : numC = 100
a.getFromD();//輸出——getFromD in A : numC = 23
B b;
b.getFromC();//輸出——getFromC in A : numC = 100
//調用的還是A::getFromC
return 0;
}
項目里的陰影實現一直沒有做，考慮到畢竟是室內的漫游項目，對陰影要求效果并不是很高，就準備用烘培試試看。況且烘培不用改代碼，模型改好后一勞永逸。
有圖有真相，看圖說話
Max里隨便加了兩盞燈，模型用的是我最喜歡的1Box+4Cylinder，可以看出地板效果還是挺好的。光線有些暗，把material文件的emissive改大些就行，懶得弄了。
接下來就把項目的文件全部baking出來吧，好大的工作量-_-|