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