發信人：bbs@neptune.cksh.tp.edu.tw
日期：Fri Oct 24 09:20:01 1997
標題：咱騞犰V(oop)基礎講議 -- 1
作者: lcr (小牛) 看板: CKCSC
標題: 物件導向(oop)基礎講議 -- 1
時間: Tue Oct 15 04:43:51 1996
C++物件導向程式語言簡明教程
<第一章 概論>
撰文:程式創作區小樹 使用編譯器:Turbo C++ 3.0
修改:lcr(小牛)
修改前言: 這篇小樹寫的 oop 概念蠻容易懂的, 蠻適合初學者看一下..
只是筆者覺得寫的有點亂亂的 (^_^), 所以小弟在這整理了一下,
並沒有修改內容....請小樹哥哥見諒啦....:p
Lcr (1996.10.13)
讀者須知:
本文章由C 開始談起, 算是一篇C++的入門參考書, 文內假設各位已經有
C 語言的基礎,是C++的初學者, 讀者至少必須對C有相當程度的熟悉, 如流程
控制(if,for,while,switch...),指標,陣列,結構(struct), 都必須非常熟悉
, 否則恐怕會有閱讀上的困難....
本文件的目的是想要讓C++更好學, 使大家都能輕易的瞭解C++的精義。
因此本文件歡迎傳閱, 若有需要也歡迎做適當的修改, 以修正錯誤或增加可
讀性. 但請勿加入不雅的言語, 而且修改者務必註明修改者名稱及修改日期,
並保留原作者之簽名. 謝謝各位!
<1> 從結構談起
首先我丟給各位一個題目, 假設各位正在設計一個遊戲, 螢幕上有十顆
子彈,各在不同的位置, 往下一齊飛去, 直到飛出螢幕為止,向這樣的程式你
會怎麼做呢? 給你五分鐘想一想.........要想喔!
想完了才可以繼續往下看喔!
Ok!想好了嗎? 讓我來公佈答案吧!
作法一: 剛學習C 或者是慣用Basic 的人也許會這麼做~~~~
┌─────────────────────────────────┐
│void show(int x,int y); //這是一個副程式,可以在(x,y)上畫出一點, │
│ //至於要怎麼寫就先不管他,反正你知道有這麼│
│ //一個函式就對了.... │
│void main() │
│{ │
│ int x[10],y[10];//這是記錄十顆子彈位置的陣列 │
│ │
│ while(1) │
│ for(int i=0;i<10;i++) │
│ { │
│ show(x[i],y[i]); //畫出每一個子彈 │
│ y[i]++; //將子彈往下移一格 │
│ } │
│} │
└─────────────────────────────────┘
這種作法可以說是一般人最常用的作法了, 對小程式也就夠了! 缺點是一
旦程式大起來了, 要處理的東西變多了, 例如螢幕上有十顆子彈, 十艘船, 十
顆隕石, 十顆背景行星或更多那程式就會變得凌亂不堪了!! (想像一下)....
光是讀懂程式是做什麼的就是一件很辛苦的事....有另外一種作法如下:
作法二: 對C比較有概念的人應該會這麼做~~~~
┌────────────────────────────────┐
│void show(int x,int y); //這是一個副程式,可以在(x,y)上畫出一點,│
│ //至於要怎麼寫就先不管他,反正你知道有 │
│ //這麼一個函式就對了...... │
│void main() │
│{ │
│ struct _Bullet //這是一個 "子彈" 的 "模子". │
│ { │
│ int x; │
│ int y; │
│ }; │
│ │
│ _Bullet Bullet[10]; //用模子做出10顆子彈. │
│ │
│ while(1) │
│ for(int i=0;i<10;i++) │
│ { │
│ show(Bullet[i].x,Bullet[i].y); //將子彈秀出來. │
│ Bullet[i].y++; //將子彈往下移一格. │
│ } │
│} │
└────────────────────────────────┘
這個程式好瞭解多了, 你可以想像 _Bullet 是子彈的 "模子", 我們用
這個模子做出了10顆名字分別為Bullet[0], Bullet[1]....的子彈, 位置是
子彈的一個"屬性"(就好像身高體重是人的屬性一樣), 程式可以由
Bullet[i].x或Bullet[i].y來取用這些屬性, 這樣子程式就好懂多了, 無論
程式寫得多大, 也可以很容易的知道某個變數到底是誰的,做什麼用的, 不會
像上一個程式一樣凌亂不堪了!
總結:
其實兩個程式最大的差別, 在於是否"擬物化"在程式一,子彈被化成一個
個的陣列,分居各處, 沒什麼關連在程式二, 子彈被程式語言模擬成一個個的
"子彈"彷彿我們操作的真是一顆顆的子彈似的. 簡單的說,第一個程式是問題
遷就程式, (硬把"子彈"拆成毫不相關的陣列)而第二個程式則是程式模擬問題
. (用struct _Bullet做出十顆"子彈")而傳統程序導向和物件導向設計的差別
之一就在此, 傳統程序導向的設計讓程式設計變得很抽象, 程式的結構與我們
所經驗到的世界大不相同, 這種結果導致程式很難被瞭解(因為違背了日常經驗
嘛!)除錯和維護起來就很困難!!
而物件導向程式設計基本上就是要將程式語言拿來模擬世界的運作!!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
這樣子設計程式其實就是在模擬世界的運行, 程式會更好了解,更容易製作,
維護起來也輕鬆多了!
<2> 物件與類別:
物件和類別是物件導向程式設計中第一個要接觸到的觀念, 讓我們來看看
什麼是物件,何謂類別:
我們在上一篇中用"子彈的模子"(struct _Bullet) 做出了10顆"子彈"
(Bullet[i])如果用比較學術性的講法, 其中"子彈的模子"就是"類別",在英
文以"Class"來表示, 那一顆顆的"子彈"就是"物件",英文是"Object".
在C++中,為了強調這種觀念,通常不用struct來做"模子", 而改用
"class"來做!! 以後我們也將只用class來做"模子"(就是類別啦!!) 基本上
兩個敘述是差不多的,但仍有一些小差別, 至於差別在哪兒,這個我們稍後再
敘.
上一個程式中的"Struct _Bullet"其實也可以寫成這樣, 效果一模一樣呢!!
class _Bullet
{
public: //多了這個敘述
int x;
int y;
};
我們可以廣義的這樣說, 若有一行敘述 :
double a,b;
我們可不可以說double 是一個倍精度浮點數的模子呢? 而是不是a,b正
是由double這個模子做出來的浮點數"物件"呢? 同樣的,所有的C 語言基本資
料型態, 例如int啦! char啦! 指標啦! 基本上都是一種"模子". 也就是一種
"類別" 而由這些模子所做出來的變數其實都是一個個的物件!
更廣義的說,其實所有的資料型態都是類別, 而所有的變數都是物件, 不
是嗎? 只要這樣想, 應該就不難瞭解類別和物件的意義吧 ?!
<3> 類別成員函數
前面所講到的程式裡,我們用"子彈模子"(即子彈類別)做出了十顆"子彈"
然後用一些敘述及show()函式去使子彈前進並畫出來, 這樣子說實話還不夠像
真實的子彈, 因為真正的子彈是"自己"飛的, 哪是由外力操縱的呢? 其實我們
可以這麼做:
┌─────────────────────────────────┐
│void main() │
│{ │
│ class _Bullet//這是一個 "子彈" 的 "模子",改用class來寫 │
│ { │
│ public: │
│ int x; │
│ int y; │
│ void show(int x,int y); //這是一個函式,可以在(x,y) │
│ //上畫出一點,內容先不管. │
│ void go() //這是一個函式,呼叫他可以讓│
│ { //子彈往下移一格並畫出來. │
│ show(x,y); │
│ y++; │
│ } │
│ int collision(int X,int Y) //這是一個函式,用來判斷子彈│
│ { //是否撞到東西, 不是則傳回0│
│ return (x==X && Y==y); │
│ } │
│ }; │
│ │
│ _Bullet Bullet[10];//用模子做出10顆子彈 │
│ │
│ while(1) │
│ for(int i=0;i<10;i++) │
│ Bullet[i].go(); //下命令給子彈,要子彈往下移│
│ //一格,並將自己畫出 │
│} │
└─────────────────────────────────┘
哇塞!太誇張了吧!! 函式區然可以放到"模子"裡面去!!!! 別懷疑,這是C++
的語法,
而且放到"模子"裡的函式還可以以 物件名.函式名(參數); 的方法呼叫喔!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
或許你會說:把函式放到class敘述中有什麼好處呢? 其實我們可以這樣想:
Bullet[i]是一顆顆的子彈, 而這個子彈是有生命的, 也就是說我們可
以下命令給他(用點想像力). 而Bullet[i].go()中的"go()" 其實就是命令
的名稱, 意思就是跟子彈說:"衝啊！衝到下一格去" 子彈接到命令後他"自
己"自然就會照作, 而有的命令是必須有附帶一些訊息的, 例如collision
是問子彈是否撞到了(X,Y)這個點, 因此點的位置必須告訴子彈, 而敘述要
寫成Bullet[i].collision(X,Y); 如果子彈發現撞到了,他會告訴你於是你
可以做一些措施,例如畫出爆炸畫面...或什麼的...
*像此類放在類別敘述內的函式稱為類別的函式成員。
~~~~~~~~
*而像int x,y 這些在類別內的物件則稱為該類別的的資料成員。
~~~~~~~~
這樣可以瞭解嗎?
<4> 私用及公用成員,資訊隱藏:
投過販賣機嗎? (廢話!!!) 販賣機其實是一個很複雜很複雜的機器, 可是
他的使用方法卻非常非常的簡單, 只要投個硬幣進去(呼叫成員函式), 按下所
要的飲料 (成員函式的參數), 飲料自然就會掉出來!! 你不必管販賣機是怎麼
做到的, 你只要會操作就可以了! 原因是販賣機把複雜的部份藏起來了, 只露
出了供人使用的部份.
同樣的道理, 我們的子彈"類別"也可以這樣, 其實我們希望不管子彈是怎
麼飛的, 只要我們叫他飛他就飛就可以了. 而且操作方法是越簡單越好, 所以
啦! 一些並不會被使用者使用到的函式, 如show()啦! 以及一些不足為外人道
的資料,如int x,y 啦! 如果能夠把他們藏起來(就像販賣機把機器部份包起來
) 只給類別自己的成員函式去使用, 而露出那些公用的操作介面, 提供給所有
的人使用, 那該有多好!
幸好C++早就想到這一點了, 提供了"private:"以及"public:"這兩個敘述
供我們使用, 請看改進後的子彈類別:
┌──────────────────────────────────┐
│class _Bullet//這是一個 "子彈" 的 "模子",改用class來寫 │
│{ │
│ private: //私用成員(販賣機的內部),除了類本類別的函式成員外 │
│ int x; //,其他人皆不得存取或呼叫之 │
│ int y; │
│ void show(int x,int y);//這是一個函式,可以在(x,y)上畫出一點, │
│ public: //公用成員(販賣機的操作方法),提供給所有的人使用 │
│ void go() //這是一個函式,呼叫他可以讓子彈往下移一格並畫出來│
│ { │
│ show(x,y); │
│ y++; │
│ } │
│ int collision(int X,int Y) //這是一個函式,用來判斷子彈是 │
│ //否撞到東西 │
│ { │
│ return (x==X && Y==y); //不是則傳回0 │
│ } │
│}; │
└──────────────────────────────────┘
"private:"是一個C++的敘述, 他告訴編譯器說:以下的東東只能在這個類別
內使用, 也就是只能給類別的函式成員使用, 因此在類別的外面絕對不能存取或
呼叫這些私有的變數或函式, 否則編譯器是會告訴你語法錯誤的!
"public:"則相反, 他告訴編譯器說:以下的東東所有的人都可以使用. 程式
可以在任何地方使用它!
這樣子一來, 子彈就像販賣機一樣, 你只要知道怎麼操作他, 而不必知道他
如何動作了, 也不怕會不小心存取到不該存取的東西, 而破壞掉子彈的運行, 因
為一旦你想要這麼做, 編譯器會阻止你的!! 像這種把沒有必要公開的資訊隱藏起
來,
在學術上叫做封裝,也稱為資訊隱藏,(要記起來喔!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
主要是為了降低程式設計師的負擔, 減少錯誤的發生. 以前物件導向的觀念
還沒流行以前, 程式師要背負的一個很大的包袱就是要牢牢的記住所有變數的名
稱及功用, (有幾千個喔!) 因為所有的變數都是隨時隨地可以存取的, 一個對變
數錯誤的存取, 就會造成整個系統難以除錯的Bug!! 而物件導向將沒有必要公開
的資料與函式封裝起來, 可以大大減少這種錯誤的發生, 況且, 資訊隱藏可以讓
類別條理分明, 容易瞭解. 將外人不需要知道的東西包裝起來, 這樣子看的人(
包括你自己喔!)可以很容易的知道在這個類別中提供了哪些運作方法, 以及這個
類別大概是做什麼的.
而不會被一大堆無用的資訊搞得一頭霧水, 浪費寶貴的時間和精力! Ok! 或
許你現在還不能很瞭解資訊隱藏的好處! 不過相信我, 當你開始寫物件導向程式
的時候, 你就會感謝C++的!!!
class 和 struct 有什麼差別呢? 我終於可以告訴你了!!!
他們差在struct的是內定為"public:"的, 而class是內定為"private:"的, 也就
是說:
void main()
{
class _Bullet
{
int x,y;
};
_Bullet Bullet;
Bullet.x=5; //這一行不合法!!!!!
};
這樣瞭解嗎?
<5> 函式複載
再出一個題目給大家, 寫一個函式,名為max 可以接收兩個整數,傳回比較
大的那一個, 一樣大就隨便傳一個, 你會怎麼寫呢?
給你兩分鐘......一定要想喔!!!
OK!想必大家都是這樣寫:
int max(int a,int b)
{
if(a>b)
return a;
else
return b;
}
很好!再出一個題目給大家: 假設上一個題目的函式已存在, 我現在想要一
個功能一樣的函式, 但是是處理倍精度浮點數的(double), 你會怎麼寫呢?
Ok!想必應該是這樣:
double maxbouble(double a,double b) //注意!函式名不同了!這是C 的規則!
{
if(a>b)
return a;
else
return b;
}
嗯...很好很好.....嘿嘿!! 如果我還要一個處理長整數,一個處理字元,一
個處理指標的呢? .............天啊！ 光是命名就讓人昏倒,而且使用起來很
不自然,不是嗎? 告訴你,其實你可以不要寫的那麼辛苦的, 上一個例子也可以寫
成這樣:
double max(double a,double b)//注意喔!名字和int max(~~)一樣喔!
{
if(a>b)
return a;
else
return b;
}
不會吧!不是不可以這樣寫嗎?" 哈哈!告訴你,這就是C++的新語法"函式複載"
或許你會問:"他怎麼知道我要用的是哪一個?" 放心吧!他知道的! 例如如果你呼叫
max(1,2); 他就會用處理整數的那一個, 如果你呼叫:max(1.3,0.005); 他就會用
處理浮點數的那一個神奇吧!
複載在學術上又稱為靜態連結, 因為到底要呼叫那個函式其實在編譯的時候
就決定了, 另外還有一種叫動態連結的, 要等到執行的時候才能決定, 這個我們
以後再說.
<6> 建構函式
一個物件在建立的時候, 有時候我們會希望能替他初始化, 例如說我們希望
在建立子彈物件時, 若沒有指定初值, 例如:_Bullet Bullet; 則子彈剛建立的時
候位置是(0,0), 若有指定初值, 例如:_Bullet Bullet(10,10); 則子彈的位置可
以設為我們要的位置, 則這樣子要怎麼做呢?
C++ 提供了建構函式(constructor), 可以讓我們在物件剛建立的時候做一些
事情, 將物件初始化, 請看下例:
┌───────────────────────────────────┐
│class _Bullet //這是一個 "子彈" 的 "模子",改用class來寫 │
│{ │
│ private: //私用成員 │
│ int x; │
│ int y; │
│ void show(int x,int y); //這是一個函式,可以在(x,y)上畫出一點, │
│ public: //公用成員 │
│ _Bullet(){x=y=0;} //無參數之建構函式 │
│ _Bullet(int X,int Y){x=X;y=Y;} //有兩個參數之建構函式 │
│ void go() //這是一個函式,呼叫他可以讓子彈 │
│ { //往下移一格並畫出來 │
│ show(x,y); │
│ y++; │
│ } │
│ int collision(int X,int Y) //這是一個函式,用來判斷子彈是否 │
│ { //撞到東西, 不是則傳回0 │
│ return (x==X && Y==y); │
│ } │
│}; │
└───────────────────────────────────┘
其中_Bullet()是一個無參數的建構函式, 當物件以 _Bullet Bullet; 的方法
建立的時候, C++會自動的呼叫此函式來作物件的初始化,而 _Bullet(int X,int Y)
則是一個有兩個整數參數的建構函式, 例如當物件以 _Bullet Bullet(2,17)來建立
的時候, C++會自動的呼叫此函式來作物件的初始化.
要注意的是建構函式的名稱必須和類別名稱一樣, 建構函式不可以有傳回值
(連寫void都不行) 結束時也最好不要用return;命令結束, 不然在某些編譯器上
會有問題. 其他的事項都和一般類別內函式相同.
<7> new 和 delete
在C 中,配置記憶體的方法最常用的就是 malloc() 和 free() 了! 當然在C++
中, 你一樣可以運用這兩個函式來配置記憶體. 但是使用這兩個函式來配置記憶體
在C++中卻有一些不妥!! 因為malloc()雖然會配置記憶體給物件用, 但是卻不會呼
叫物件的建構函式, 這樣子我們就不能再建立物件之初將其初始化了!! 幸好C++想
到了這點, 提供了兩個新的記憶體配置運算子----new 和 delete!! 他們的用法相
當簡單! 請看:
int *p=new int; //建立指標p,並配置一個int的記憶體給他.
int *q; //和上面的效果一樣,但是先宣告後配置.
q=new int;
int *r=new int[10]; //建立指標r,並配置10個int的記憶體給他.
_Bullet *s=new _Bullet[10]; //和上面一樣,只不過int換成_Bullet.
_Bullet *t=new _Bullet(1,2)[10]; //和上面一樣,但指定了初值.
delete p; //歸還p所配置的記憶體
delete q; //歸還q所配置的記憶體
delete [] r; //歸還r所配置的記憶體
delete [] s; //歸還s所配置的記憶體
delete [] t; //歸還t所配置的記憶體
值得注意的是, 使用new時, C++會自動的呼叫每一個物件的的建構函式. 例如
在t 中:
*(t).x , *(t+1).x ,....*(t+9).x 都會是 1
*(t).y , *(t+1).y ,....*(t+9).y 都會是 2
使用delete時, 若當初配置的是單一物件則不要加括號, 若當初配置的是物件
陣列的話則一定要加括號!! 不然會有問題! 切記!切記!
<8> 解構函式
有建構當然就會有解構啦!!! 有的時候我們會希望在物件被消滅的時候(例如被
delete的時候) 能夠做一些措施. 而做這種做施的函式就叫解構函式.(destructor)
, 請看下例:
class test
{
int *p;
public:
test(){p=new int;} //建構函式
};
void main()
{
test a;
}
這個類別在建立時會配置一個int的記憶體給指標p, 但是當程式結束時並沒有
將p 所指到的記憶體歸還給系統, 這樣會造成一些BUG. 解決的方法是加入解構函式
請看:
class test
{
int *p;
public:
test(){p=new int;} //建構函式
~test(){delete p;} //解構函式
};
void main()
{
test a;
}
這個新的版本中加入了解構函式, 當物件將要被毀滅時,(程式結束時,或物
件被delete掉時) C++會自動執行解構函式,以妥善的進行善後工作, 值得注意的
是解構函式名為類別名前面再加上 "~" 符號而成不可以有參數,也不可以有傳回
值, 不得複載!! 函式中不可以有return;敘述. 否則可能會有問題!!
<9> 繼承
讀過生物吧!!(又是一句廢話!!) 動物是一種生物, 靈長目又是一種動物,人
類又是一種靈長目, 李登輝是一個人類的個體. 向這種 "是一種" 的關係就叫繼
承. C++是為了模擬世界而創的, 像這種繼承的機制當然是不會放過的啦!
請看我們的例子:
生物有一些生物的特性, 生物會繁殖、會生長. 動物既然是一種生物, 當然
也一定會繁殖會生長囉! 可是動物還加了自己的一些特性:動物會動(廢話!) 靈長
目也是一種動物囉!! 所以動物該有的特性他都有囉! 可是靈長目他又多了一種自
己的特性, 就是他有IQ囉! 同樣的,人類是一種靈長目, 所以人類會繁殖,會生長,
會動,有IQ, 而且人類還多了自己的特性----人類有名字!!!
李登輝是個人類! 因此他有自己的名字:他叫李登輝, 有自己的IQ---雖然我
不知道有多少, 會動,會繁殖,也會生長!!
以上拉拉雜雜的一大堆以C++的方法來表示就是:
class life //生物類別
{
public:
void gorw(){~~~}; //命令生物"生長"的函式,內容先不管
void bear(){~~~}; //命令生物"繁殖"的函式,內容先不管
};
class animal:public life //動物類別,繼承自生物,也就是說"動物是一種生物"
{
public:
void move(){~~~}; //命令動物"移動"的函式,內容先不管
};
class primates:public animal //靈長目,繼承自動物
{
int IQ; //這是靈長目的IQ
};
class human:public primates //人類,是一種靈長目
{
char name[6]; //名字,三個中文字
public:
human(char *p){strcpy(name,p);} //設定名字的建構函式
};
void main() //程式開始
{
human LDW("李登輝"); //誕生李登輝並替他取名字(將name[]設為"李登輝")
LDW.grow(); //李登輝在"生長"(天天喝克寧,你就會長得跟"小樹"
//一樣喔!)
LDW.move(); //李登輝做"運動"(嘿休!嘿休!)
LDW.bear(); //李登輝在"繁殖"!!??%^#$%(18歲以下兒童請勿觀看)
}
這個例子只是博君一笑, 事實上繼承的用處是很大的. 他可以讓程式更擬
物化, 也可以讓程式具有重用性... 我這樣說你可能會很模糊, 沒關係,等到我
們開始實做程式的時候你自然就會瞭解了!
<第一章結束>
小樹
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
發信人：bbs@neptune.cksh.tp.edu.tw
日期：Fri Oct 24 09:20:01 1997
標題：咱騞犰V(oop)基礎講議 -- 2
作者: lcr (小牛) 看板: CKCSC
標題: 物件導向(oop)基礎講議 -- 2
時間: Tue Oct 15 04:46:12 1996
C++物件導向程式語言簡明教程之二
<第二章 概論 II >
撰文:程式創作區 小樹 使用編譯器:Turbo C++ 3.0
修改:lcr(小牛)
修改前言: 這篇小樹寫的 oop 概念蠻容易懂的, 蠻適合初學者看一下..
只是筆者覺得寫的有點亂亂的 (^_^), 所以小弟在這整理了一下,
並沒有修改內容....請小樹哥哥見諒啦....:p
Lcr (1996.10.13)
讀者須知:
本文章由C 開始談起, 算是一篇C++的入門參考書, 文內假設各位已經有
C 語言的基礎,是C++的初學者, 讀者至少必須對C有相當程度的熟悉, 如流程
控制(if,for,while,switch...),指標,陣列,結構(struct), 都必須非常熟悉
, 否則恐怕會有閱讀上的困難....
本文件的目的是想要讓C++更好學, 使大家都能輕易的瞭解C++的精義。
因此本文件歡迎傳閱, 若有需要也歡迎做適當的修改, 以修正錯誤或增加可
讀性. 但請勿加入不雅的言語, 而且修改者務必註明修改者名稱及修改日期,
並保留原作者之簽名. 謝謝各位!
<1> 再談類別繼承
讓我們來繼續談上一回的繼承. 在繼承關係中, 一個類別的上一層稱為此
類別之父類別, 一個類別的下一層稱為此類別之子類別或衍生類別. 例如生物
類別為動物類別之父類別, 動物類別為生物類別之子類別.
C++有一個規定:"一個父類別的指標可以指向一個他的子類別"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
請看:
class father
{
};
class son:public father
{
};
void main()
{
father *man;
son peter;
man=&peter;
}
以上的敘述完全合法, 不會有任何錯誤. 至於有什麼用途, 等我們真正開
始做程式時你就會明瞭!
<2> 虛擬函式
我們改造一下上一個例子:
class father
{
public:
DoJob(); //做工作
};
class son:public father
{
public:
DoJob(); //做工作
};
void main()
{
father *man; //父親類別指標.
son peter;
man=&peter; //父親的指標可以指向兒子,這是上一章才說過的.
man->DoJob(); //到底是爸爸的DoJob會被呼叫呢?還是兒子的?
}
在上例中,爸爸和兒子都多了一個成員函式--DoJob(), 意思是叫他們作自己
的工作的意思!! 由於爸爸的工作和兒子不同, 所以內容當然不一樣啦!! 以上面
的寫法, 雖然man是指到peter, man->Dojob()應該要執行的是兒子的工作, 但是
程式到底會叫兒子執行爸爸的工作呢? 而是作自己的工作呢?
其實程式的本意當然是希望兒子執行他自己的工作啦!!(因為man 指到的是peter
啊!!) 可是照上面的寫法,C++卻會執行爸爸的工作..要讓程式能執行指標所指到
的人的函式, 程式必須這麼寫:
class father
{
public:
virtual DoJob(); //做工作
};
class son:public father
{
public:
virtual DoJob(); //做工作
};
void main()
{
father *man;
son peter;
man=&peter;
man->DoJob();//因為指標指到的是兒子,所以兒子做工作
}
上面的程式在函式前多加了"virtual"敘述, 稱作虛擬函式, 加上去之後,程
式便會根據指標所指的人,去執行他該做的事, 這樣瞭解嗎?
虛擬函式又叫動態連結,或晚連結, 因為到底要執行誰的函式要等到實際執行
才知道.
<3> 參考型別
在C++中,提供了一個C 所沒有的特性--"參考型別" 其實參考型別沒有什麼,
他只是替物件建立一個別名罷了!
請看:
int i=5; //i 是個int 物件.
int &j=i; //j 是 i 的別名,即j 是i 的參考,明白的說,
//i 和 j 是同一個變數的不同名字.
i++; //執行後 i 變成 6.
j++; //因為j 就是i ,故i 此時為 7.
所謂的"參考",其實就是別名. 就好像蔣中正又叫蔣介石一樣. 其實j 和i 是
同一個變數, 只是名字不同罷了!! 這樣懂乎?
其實如果只有這樣, 那參考還真是沒什麼用處! 事實上參考最大的用處,在於
函式傳參數時使用. 請看下例:
struct test //一個結構
{
int string[1000];
};
void function(test value) //此函式會印出value.string
{
cout << value.string;
}
void main()
{
test a; //建立一個a物件
function(a); //將a傳給函式
}
test結構是一個很大的結構, 光是a 這個物件就至少要佔掉2000 bytes的記
憶體, 各位想想, 當我將a 傳給function 的時候, 因為是傳值, 所以C++會先做
出一個test結構的 value物件, 然後再將a 一個位元一個位元的copy 給value,
天啊! 這既佔記憶體又耗時間, 如果我能直接將a 拿給function函式使用的話多
好啊!! 用傳參考就可以做到這一點, 而且不會像傳址那麼彆扭, 請看改進後的程
式碼:
struct test //一個結構
{
int string[1000];
};
void function(test & value) //傳參考,這裡多了一個 & 符號
{
cout << value.string;
}
void main()
{
test a; //建立一個a物件
function(a); //將a傳給函式,注意!!函式用法不變喔!!
}
只要照上面這樣寫, value 就會是a 的別名, 也就是說value 就是 a啦!!! (
但是生存期跟傳值時一樣) 不必多佔記憶體, 也不必花copy物件的時間. 這不是很
好嗎!! 參考的用處就在此, 這樣瞭解嗎?
<4> const 物件
相信熟悉C 語言的你, 對"#define"這個關鍵字應該很熟了吧!! 使用#define
可以在C語言中定義出常數, 例:
#define PI 3.1416159 //定義常數PI
void main()
{
cout << PI; //印出PI
}
可是#define使用在C++中卻有缺陷, (不過這個缺陷不是重點,為省各位的腦力
我就不講啦!!) 為此C++提出了新的定義常數的方法---const 物件!! 請看:
const double PI=3.1416159;
void main()
{
cout << PI; //印出PI
PI=10; //錯誤!!!const 物件不能被更改
}
所謂的const 物件, 其實他和一般的物件一樣, 但是他在定義後就不能改值了,
而且在定義時就必須要給初值,(不給不行喔!!) 若嘗試著去更動const物件, 則編譯
器會給予警告, 並終止編譯!!
<5> 行內函式
相信各位C 的高手們對巨集函式應該不陌生吧!! 巨集函式有執行速度快的優點,
可是C 的巨集函數卻是很麻煩, 一個不小心就會留下難以除錯的BUG!!
C++提供了行內函式, 用以取代傳統C 之巨集!! 其實行內函式很簡單, 只要在
函式名字的前面加上"inline"的識別字, C++就會視情況將行內函式拓展成巨集, 請
看:
inline int max(int a,int b)
{
if(a>b)
return a;
else
return b;
}
如此一來,max就是一個快速的巨集函式了!! 值得注意的是: 行內函式為巨集,
故不可遞迴, 即不可呼叫自己.
現在讓我們來回溯一下我們第一章所建立的子彈類別:
┌──────────────────────────────────┐
│class _Bullet//這是一個 "子彈" 的 "模子",改用class來寫 │
│{ │
│ private: //私用成員 │
│ int x; │
│ int y; │
│ void show(int x,int y); //這是一個函式,可以在(x,y)上畫 │
│ public: //公用成員 出一點. │
│ _Bullet(){x=y=0;} //無參數之建構函式. │
│ _Bullet(int X,int Y){x=X;y=Y;} //有兩個參數之建構函式. │
│ void go() //這是一個函式,呼叫他可以讓子彈│
│ { //往下移一格並畫出來. │
│ show(x,y); │
│ y++; │
│ } │
│ int collision(int X,int Y) //這是一個函式,用來判斷子彈是 │
│ { //否撞到東西. │
│ return (x==X && Y==y); //不是則傳回0 │
│ } │
│}; │
└──────────────────────────────────┘
在這個類別中,類別內函式成員都是定義在類別中,(注意!!定義和宣告是不
一樣的!!) 其實我們也可以定義在類別外的, 請看:
┌──────────────────────────────────┐
│class _Bullet │
│{ │
│ private: │
│ int x; │
│ int y; │
│ void show(int x,int y); │
│ public: │
│ _Bullet(); //只宣告不定義 │
│ _Bullet(int X,int Y); │
│ void go(); │
│ int collision(int X,int Y); │
│}; │
│ │
│Bullet::_Bullet() //定義在外的建構函式 │
│{ │
│ x=y=0; │
│} │
│ │
│_Bullet::_Bullet(int X,int Y) //同上 │
│{ │
│ x=X; │
│ y=Y; │
│} │
│ │
│void _Bullet::go() //同上 │
│{ │
│ show(x,y); │
│ y++; │
│} │
│ │
│int _Bullet::collision(int X,int Y) //同上 │
│{ │
│ return (x==X && Y==y); │
│} │
└──────────────────────────────────┘
一個類別的函式成員若過大, 定義在外面是比較好的, 因為這樣子好看多了!!
相信從上例大家應該可以學會類別內函式定義在外的語法!! 若要將類別的函式成
員定義在外, 其語法為:
函式傳回值 所屬類別::函式名(參數)
{
......
}
基本上,對於定義在內的成員,C++會將其編碼為行內函式, 定義在外的則編碼
為一般函式!! 若要定義在外的也為行內函式, 只要加上inline敘述即可!!
<第二章結束>
小樹 1996 8/16
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
發信人：bbs@neptune.cksh.tp.edu.tw
日期：Fri Oct 24 09:20:01 1997
標題：咱騞犰V(oop)基礎講議 -- 3
作者: lcr (小牛) 看板: CKCSC
標題: 物件導向(oop)基礎講議 -- 3
時間: Tue Oct 15 04:47:02 1996
C++物件導向程式語言簡明教程之三
<第三章 物件導向程式設計實作>
撰文:程式創作區 小樹 使用編譯器:Turbo C++ 3.0
修改:lcr(小牛)
修改前言: 這篇小樹寫的 oop 概念蠻容易懂的, 蠻適合初學者看一下..
只是筆者覺得寫的有點亂亂的 (^_^), 所以小弟在這整理了一下,
並沒有修改內容....請小樹哥哥見諒啦....:p
Lcr (1996.10.13)
讀者須知:
本文章由C 開始談起, 算是一篇C++的入門參考書, 文內假設各位已經有
C 語言的基礎,是C++的初學者, 讀者至少必須對C有相當程度的熟悉, 如流程
控制(if,for,while,switch...),指標,陣列,結構(struct), 都必須非常熟悉
, 否則恐怕會有閱讀上的困難....
本文件的目的是想要讓C++更好學, 使大家都能輕易的瞭解C++的精義。
因此本文件歡迎傳閱, 若有需要也歡迎做適當的修改, 以修正錯誤或增加可
讀性. 但請勿加入不雅的言語, 而且修改者務必註明修改者名稱及修改日期,
並保留原作者之簽名. 謝謝各位!
<1> 何謂物件導向
所謂的物件導向程式設計, 簡單的說就是擬人化的程式設計.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
也就是說我們所設計的不再是一個個的函式, 而是一個個有生命力的物件.
其實各位可以把物件想成一個個不同職業的人, 物件的成員函式就是要求這個
人服務的管道. 而類別則是造人的模子!
我們用各種不同的模子作出各種不同職業的人, 然後藉由人與人的互相溝
通, 而架構起整個程式. 這樣說或許有點模糊, 但是等你看完整個教程再回來
看這一段, 相信你一定會發出會心的一笑.
<2> 事件驅動
接下來我們要實際的做一個物件導向的程式, 既然要做程式, 就必須要有
題目. 事件驅動核心是一個很能充份表達物件導向精神的題目, 而且又不會太
難, 所以我們決定以它為這個教程的範例.
那麼什麼是事件驅動呢? 相信寫過Windows的程式的讀者必不陌生. 因為
Windows本身就是一個事件驅動的核心!!! 以前我們在寫程式時, 程式必須主動
的查詢電腦的各種狀況, 例如鍵盤是否被按下去啦?! 滑鼠是否移動了啦?!特定
的時間間隔是否到了啦?! 像以上我們所說的這些東西就稱為事件!! 以從前的
作法, 我們所寫的程式必須主動不斷的去查詢事件是否發生, 若發生,則依發生
事件的種類分去處理. 這是一種很複雜的作法....
所謂的事件驅動式的程式設計, 就是有一個核心,(他是一個物件,也就是一
個"人",名字叫"Kernel"好了!! ) 他會主動去偵測事件是否發生, 若有事件發生,
則通知專門處理這個事件的人(物件)來處理(可能不只一個喔!!) 也就是說, 整個
程式只有核心是主動的, 其他的部份各司所職, 平常時並不動作, 只有當與自己
有關的事件發生時才會被核心通知去處理. 這樣子程式會很有條理, 有問題時也
可以很容易的查出錯誤在哪裡. 而我們要架構的,就是這這樣的一個核心.
<3> 萬物的起源--基本類別
人是一種動物, 動物是一種生物, 生物是一種物體, 所以人也是一種物體.
所有的東西都是一種物體. 由上可知, 在自然界存在有一種"最基本類別" 一切
類別都是他的子類別, 在C++當然也不例外. 通常這個最基本類別會叫做"Object",
也就是物體的意思. 不過這個字太常用了, 很多類別庫都用這個名字. 為了避免
與他們衝到, 我們把我們的最基本類別稱作"_Thing", 請看_Thing的程式碼:(存於
thing.h中):
┌──────────────────────────────────┐
│#ifndef _THING_ //防止重複include用 │
│#define _THING_ │
│ │
│#include "class.h" │
│class _Thing │
│{ │
│ public: │
│ _Thing(){} //建構函式 │
│ virtual ~_Thing(){} //解構函式,必須宣告為虛擬函式 │
│ //呼叫此函式則會傳回物件所屬類別的代碼 │
│ virtual unsigned Is(){return IAm_Thing;} │
│}; │
│ │
│#endif │
└──────────────────────────────────┘
既然_Thing是最基本類別, 因此他有的特性萬物都會擁有. 因為萬物都是一
種_Thing.(萬物都是一種"東西"), 現在讓我們來看看他有哪些特性:
<1> 建構函式:雖然是空的,不過擺著比較好看
<2> 解構函式:解構函式必須是虛擬函式,為什麼以後再說
<3> Is()函式:這是一個報姓名的函式,意思是問物件說你是哪一種人啊?(什麼類
別?) 於是物件會傳回一數值, 我們可由此數值以及class.h中的
記錄得知此物件是什麼類別生出來的
<4> class.h :這是一個含括檔,記錄所有類別的代碼,詳細內容如下:
┌──────────────────────────────────┐
│#ifndef _CLASS_ //防止重複include用 │
│#define _CLASS_ │
│ │
│const unsigned IAm_Thing=0; │
│const unsigned IAm_Letter=1; │
│const unsigned IAm_EventReceiver=2; │
│const unsigned IAm_Kernel=3; │
│const unsigned IAm_KeyBoard=4; │
│ │
│#endif │
└──────────────────────────────────┘
最基本類別是寫物件導向程式一定要先定義的, 所以我們就先寫出來啦!
至於為什麼一定要定義呢? 原因有二:
<1> 好看,整個類別繼承的很完整
<2> 方便做包含者類別
第二個原因一時之間很難解釋是什麼意思, 先不要管他, 我們繼續作下去便
是了!!
<4> 設計類別種類及內容
我們來複習一下前面所講到的核心是什麼樣子: 所謂的事件驅動式的程式設
計, 就是有一個核心,(他是一個物件,也就是一個"人",名字叫"Kernel"好了!! )
他會主動去偵測事件是否發生, 若有事件發生, 則通知專門處理這個事件的人(
物件)來處理(可能不只一個喔!!) 也就是說, 整個程式只有核心是主動的, 其他
的部份各司所職, 平常時並不動作, 只有當與自己有關的事件發生時才會被核心
通知去處理.
問題來了:
第一:Kernel怎麼知道當一事件發生時要通知誰呢? (想一下喔..)
所以必須先由想要要求事件處理權的人先向Kernel報到, 例如物件
LittleTree希望Kernel在鍵盤事件發生時通知他, 他必須先這樣做:
Kernel.RequestKeyEvent(&LittleTree), 意思是告訴Kernel說 LittleTree
希望Kernel在鍵盤事件發生時告訴LittleTree, 並把LittleTree的位址告訴
Kernel好讓Kernel通知他!
同理,若物件KenLin希望Kernel在滑鼠事件發生時通知他, 他必須先這樣
做:Kernel.RequestMouseEvent(&KenLin) 意思是告訴Kernel說KenLin 希望
Kernel在滑鼠有動作時告訴KenLin, 並把KenLin的位址告訴Kernel好讓Kernel
通知他!
先說明一點:Kernel一開始是不活動的!!
也就是說就算事件發生了,Kernel也會置之不理!!
因為程式執行之初是專門讓各事件處理人向Kernel報到用的!
當一切處理就緒,呼叫Kernel.Go()!! (意思是說Kernel,開始幹活吧!)
Kernel便開始活動!!此時一旦有事件發生,
Kernel便會依照事件的種類通知事前曾登記過的事件處理人.
第二:Kernel要怎麼做出來呢? (想一下喔..)
當然是用模子(類別)做出來的啊!! Kernel的模子叫做 _Kernel. 還記得
先前講過的_Thing類別嗎? _Kernel是一種"東西", 所以_Kernel也是一種
_Thing啦!!! 換句話說,_Kernel是繼承自_Thing的! 以C++的表示法如下:
(存於Kernel.h檔中)
┌───────────────────────────────────┐
│#ifndef _KERNEL_ │
│#define _KERNEL_ │
│ │
│#include "Evrece.h" //先不要管這一行是做什麼的 │
│#include "thing.h" │
│#include "class.h" │
│class _Kernel:public _Thing │
│{ │
│ public: │
│ _Kernel(); //建構函式. │
│ virtual ~_Kernel(); //解構函式. │
│ virtual unsigned Is(){return IAm_Kernel;} │
│ void Go(); //叫Kernel工作的函式. │
│ void RequestKeyEvent(_EventReceiver *); //要求鍵盤事件的函式. │
│ void RequesrMouseEvent(_EventReceiver *); //要求滑鼠事件的函式. │
│}; │
│ │
│#endif │
└───────────────────────────────────┘
而一個應用程式,要寫成下面的樣子:
#include "Kernel.h"
void main()
{
_Kernel Kernel; //用模子做出Kernel.
~~~~~~~; //做出其他的物件,並向Kernel申請事件的處理權!
//此時Kernel並不工作.
_Kernel.Go(); //Kernel開始工作啦!!
}
第三:Kernel要如何詳細的告訴事件處理人所發生的事件的詳細情形呢? 比如說一
個鍵盤事件, 有可能是A鍵被按了,也可能是B, Kernel要如何告訴事件處理人
到底是那個鍵被按了呢? (想一下喔..)
當然是"寫信"告訴他啦!! 首先必須要有一個信信類別 _Letter, 此類
別必須能夠詳細記載各種可能的事件, 當事件發生時,Kernel先用_Letter類
別做出一封信, 然後在信中記載事件的詳細情形!! 再將信信傳給事件處理人
, 以下是Kernel的處理過程:
_Letter Letter; //先做出一封信
~~~~~~~~; //將所發生的事詳細的寫入信中
LittleTree.ReceiveLetter(Letter); //將信寄給事件處理人
讓我們來把_Letter類別做出來:(此檔存於Letter.h中)
┌──────────────────────────────────┐
│#ifndef _LETTER_ │
│#define _LETTER_ │
│ │
│#include "thing.h" │
│#include "event.h" │
│#include "class.h" │
│class _Letter:public _Thing //信也是一種"東西" │
│{ │
│ public: │
│ _Letter(){EventKind=EvNothing;Message=NULL;}; //建構. │
│ virtual ~_Letter(); //解構. │
│ virtual unsigned Is(){return IAm_Letter;} │
│ unsigned EventKind; //記載事件的種類. │
│ unsigned Key; //若是鍵盤事件則記錄所按之鍵值. │
│ unsigned MouseX,MouseY; //若是滑鼠事件則記錄滑鼠目前之位置. │
│ char *Message; //若是訊息事件則記錄訊息於此. │
│}; │
│ │
│#endif │
└──────────────────────────────────┘
現在讓我們來看看他有哪些特性:
<1> include "event.h":
event.h中記載了所有事件的代碼, 請看:
┌─────────────────────────────┐
│ │
│ #ifndef _EVENT_ │
│ #define _EVENT_ │
│ │
│ const unsigned EvNothing=0; //沒事 │
│ const unsigned EvKeyDown=1; //鍵盤被按下去了! │
│ const unsigned EvKeyUp=2; //鍵盤被放開 │
│ const unsigned EVMouseMove=3; //滑鼠移動了 │
│ const unsugned EvMouseLeftDown=4; //滑鼠左鍵被按下 │
│ const unsugned EvMouseLeftUp=5; //滑鼠左鍵被放開 │
│ const unsugned EvMouseRightDown=6; //滑鼠右鍵被放開 │
│ const unsugned EvMouseRightUp=7; //滑鼠右鍵被放開 │
│ const unsigned EvMessage=8; //傳送訊息事件 │
│ const unsigned EvTimer=9; //時間事件 │
│ const unsigned EvEnd=10; //"核心即將終止"事件 │
│ const unsigned EvKernelStart=11; //"核心開始動作"事件 │
│ #endif │
│ │
│ _Letter類別中的EventKind就是以此代碼記載事件的 │
└─────────────────────────────┘
<2>
unsigned Key; //若是鍵盤事件則記錄所按之鍵值
unsigned MouseX,MouseY; //若是滑鼠事件則記錄滑鼠目前之位置
char *Message; //若是訊息事件則記錄訊息於此
此三個變數分別記載事件的詳細內容
在event.h中記載有很多種事件的代名及代碼, 事實上為了簡單起見,
我們將僅做出鍵盤事件, 也就是說在我們的教程中Kernel只會偵察鍵盤事
件啦! 其他的事件, 若各位有興趣可以自己做做看!
第四:雖然我們已做出_Letter類別,可以寄信給專門處理事件的物件, 可是當初各
個物件向Kernel申請事件處理權的時候, 只留下位址而已,我們要如何根據此
位址來傳信給他呢? (想一想喔..)
以下的文章請一口氣看完, 瀏覽一遍後再回頭來詳細看會比較好瞭解!
所有能夠收信的物件(人)都是一種事件接收者-- _EventReceiver 我們這樣寫:
(EvRece.h)
┌──────────────────────────────────┐
│#ifndef _EVENTRECEIVER_ │
│#define _EVENTRECEIVER_ │
│ │
│#include "class.h" │
│#include "thing.h" │
│typedef int Bool │
│class _EventReceiver:public _Thing //事件接收者也是一種_Thing │
│{ │
│ _EventReceiver(){} │
│ virtual ~_EventReceiver(); │
│ virtual unsigned Is(){return IAm_EventReceiver;} │
│ //這是收信信用的函式,成功的處理完所發生的事件後則傳回True,│
│ //否則傳回False │
│ virtual Bool ReceiveLetter(_Letter &){return 1} │
│}; │
│ │
│#endif │
└──────────────────────────────────┘
基本上,_Eventreceiver和_Thing一樣,都是一種基本類別, 所謂的基本類別,
通常是不拿來直接定義物件的!! 而是拿來當作其他類別的父類別!!因為
_EventReceiver類別多了一個虛擬函式-- ReceiveLetter() 所以所有繼承自此類
別的類別所做出來的物件都會有接收信信的能力, 換句話說, 所有想要有收信信能
力的人都需要是一種_EventReceiver, 比如說Kernel不是一種_EventReceiver他當
然不能收信, 我這樣講你可能不懂, 讓我舉個例子:
┌───────────────────────────────────┐
│class _KeyEventReceiver:public _EventReceiver //鍵盤事件接收者類別 │
│{ │
│ public: │
│ //當鍵盤事件發生時Kernel藉由此函式通知他 │
│ virtual Bool ReceiverLetter(_Letter &Letter) │
│ { │
│ cout << Letter.Key; //此類別收到信信後的反應 │
│ return 1; │
│ } │
│}; │
│ │
│void main() │
│{ │
│ _Kernel Kernel; //生出Kernel │
│ _KeyEventReceiver LittleTree; //生出LittleTree │
│ Kernel.RequestKeyEvent(&LittleTree); │
│ //LittleTree向Kernel申請鍵盤事件處理權│
│ Kernel.Go(); //Kernel開始幹活吧! │
│} │
└───────────────────────────────────┘
在Kernel.Go()中,Kernel到底是怎麼呼叫LittleTree的呢? 讓我們來看看新
的Kernel的程式碼:
┌───────────────────────────────────┐
│class _Kernel:public _Thing │
│{ │
│ unsigned KeyEventReceiverCount; │
│ //記錄有多少人申請鍵盤事件處理權 │
│ _EventReceiver *KeyEventReceiver[30]; │
│ //用來記錄所有申請鍵盤事件處理權的物件的位址,最多30人 │
│ public: │
│ _Kernel(){KeyEventReceiverCount=0;} //建構函式 │
│ virtual ~_Kernel(); //解構函式 │
│ virtual Is(){return IAm_Kernel;} │
│ void Go(); //叫Kernel工作的函式 │
│ void RequestKeyEvent(_EventReceiver *); //要求鍵盤事件的函式 │
│ void RequesrMouseEvent(_EventReceiver *); //要求滑鼠事件的函式 │
│ _Letter Letter; //做出一封信 │
│}; │
│ │
│void _Kernel::RequestKeyEvent(_EventReceiver *Receiver) │
│{ │
│ KeyEventReceiver[KeyEventReceiverCount]=Receiver; │
│ KeyEventReceiverCount++; │
│} │
│ │
│void _Kernel:::Go() │
│{ │
│ while (1) │
│ { │
│ if(bioskey(1) != 0)//如果鍵盤事件發生 │
│ { │
│ Letter.EventKind=EvKeyDown; │
│ //將信中的事件種類改成鍵盤事件 │
│ Letter.Key=bioskey(0);//由鍵盤讀入一鍵 │
│ for(unsigned i=0;i<KeyEventReceiverCount;i++) │
│ KeyEventReceiver[i]->ReceiveLetter(Letter);//送信的動作 │
│ //將此信傳給所有鍵盤事件處理人 │
│ } │
│ } │
│} │
└───────────────────────────────────┘
第五: 要怎麼讓Kernel停止工作呢? (想一想..)
任何物件只要呼叫Kernel.End()就可以停止核心的工作了! 可是這樣會有
兩個問題:
1.Kernel是怎麼把自己停下來的呢?
2.各物件又不知道Kernel的位址,要怎麼呼叫他呢?
我們先解決第二個問題: 其實很簡單, 只要在_Letter類別中記錄下核心的
位址就好了啊!
┌──────────────────────────────────┐
│class _Letter:public _Thing //信也是一種"東西" │
│{ │
│ public: │
│ _Letter(){EventKind=EvNothing;Message=NULL;}; //建構 │
│ virtual ~_Letter(); //解構 │
│ virtual unsigned Is(){return IAm_Letter;} │
│ unsigned EventKind; //記載事件的種類. │
│ unsigned Key; //若是鍵盤事件則記錄所按之鍵值. │
│ unsigned MouseX,MouseY; //若是滑鼠事件則記錄滑鼠目前之位置│
│ char *Message; //若是訊息事件則記錄訊息於此. │
│ _Kernel KernelAddress; //這是記錄核心的位址用. │
│}; │
└──────────────────────────────────┘
如此一來,收到信信的事件處理人就可以根據Kernel的位址跟Kernel溝通了.
至於第一個問題,請看更新後的程式碼:
┌────────────────────────────────────┐
│ class _Kernel:public _Thing │
│ { │
│ unsigned KeyEventReceiverCount; //記錄有多少人申請鍵盤事件處理權. │
│ _EventReceiver *KeyEventReceiver[30]; │
│ //用來記錄所有申請鍵盤事件處理權的物件的位址,最多30人. │
│ int EndFlag; //多了這一個結束旗標 │
│ │
│ public: │
│ _Kernel(){KeyEventReceiverCount=0; │
│ EndFlag=0;Letter.KernelAddress=this;} //建構函式 │
│ virtual ~_Kernel(); //解構函式. │
│ virtual Is(){return IAm_Kernel;} │
│ void Go(); //叫Kernel工作的函式. │
│ void RequestKeyEvent(_EventReceiver *); //要求鍵盤事件的函式. │
│ void RequesrMouseEvent(_EventReceiver *); //要求滑鼠事件的函式. │
│ void End(); //多了這一個結束函式. │
│ _Letter Letter; //做出一封信. │
│ }; │
│ │
│ void _Kernel::RequestKeyEvent(_EventReceiver *Receiver) │
│ { │
│ KeyEventReceiver[KeyEventReceiverCount]=Receiver; │
│ KeyEventReceiverCount++; │
│ } │
│ │
│ void _Kernel:::Go() │
│ { │
│ while (1) │
│ { │
│ if(EndFlag==1) //若結束旗標為1則結束程式. │
│ break; │
│ if(bioskey(1) ==1) //如果鍵盤事件發生. │
│ { │
│ Letter.EventKind=EvKeyDown; //將信中的事件種類改成鍵盤事件. │
│ Letter.Key=bioskey(0); //由鍵盤讀入一鍵. │
│ //將此信傳給所有鍵盤事件處理人. │
│ for(unsigned i=0;i<KeyEventReceiverCount;i++) │
│ KeyEventReceiver[i]->ReceiveLetter(Letter); //送信的動作. │
│ } │
│ } │
│ } │
│ │
│ void _Kernel::End() │
│ { │
│ EndFlag=1; //將結束旗標設為1. │
│ Letter.EventKind=EvEnd; │
│ for(unsigned i=0;i<KeyEventReceiverCount;i++) │
│ KeyEventReceiver[i]->ReceiveLetter(Letter); │
│ //告訴所有的事件處理人程式即將結束,請做好善後準備.│
│ } │
└────────────────────────────────────┘
上面的程式碼中,在建構函式的地方, 用到了this這個指位器! this是一個C++
自己建立的指位器, 永遠指向現在正在操作的物件!! 當建構函式執行時, this當
然是指向Kernel啦! 所以把this拷貝一份給Letter.KernelAddress, 這樣
Letter.KernelAddress就能正確的指到Kernel了!
<5> 編碼及範例
接下來是一個範例, 程式碼我都已經收錄在檔區了! 麻煩大家去抓下來看一看.
程式並不難,重要的是物件導向的觀念. 整個程式其實就是一個物件和物件間的溝通史!
看完就知道整個物件導向的程式是怎麼運作的了! 事實上一個事件驅動的核心絕對不
只這麼簡單. 要考慮的事情是很多的!! 有興趣的人可以參考旗標的"事件驅動程式設
計"這本書是古清德先生寫的! 裡面有更詳細的說明! 相信看完這整個教程, 您對物件
導向的程式設計方法會有多一層的瞭解.
期待再與您見面, Bye!Bye!
全篇完
小樹
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
發信人： zmx (劇院之鬼) 看板：math89
日期： Fri Oct 24 09:30:41 1997
標題： 這三篇
簡易的 C++ 解說, 想學更多的人請看書, 還是推鑒 C++爸爸寫的
The C++ Programming Language. 中文的話, 松格出的 C++聖經
還可以. 我會在貼幾篇 OOP( Object-Oriented Programming )的東西
--
ZMX
The Phantom of The Opera
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
發信人: william@cis_nctu (C++/ASM/Win Master), 信區: oop
標 題: 物件導向的天空
發信站: 交大資科_BBS (May 18 01:51:10 1994)
轉信站: cis_nctu
FOOTNOTE by william@cis_nctu:
底下文章是由建中林俊杰先生兩三年前發表於「建中青年」刊物的文章 , 給各位參考。
其中該文的觀點多半出自 OMT 方法論。
註: 林俊杰現在應該就讀於台大數學系大二, 你可以在 HOPE BBS 看到他,
ID 為 Dickson Lin。
物件導向的天空
□林俊杰
前 言
「物件導向」這個名詞越來越熱門，似乎不懂它的人都好像活在上古世界一
般的過時，但知其然者未必知其所以然，物件的定義為何？物件導向的設計哲學
精髓為何？這些問題並非是人人都能答得上來的。
最近學C++的人口也開始上升，恐怕又會帶動另一股流行的風氣。但荒謬的
是大部分C++的教科書所講的內容根本就是Ｃ語言，外加一點物件導向程式設計
(OOP)的皮毛。這樣做真能學好C++嗎？筆者見真正把Ｃ的設計哲學搞懂的人士實
在不多，恐怕真正弄懂C++的更少。如果缺乏物件設計哲學概念的人用C++所寫的
程式恐怕也只是比較特別的Ｃ罷了。
其實物件導向是門很有趣的設計哲學，它試圖由人們對問題的看法來解釋軟
體的架構，並力求將問題的定義域映射到分析的模型，再轉成相對的程式碼。目
前使用物件導向技術的軟體如雨後春筍般地蓬勃發展，因此無論你是不是專業的
工程師，都應該對物件有所瞭解。
在後文中，將以物件導向軟體工程論為討論的核心，最後觸及C++與物件設
計的關係。如此精采的文章，你若再不猛Ｋ，豈有國法天理人情良心乎！
第 一 章 何謂物件 (OBJECTS)
物件的原文是Object，國內也有人把他譯為「個體」，「項目」、「目的」
等等，但為統一起見，在本文中一律統稱物件。而以物件為基礎的軟體設計哲學
，則一律冠以「物件導向」 (Object Oriented，簡寫為OO)的頭銜。故物件導向
程式設計便稱OOP (Object Oriented Programming ) 物體導向分析(Object
Oriented analysis, OOA)，物件導向程式語言(Object Oriented Programming
Lagnage,OOPL)如此類推，不一而足。然而，到底物件是什麼呢？電腦學家給它
一個定義：
一個抽象體、概念、或是一個有明確界定範圍的事物，並且在我們要解決的
問題中是有意義的。
舉兩個例子：筆者有部腳踏車，這是個物件，閣下手上看的建青也是個物件
。生活中形形色色的事物也都是物件，閣下亦復如此。這點概念大家都可以接受
，但光定義物件沒用，車子依舊在路上跑，和閣下的程式毫不相涉。再進一步去
研究，筆者的自行車是以鋁合金為車骨，輕且不生銹，而且它可以前進，可以剎
車，這也都沒啥奇怪，但經由以上的描述，我們已經定義出筆者的自行車，和它
的特性（鋁合金車架），及它的功能（前進、剎車）。當然這樣可能尚未臻周延
，因為我沒說我的車子有輪子，但我的程式或許不必知道那麼多！假定讀者你也
有部腳踏車，你的腳踏車的車身是塑膠製的，同樣的，您的車也可以前進、剎車
！理所當然，你的車也是個物件！上面提到筆者的及閣下的自行車，但其它的張
三李四也會有自行車，其中有鐵的，也可能有紙糊的！此時我們可定義一個叫「
自行車」的「類別」(class)。類別也同樣有個定義：
對於具有類似性質、相同的行為、意義及共同關係的物件之描述即為類別。
淺白的說，類別即是具相同性質物件的集合；反之，對於類別而言，物件則
為其「案例」(instance)。
傳統的軟體設計方式是將問題的對象分析之後，採取適當的資料結構來表示
，並以相對的程序函數演算法來處理資料，兩者看起來似乎獨立而無關。而現在
我們則以「物件」將相關的資料和程序結合成一體，使得兩者的關係看起來更明
白，這是物件導向程式設計最大的特點之一。
資訊隱藏(information hiding)，也就是物件的封裝性(encapsulation)，
可以明白分出物件可以被外界使用的特性及受保護的內部特性。把特性依存取權
限分類可以避免程式的其它部分誤用此物件，而導致不良的副作用。關於封裝性
在第六章有更深入的討論。
Cox 氏認為我們可以藉由建立物件程式庫來達成軟體IC的目標，理由是因為
物件具有重覆使用性(reusability)，而繼承(inheritance)則是達成重覆使用的策
略。叫它繼承可能有些語意不明，不過卻很貼切，以自行車這個類別來說，加裝
一具馬達就成了一部電動機踏車，電動機踏車依然可以前進、剎車，也有車身材
質，只不過多具馬達，因此這個電動機踏車類別便是由腳踏車遺傳而來的。繼承
在視窗的設計上特別有用。由最基本的視窗可以衍生出可捲頁的，可放大縮小的
......等等各式各樣的視窗。詳細的內容在後面的章節有更深入的介紹。
火車、汽車、機車都可以為人所駕駛。「駕駛」這個動作是個相當抽象的名
詞，火車、汽車、機車的駕駛方法都不一樣，但駕駛一詞涵蓋了實際上具有差異
性的駕駛行為。這種特質稱為「多形性」(polymophism)。
另方面，光知道物於物件的特性實在不足以解決我們的問題，如何將物件引
入軟體設計中呢？如何分析物件？如何遺傳？如何描述一整個系統中物件和物件
間的關係？這些還都是未知的問題。在後文中，筆者將以相當篇幅討論物件方法
論。在這個領域中應首推布奇(Booch)的研究成果，他有效的以圖表分析出物件
的結構及關聯。不過我並不打算多談，因為他的理論較偏重於傳統的設計理論，
對於遺傳等先進的概念顯得較薄弱，筆者將以勞恩森 (Lorensen) 等人所提出的
OMT ( Object Modeling Technique ) 為骨幹。這套理論有一套極完整的發展過
程。OMT是他們用以發展軟體的方法，因此在實作方面的效果相當理想。
物件導向軟體工程有項特點，就是試圖以建立「模型」的方式來分析問題。
OMT法尤甚，它以三種基礎模型來敘述整個軟體的結構、運作模式，它們分別是
：
𣇈物件模型(Object Model)
描述物件的結構及物件間的關係
𥌓動態模型(Dynamic Model)
系統的狀況時時都有變化，動態模型以事件發生和狀態的改變來描述系統中
的交互作用。
矅功能模型(Functional Model)
功能模型是OMT包容傳統軟體設計的一部分。它藉由資料流程圖(Data Flow
Diagram，DFD)來描述資料轉換或計算之流程。關於DFD，讀友可參考建青
94期筆者拙作「軟體設計的思維」一文。
OMT的軟體設計步驟是分析(Analysis)、系統設計(System Design)、物件設
計(Object Design)在來是實作(Implementation)之本質則是以物件觀點建立前
述三種模型，再加以設計、統合、然後映射成為程式碼。
藉由物件導向的方式來設計軟體可以有效的提升軟體設計的效率，（雖然在
由舊方法轉入物件導向時可能會有降低的現象）。舉個明顯的例子：Borland 公
司在Quattro推出半年多後推出Quattro Pro，三個月後視窗版就問世了。這麼快的
速度完全是拜物件導向法所賜，也使Borland公司大賺其錢（該公司號稱年成長
率百分之兩百）。以生產dBASE著名的安信達公司在dBASE III推出數年後才推出
dBASE IV 1.0版，而且還是伴隨一堆Bug上市的。最後，在幾個月前Borland終於
併吞了安信達！
1.2 物件模型(Object Model)
物件必定具備兩個基本的構要素：屬性(attributes)及行為(behavior)，也
就是物件的運作(operation)。再舉前面的例子，自行車類別中關於車身材料等
等靜態的資料就是屬性，而自行車可以做的動作，如前進、煞車等等都屬於屬性
。也就是說，類別中靜態的資料成員就是該類別的屬性，而該類別動態的演算法
就是這個類別的行為或是運作(operation)。那何謂運作，何謂方法(Method)呢
？兩者有什麼不同呢？前一節曾經提到「駕駛」這個抽象化的工作，「駕駛」在
此便是個operation，而實際的、真正的駕駛則是屬於各別物件的特定方法
(method)。例如說，開轎車的方法和開七四七就不一樣，但一樣都都被稱為是駕
駛，但這不是掛羊頭賣狗肉的勾當！
請看官大爺注意，在還未實作之前，所有的概念都是抽象化的，因此腦中除
了考慮你的問題外，不必急著去想在電腦上設計的細節，除非你所要解決的問題
本身就與電腦有關。
1.2 物件之間的關係
1.2.1 鏈結(Links)
假定我們現在有二個物件案例(instance)，一位是張老師，一位是王同學。
張老師和王同學這兩個物件的屬性和行為我們暫且不關心。張老師與王同學之間
存在某種關係，由參考圖1.1可以看出張老師「教導」王同學。反過來看，王同
學則「受教」於張老師。這兩個案例間的關係便是鏈結。
1.2.2 關聯(Associations)
在Link鏈結的部分，我們的案例(instance)是張老師和王同學，但老師可能
是趙錢孫李，同學也可能是周吳鄭王。將兩個案例一般化後，我們得到兩個單純
抽象的類別；老師類別(class teacher)及同學類別(class student)。各同學各
老師之間鏈結的集合便稱為關聯(associations)。也就是說，鏈結是真實世界中
物件的關係，而是將鏈結抽象化，一般化後我們便可得到關聯(association)。
讀者在此應先建立一個概念，物件導向的分析規則是由特殊到一般，由實體
到抽象，就像我們先以張老師和王同學為研究樣本，再將他們的關係抽象化。往
後還有更多的例子。
一個老師所施教的對象通常有許多位學生而不只是一位。此時，這個教導的
關係便成一對多(one-to-many)的關係，如圖1.2所示。而若一個學生只向一位老
師求教，教導關係則為1對1(one-to-one)；若一個學生不僅僅只有一位老師，教
導關係就成了多對一了！請讀者試著看懂我們所用的圖形表示法，並且比較其間
的差異。在真實世界中，關係是相當具多樣性的。例如說它可能是個選擇性關係
(optional association)。例如在一夫一妻制國家中，一個男人可以選擇單身（
無妻）或有唯一的配偶，如圖1.3所示。但中國古時候是行一夫多妻制的，窮漢
子可能一個老婆都沒有；市井小民或許只養得起一口子；天子王侯可能就藏嬌無
數了！這就如圖1.4所示了。圖1.3中的關係是1或無，圖1.4是無或許多。筆者在
此特別聲明我絕對沒別的意思。
關係(association)也可以不只限定於二元關係(binary association)，它
可能是三元性(ternary association)或多元性的。圖1.5 表示老師、學生及教
室的三元關係。
1.2.3 鏈結的屬性(Link attributes)
前面所提到的鏈結都蠻單純的，但真實情況中，鏈結可能有條件或範圍上的
限制。例如在一個多使用者(multi-users)的作業系統(operating system)中，
每個user對檔案的存取都有不同的權限，這點在93期建青筆者拙作「切開MS-DOS
」中有介紹，各位看官可翻閱參考一下。使用者依其層級不同，可以讀寫檔案，
或僅能讀檔，甚至連沾邊的機會都談不上。這麼做的理由是為了保證檔案的安全
所設的規定。此時User這個物件在對於檔案物件的存取關係中，便具有存取權的
屬性。如圖1.6所示。
一個較特殊的鏈接屬性稱為資格(qualificiation)。可將其視為是具有邏輯
性的屬性。例如關卡的通行許可。「通行」只有准許及拒絕的判定，不可能只允
許前腳進，後腳出，身體跨在門中間。因此這種關係是「資格」的判定問題。
1.2.4 集合(aggregation)
「集合」表明了一種物件組成的關係。例如汽車物件是由輪子物件、引擎物
件、齒輪箱物件，車殼物件等等物件所組成的集合體。如果Ａ物件是Ｂ元件的一
部分，Ｂ物件是Ｃ物件的一部分，則Ｂ物件亦會是Ｃ物件的一部分。則Ａ物件是
Ｃ物件的一部分。Ａ物件是Ｂ物件的一部分。則Ｂ物件必非Ａ物件之一部分！
這個概念在視窗設計上也很有用！你可以利用按鈕物件和視窗物件組合成一
個對話盒物件。集合關係(aggregation)很容易就和遺傳或其他特性搞混了，讀者
宜注意。
1.2.5 遺傳(Inheritance)及歸納關係(Generalization)
我相信只要是對物件導向稍有接觸的朋友都必定對「遺傳」(inheritance)
這名詞不陌生。遺傳和歸納關係提供了程式碼重複使用的可行方案。由生物學的
觀點來看遺傳：子代的特徵都來自於親代。由電腦的觀點來看遺傳：遺傳就是類
似軟體元件共用，並且分享相同的行為以及相似的特性或運作。一個被遺傳的父
代類別 ( parent class ) 被我們稱為「超級類別」(super class)。而子代類
別(child class)被稱為副類別(subclass)。父類別和子類別之間則存在有歸納
關係(Generalization)，而同時也是表示”is-a”或”a-kind-of”的關係，這
代表什麼呢？子類別的案例(instance)同時也必須是父類別的案例。這項特性十
分的合理，假定子類別被修改的和父類別不同，悲劇將無可避免的產生：適用於
父類別的運作(operation)無法正確的適用於子類別上，而設計者在不知情的狀
況下，軟體可能會當掉或失誤。但子類別並非不能修改。你可以修改(refine)及
增加(append)一個子類別的屬性(attribute)及運作(operation)之內部方法 (
method ) ，請讀者回憶前面章節曾說明過運作和方法的差異。運作(operation)
是一個動作的「簽名」(signature)，也就是某一動作的名稱。但筆者在此所說
的修改，是屬於「機能性」的修改，意謂為了適應新物件的運作方式，而必需修
改其內部的方法(method)，以符合新的要求，但該方法最後所要達成的目的應該
和舊方法是一致的，非重新定義。例如我們把”＋”定義為運算上的加法，而你
卻要定義為減法，這不是挺危險的嗎？不幸地，目前的程式語言並不會主動地警
告設計者這個潛在的危險，而成為一個軟體陷井。
剛才我們曾討論了一個重點：為了適應新物件的新特性，而必需修改其內部
的方法，但運作的簽名(signature)卻必需維持相同，這種特稱性便為「凌越」
(overriding)，但和C++中的「多重載入」(overloading)並不相同，請讀者自行
比較。
在此舉一個範例。在一個幾何繪圖的程式中，我們嘗試提供點、線、弧線、
多邊形、圓形的繪圖元件。在此範例中，筆者將以物件分析(OOA)中關於物件模
型的方法來分析這個例子。
我們先試著描述這個繪圖系統的各種圖形元件（先分析案例）。因為用文字
說明佔去篇幅繁浩，故把各物作類別的特性列於圖中。決定各類別後，得視情況
將類別多餘的，無效的屬性或運作剔除，並且將一些可以做成物件的特徵獨立成
為物件（不過在範例中似乎沒有）。下一步是鑑別物件與物件的關係(link)，單
就這些物件來看也缺乏關聯。接下來，觀察這些物件是否用了一些共同的特徵（
屬性及行為），將共用的特徵萃取出來，形成父類別。在範例中，我們可以先將
物件分成三類，分別是零維、一維及二維圖形(用generalization)，而且一維及
二維圖形可以按比例(scale)伸縮，但三維圖形中間空白部分則可以填色(fill)
還可以把顏色、位置、移動．．．．等等特徵歸納成一個最終的父類別，也就是
圖形(figure)類別。如此我們又得到一張新的參考圖1.7。同時，在此也可以考
慮引用舊的物件。
在圖中，我們發現物件顯示(display)的功能被凌越(overriding)了！為什
麼呢？因為畫法不同啊！但圖形(figure)那個類別要幹啥呢？一點用也沒有！但
他可以表示各subclass的共同特性。任何類別只要有一個運作是抽象的
(abstract)，這個類別就是一個抽象類別(abstract class)。抽象類別不能產生
案例(instance)，但卻可供為遺傳的父類別。相對於抽象類別的是實體類別，實
體類別可以衍生子代，也可以產生案例(instance)。
另一個爭議是應該遺傳幾代。遺傳太多代可能會使子代不好懂。太少嘛，不
太合乎經濟效益，二、三層很好，六、七層勉強接受、十幾層恐怕令人咋舌了。
為什麼呢？是這樣的，理論上類別應該可以被無窮的遺傳，產生新的類別，但是
常常發生在遺傳數代後的子類別的特性竟然「變質」了！父代類別的舊屬性或是
舊運作變得囉唆多餘了，如果你繼續引用遺傳，那可能會變得沒有效率，因此，
筆者認為物件重複遺傳的次數應該會有一個自然上限，但這個上限是幾層呢？這
就和你所設計的物件好壞有關了。
1.2.6 多重繼承(Multiple Inheritance)
前面所提到的都是單源繼承(single inheritance)，十分單純，相較之下，
多重繼承允許一個物件同時繼承許多不同物件的特性，這種方式更接近人類思考
的方法，不過相對也產生不少問題。所謂多重繼承即是一個子物件可同時繼承許
多父類別，通常我們叫這種子類別為「聯合類別」(join class)。
多重繼承最常引發的麻煩便是「模稜兩可」(ambiguity) 的紛爭。這肇因於
父類別中的屬性或運作可能具有類似的簽名。這種情況無法以程式語言的特性避
免（雖然某些程式語言可以設定繼承的優先順序），程式設計師應該要盡力避免
模稜兩可的問題。另外值得注意的一點是某些較舊的物件導向程式語言(OOPL)並
不具備多重繼承的特性，例如：Smalltalk-80，C++ 1.2，Objective-C。
1.3 集合與其它關係的比較
物件與物件之間的關係是極令人感興趣的，一個程式不太可能僅由一些簡單
的物件架構而成。前面筆者曾說過集合(aggregation)很容易和其他種類的關係
搞混，在這節中，我們將討論它們有啥差異。讀者在往下看之前，不妨自己先比
較一下，看看自己是否也搞混了。
1.3.1 集合和關係(association)的比較
集合是關係(association)一種特例，但集合關係卻特別指出某個特定物件
是由那些物件組成的。就好比一部機器與組成它的螺絲釘之間的關係。主要的判
定方式是：如果一個物件是另一個物件的組成元素，那麼便存在「集合」的關係
了。
1.3.2 集合和遺傳(Inheritance)的比較
集合和遺傳並不一樣。遺傳關係通常被稱為”is-a”或”is-kind-of”（是
一個，是一種），理由前面已經講過了，而集合則被叫做”a-part-of”（一部
分）。
不過，有時我們最好選擇集合關係來替代遺傳的運用。先舉一例。串列結構
(list)是資料結構中一種儲存資料的基本方法，而堆疊(stack)是一種 FILO (
first in ，last out ) 先進後出的結構，關於這方面請讀者自行參考與資料結
構有關的書籍。串列有些基本的運作方法，例如說：增加節點，刪除節點等等。
現在我們要實作堆疊，而堆疊有自己惟一的存取方法也就是它的運作──推入
(push)和彈出(pop)。我們可以採取兩套策略來獲得「堆疊」類別。第一：由串
列遺傳出新的「堆疊」類別，但注意！那些刪除節點之類的運作(operation)也
會被遺傳下來，然而對堆疊來說，不但不需要這些多餘的運作，也不能要，因為
可能意外地刪除節點。因此建議採第二種策略：把串列和堆疊以集合
(aggregation)連起來，就是說把串列變成堆疊的一部分。如圖1.8所示。
關於物件模型(object model)的部分就介紹到此，由於物件模型是最基本而
重要的一部分，讀者宜多留心。
第二章 動態模型 (Dynamic Model)
2.1 概說
上一章所討論的物件模型，是屬於物件導向中靜態的部分。而這章則要仔細
地探討物件的行為，及物件之間的交互作用。
2.2 事件(events)和狀態(states)
概括的說，物件中的屬性及鏈結(link)，都屬於該物件的狀態(state)。而
一物件之狀態則會因事件(events)的影響而改變。在下面的討論中，讀者會發現
我們較偏重於即時(real-time)程式的設計，事實上亦是如此。
事件是指發生在某時刻的某事，而且理論上它並不會持續一段時間。例如電
話鈴響就是一種事件。事件通常由一個物件發出，而被另一個物件接受。而且事
件只是單向性的訊息傳遞，而不像函數會帶有傳回值。事件也是一種特殊的類別
，他可以具備有屬性。例如說：撥電話號碼(dial)這個動作也隱含著撥某個號碼
，例如說：撥”5”、撥”1”等等。同理，「錯誤」也可以被設計成事件，而且
伴隨有錯誤代碼。
狀態(states)是物件屬性或鏈結的抽象體。狀態是被動的而且只在此事件發
生後才改變，因此我們可視為兩事件發生間的時間為此物件的狀態，也就是說，
某個狀態將會持續一段時間，直到下個事件發生為止。
為了表示出一連串的事件及他們發生的順序，我們得編一套事件的「劇本」
(scenario)。這個劇本十分重要，有劇本才能讓模型”活起來”。劇本的產生通
常是以平常可能發生的情況為主體，再加入例外。然而，劇本也有可能不甚詳盡
，但是可以改！
劇本準備好了之後，可以作事件追蹤(event trace)的模擬。事件追蹤可以
明確的看出來誰產生了事件，誰接收了事件，何時產生事件，那個事件先發生…
…等等。接著再作一份事件流程圖(event flow diagram)，顯示哪個物件該產生
那些事件，該接收哪些事件等等。
狀態圖(state diagram)則很清楚的表示了事件的流程及對狀態的影響，以
下將教您如何畫圖。在狀態圖中，用節點(一個橢圓形)表示此物件的狀態
(state)，而箭頭旁則標明了事件名稱，在事件的流程圖上可加以標示「判斷」
布林值以決定事件的流向，在後面有張紅綠燈的狀態圖，在此扼要的加以說明。
這個號誌系統是個長「眼睛」的紅綠燈，藉由偵測在左彎車專用道上是否有車，
來決定是否要讓直行車先行或留一段時間給轉彎車走。你可以看得出來，例如說
南北向要彎紅燈時，會先判斷要不要先亮轉彎燈，如果不要，就直接跳到東西亮
線燈的狀態去。在此，那個判斷值便標明在事件的箭頭上，其餘依此類推。
2.3 動作(Action)與活動(Activity)
光在圖上標出事件、狀態及判定值還不太夠，通常伴隨事件之後應該會有一
項對應的動作 ( Action ) ，它在圖中的表示法是在事件敘述後加斜線”/”區
隔。事件的發生只是告知或確認狀態的改變，至於如何轉變狀態則和事件無關，
必須靠內部的活動 ( activity ) 來改變狀態。而這活動可能包括一連串的運作
( operation ) 。活動 ( activity ) 在圖中的表示方法是在節點中寫個
do:activity name。讀者或許感到筆者一直在強調狀態圖(state diagram)的畫
法。因為構圖表示一個程式十分的重要。前一章物件模型有圖，這章狀態模型也
有圖，下一章功能模型還有ＤＦＤ圖。由此可知圖表的重要性！讀者應該好好的
揣摩圖形的畫法。
第三章 功能模型(Functional Model)
功能模型 ( Functional Model )是OMT 三種基本模型中延用「傳統」的一
部分。功能模型用以描述系統中資料的流程，資料被哪些單元接受處理經由哪些
過程，但卻不深究資料真正是怎麼被計算的。功能模型有效的運用在編譯器 (
compilers ) 之類純粹處理資料的工作，而這些工作所處理的資料不易於被設計
成物件。不過在傳統的設計領域中，除去物件模型，程式一樣可以寫，只不過在
這裡以物件分析為首要觀點，功能模組只得屈身。與其它兩種模型並列了。
3.1 ＤＦＤ資料流程圖
資料流程圖的繪製是功能模型表示方法的核心。ＤＦＤ圖的畫法較前兩章圖
形的畫法都來得簡單，以下就各圖形元件來介紹。
3.1.1 處理單元(process)
我們以一個橢圓形的節點來表示一個「處理」。「處理」(process)用以接
受輸入資料，經過一特定工作方法，將輸入的資料轉換計算後輸出。
3.1.2 資料流(Data Flow)
資料流表示出處理與處理之間所傳遞的資料，在此我們以箭頭符號連接。在
某些例子中，一道資料流（我的意思是僅以一個箭頭符號來表示一道資料流）可
能包含許多資料，而我們或許需要分解其中各別的資料流，此時可以將它分流成
更細的資料流，流入目的「處理」單元。
3.1.3 控制流(control flow)
資料流(Data flow)只是單純的傳遞資料，而不傳送控制訊息。然而某些處
理(process)會需要控制旗標來決定它資料處理的方式，解決的方式並不是經由
資料流傳一個值給處理,在此我們我們另以控制流來解決這個問題。控制的性質
是布林(boolean)代數值，只有真偽兩種情況。基本上控制流應該屬於動態模型
(dynamic model)中的”事件”，但因為和資料處理有密不可分的關係，於是便
被包括進來了。控制流的畫法是以點虛線箭頭表示事件訊息。
3.1.4 資料儲存(data storage)單元
資料儲存單元被視為DFD圖中一個專門用以儲存資料的被動物件。資料儲存
單元的畫法是以二槓橫線表示它。
3.1.5 行事者(Actor)
Actor被用來標示資料流的端點，可能是起點，也可能是終點。畫法是以小
三角形來表示。Actor和資料儲存單元有幾分類似。但資料儲存單元是被動的，
而不會執行任何動作，但Actor卻依資料的指示作一些動作，例如產生資料或終
結資料的處理，因此有時也被稱為「終結者」(terminator)。
3.1.6 外界個體
我們用一個矩形來代表外界個體。外界個體是什麼意思呢？因為在ＤＦＤ圖
中總會有資料是由外界輸入進來，也會有資料傳送給外界。因此以外界個體來表
示系統輸入的起點及輸出終點。
3.2 物件、動態模型與功能模型的關係
功能模型描述了一個軟體模型真實地去作了哪些事，ＤＦＤ圖中的「處理」
(Process)單元可以對映到物件模型中的運作(operation)，而資料流則是物件內
的屬性。控制流(control flow)前面也說過是來自於動態模型。整體的來說，三
種模型並不是獨立存在的，而是互補的，只是說它們各自以不同的角度來分析軟
體。功能模型中資料的流程及處理的流程圖並不能表示出處理執行的順序，這點
必需靠動態模型來補足（還記得原因嗎？）。而處理與處理間的流程關係及對於
物件運作(operation)的主客關係。這裡主客關係的意思是：運作(operation)之
間的層次關係，主模組將它的任務切割交由底下的子模組處理。物件模型內的屬
性，也就是狀態的改變，以及運作是如何被引發，怎麼個執行法，都由動態模型
來表達。因此都於所有的軟體來說，三種模型都是基本而且必要的，只不過是重
要程度不同而已。稍後我們所討論的物件發展流程也是照著這三種模型來發展。
第四章 分析 (Analysis)
4.1 OMT的設計流程
OMT方法其實就是一種軟體工程發展法。在此體系中我們採取下列步驟來設
計軟體：
𣇈分析(analysis)
分析工作由了解問題定義開始，逐次建立物件、動態、及功能模型來描述軟
體定義域(software domain)，這件工作和真實世界有極大的關聯。
𥌓系統設計(System Design)
以物件模型(Object Model)為基礎，開始建立系統的架構，定義動態模型的
劇本，將分析真實世界的結果轉換成電腦世界中型態。
矅物件設計(Object Design)
如果說系統設計是承先啟後的的工作，那麼物件設計就是集其大成了。在本
步驟中，三種模型被我們仔細的修改，細部化，具體化，以至於最佳化，將
模型轉換成實際可行的方案，然後進行模組化，最後將結果交給下一步處理
。
𢣷實作(implementation)
實作就是將前面所得的結果轉成對映的程式碼。往後在此章節中，筆者將和
大家討論C++的應用。
4.2 分析
這部份的內容在前三章的內容及概念己經被打散進入各模型的介紹中了。我
們現在的工作就是把他們整合起來，並加強一些重點。
分析工作就是要了解問題的定義，因此第一步，整理關於軟體的描述，弄清
楚問題的細節，力求使定義明確而易瞭解，也就是說要由問題陳述(problem
statement)來分析軟體的結構。這工作的基本精神和傳統的設計方式是殊無二致
的。筆者曾在前期的拙作中解釋得很明白了。
物件模型的建構：首先把一個物件的結構包括屬性和運作行為列舉出來，找
出物件與物件間的關係。並且要將物件中和問題無關的屬性及運作刪除，同時也
要去除和問題的屬性及運作刪除，同時也要去除和問題無關的關係及鍵結。適當
的引用舊物件，或將同類的物件抽象化，取出共同的父類別來....。有一點需要
留心，最好要有說明文件來記錄物件的性質和運作的目的。相關的內容在第一章
中都說過了，請讀者自行參考。
動態模型表達出物件中事件運作的順序和狀態的改變。首先，你該準備一個
劇本，劇本的來源或許是積數十年的觀案所累積的規則。劇本的內容或許不是鉅
細靡遺，也可能和「連噓劇」一樣無聊，但它卻很重要。然後要找出那些是「事
件」，事件包括信號，輸入，中斷等等。同時要留心每個伴隨事件而生的動作
(action)，及其副作用。然後以劇本為根據作事件追蹤(event trace)，測試事
件發生的先後順序及各事件的目標物件(target object)。
使用者介面 ( User's interface ) 也該在此時期建立。使面者介面的設計
是最難估量的，因為你很難決定怎樣的介面才是最好用 ( easy use ) 和最友善
( user friendly ) 的，除非到真正設計完成後才能知道效果如何。然而，我們
不得不承認軟體是由程式邏輯的部份和使用者介面合起來的。尤其在今天，軟體
的好壞通常經由使用者介面判定。使用者介面的設計在目前而言並沒有一個很統
一的型式，但將來也很難有一致公認的標準。
關於分析功能模型 ( Functional model ) 方面，主要的工作就是建構ＤＦ
Ｄ圖。將資料的流向和處理程序標示出來，就如同前一章所講的一樣，然後本著
「逐步細緻化」的原則，將抽象的處理單元，再細分出它內部的ＤＦＤ圖，一真
重覆這個步驟，直到它們的結構基本到不能再基本為止。
第五章 系統設計(System Design)
系統設計是軟體設計週期中承先啟後的一環。在本階段中有一些首要的目標
，包含模組化、資源分配、系統結構規劃等等工作。
5.1 模組化
再一次要強調「逐步細緻化」的概念。概念上是將一個大系統切成小系統，
小系統再分成小小系統.....如此遞迴式的切分，可以分析出基本單位、指令碼
，所以一軟體可能是由幾個主系統，而主系統又由若干個小系統所組成的。我們
試著歸納主系統及子系統間的關係，有層疊(layer)及分割(partition)。
5.1.1 層疊(Layer)
具有層疊關係的從屬模組，其現象是；子模組提供父模組所需的功能，子模
組並不需知道父模組在做什麼，更不會呼叫上層模組。因此，層疊的構成是「垂
直」的相繫。層疊式的關係可以降低機器相依性(machine dependence),因為只
有最底層模組才需「實體化」，中層以上的模組所作的工作都可以是抽象的。因
此為了要適應新的環境，只要抽換底層的模組就可以了。
5.1.2 分割(partition)
分割表示說，模組和模組的連繫是水平方向的。模組間可以相互的呼叫。分
割及層疊結構通常都共存在系統中間可以相互的呼叫。分割及層疊結構通常都共
存在系統中，也沒有孰好孰壞的問題，依系統所需才重要。
5.2 管理資源(resource)
磁碟、螢幕顯示、記憶體、鍵盤、印表機等都是系統資源。管理系統資料的
工作大半都有作業系統把關。不過應用程式也不應任意讓程式內的次系統隨意使
用公共資源。最好的作法是這樣：設計對等於資源的把關者物件，使該物件代表
該資源，由此物件統籌此資源的管理。例如說你可以把某個檔案定義成一個物件
，定義一些運作.....。當然可能會對存取速度或效率有點影響，但那也是極少
的一點而己，但卻可以用一致的方式來管理資源。
第六章 物件設計(Object Design)
物件設計(Object Design)的工作是規劃工作的最後一環，在這個部份裡，
我們得把模型具體化，最佳化，才能實作。
6.1 演算法(Algorithms)設計
演算法的重要性是無可比擬的。一個好的演算法不但快，而且有效率。請看
這個方程式 f(x)=10*x^250-20*X^249+1求 f(2)=? 嗯，很簡單，把2代進去算，
然後一定會發生悲劇，因為250次方實在太大了，沒法算。可是寫成f(x) =
(10x-20)*x^249+1 不就很好算了嗎？這是一個數學演算法的例子。如何去選擇
一個適當的演算法呢？嚴格說來這點將牽涉到演算法分析，需要引用大量的數學
估算，恐怕得寫上一本很厚的書。不過就軟體工程的觀點來看就比較簡單而直觀
了。請各位把握一些要點：選擇那些公認而且沒有爭論的演算法，它們通常是有
效的。但如果你自己設計演算法，將一般性列入考慮。如果演算法不是要被用在
關鍵瓶頸上的，最好是易懂易改的。
為了實作演算法，也同時得選擇合適的資料結構。既然有靜態的資料結構和
動態的演算法，我們可以試著做一些內部類別(internal class)來應付實作演算
法。現在大部份的物件導向程式語言都附有資料結構的物件，可以減去重新設計
演算法的麻煩，真是設計師的福音。
6.2 關聯(association)的設計
我們好像很久都沒看到這個偉大的名詞了。筆者曾提及關聯的運用是很重要
的，但怎麼實作關聯呢？我們試著以關聯用途的方向來分析。
6.2.1 單向關聯(One Way Association)
好幾章前筆者曾以老師及同學類別的交互關係來說明關聯。如果單就「教導
」這關聯來看，純粹是單向性的由老師到學生，而沒有學生「教導」老師。單向
關聯的實作通常以指標達成。如果關聯是一對一(one-to-one)的，則用一個指標
就可以解決，但如果是一對多(one-to-mamy)，則可能要用一組指標，或一個指
標的表格。但如果這關係是有條件限制，則一定要用一個帶有權限值
(qualificiation)的表格來連接了。
6.2.2 雙向關聯 (Two-way association)
在一些情況下，雙向關聯是有必要的。如果去的方向使用率大於反向的使用
率，那麼和單向關聯一樣，用一個指標聯起來就足夠了，在需要用反向關係時，
以搜尋的方法來找到正向指標的來源物件。如果來去雙向使用頻率都差不多，那
麼便用雙指標。在複雜的情況中，例如具有條件的關係或是多對多的關聯之類的
運用便有須要將關聯做成一個物件。基本上，這物件也是一個表格。關於這些類
型的表格，可考慮以雜湊表(hash table)來實作。
6.2.3 關聯的最佳化(Optimization)
我們「物件模型」中所建的物件及其關聯可能是很完整而週密，而且符合現
實的。不過它可能太繁複了。為了傳送一個事件，可能要穿過數個物件，透過數
個關係(association)傳遞。就好像從台北到高雄，走三號省道，得經過近百個
城鎮和數不清的支線才能到達目的地，但如果經過高速公路，就可以直達高雄。
同樣的，在資料傳送頻率高的物件間，即使彼此沒有直接關聯，也可以考慮特別
建立一個關係(association)來達成最佳化資料傳送路徑的目的，以去除傳輸過程
所不需要的冗長步驟。
6.3 遺傳(Inheritance)的運用
物件導向的特點就是它具有遺傳性，我們希望軟體中的物件能夠儘可能地重
覆使用，繼承舊物件，以大量縮減軟體設計的時間及增高可信度。
物件中的一些運作(operation)可能和舊的物件或他同系統中類似的物件中
的運作有相近的功能，但其參數個數卻少了一些。就因為這樣，可能會導致無法
遺傳舊物件，這實在的很可惜。不過，何不替這種運作「補足」多餘的參數呢？
這真是一個好主意。藉由增加多餘的參數，它們的簽名和功能就可完全一致了！
例如說在單色繪圖系統上畫點，只需要座標的資料即可，但在彩色系統上卻得要
有顏色(color)的參數，如何達成共用呢？只好在單色畫點的函數中多加一個不
需要、可忽略的顏色參數。讓兩個原來並不相同的運作(operation)，變成簽名
(signature)相同，但內部方法(method)不同的同一個運作。
除了遺傳舊物件以外，新建的類別也可以想法子做「遺傳」。因為相類似的
類別都具有共同的運作及屬性。考慮將這些共同的運作和屬性抽出來成為一個共
同的超級類別。但基於各子類別具有差異性，則某些運作可能是抽象的，於是乎
這個父類別就成了抽象類別了。
這樣作有不少好處。第一：修改其共同的父類別就可以影響到所有的子物件
。第二：可以產生不同的子類別來適應不同的環境。對於前者，筆者認為很淺顯
，不需多討論，讀者應該可以了解；筆者要歌頌一下第二點。假如你的軟體公司
出售同一套軟體給許多有不同需求的客戶，你毋需大幅增刪你的程式，只要遺傳
新的子類別即可。其次，以一個繪圖系統的繪圖類別而言，為了適應不同的顯示
系統，可以遺傳適應不同機器的類別，在真正上機執行時，再依真實情況引用適
當的類別就可以了。
6.4 資訊隱藏(lnformation Hiding)
在前面章節中，幾乎沒提到資訊隱藏(lnformation Hiding),也就是物件的
封裝性(encapsulation)。封裝性和資料保全(security)不能混為一談，後者指
的是系統資料的保密和安全的可靠性，前者則具有軟體工程上的意義。資訊隱藏
的目的有二，第一：使運作(operation)有限度的存取資料成員，降低其引發的
副作用。也就是說，我們不希望運作會牽一髮而動全身，因此在修改運作的方法
(method)時，可預期的降低物件結構的影響。第二：迫使物件必須建立一個統一
的介面(interface)。透過介面來提取或改變物件屬性，可以有效地遏止類別遭
到意外的破壞。更重要的是，類別介面可以提高類別的抽象化程度，一個愈抽象
的類別對我們愈有利。要怎麼去決定類別中哪些屬性和行為該被隱藏呢？說實話
，筆者也考慮了很久。一個常見的看法是這樣的：僅將類別的界面顯露出來，而
將其它的元件都隱藏起來。而這又引發了一個問題：我們如何去設計一個好的介
面？筆者心目中好的介面是高度抽象的，而且與內部結構不相涉，能夠考慮到遺
傳後的子類別仍可適用父類別的介面，並且不需要任何增刪修改，但同時也必須
能周延地控制物件的動作。
6.5 類別模組化
傳統的軟體設計很重視模組化，物件導向軟體工程同樣也十分重視模組化，
模組和類別的意義並不相同。筆者認為模組的界定屬於「功能模型」的範疇中，
也就是說將有主客關係或是類似的運作模組化。但如何形成模組呢？模組間又存
在什麼關係呢？我們依舊以「緊密性」來判定模組內成員的關係，而以「關聯性
」來討論模組與模組之間的交互作用。這兩個性質一樣的可以被引用到類別的分
析。模組內若是緊密性低，可能意味著這模組還可以再被切分成更小的子模組。
同樣的，類別內若是緊密度低，那麼這個類別或許也是大而籠統的類別。模組之
間若關聯性過高，應該考慮模組的分割分式是否妥當。同樣的道理引用到類別的
分析上亦是如此。關於模組的緊密性及關聯性的詳細內容，請參考上期建青。
第七章 實作、語言
7.1 物件導向程式語言(Object Oriented Programming Language)
不可否認的，物件導向設計(OOD)和物件導向程式語言的相依程度極高，物
件導向設計的概念在七○年代就出現了，但卻是在八○年代物件導向程式語言發
展成熟之後才大放異彩。傳統的程式語言並非不能應用物件導向方法，只是很難
罷了，例如遺傳 (inheritance) 就很難實作，因此得依賴物件導向專用的程式
語言。但物件導向程式語言並非一夕所成的。從程式語言的發展歷史中，可以看
出一條脈絡來。如果按照一般對語言的分類方式，則有第一代到第四代之不同。
但筆者在此採取資料型態的觀點來看程式語言的演進，歸納出一些結果。上古的
程式語言，如組合語言，沒有今日整數、浮點數的資料表示法；中古的程式語言
如 FORTRAN、BASIC 等有基本的資料型態，如整數、字串型態等等；近代的程式
語言如Ｃ或Pascal，則具備有「集合」式的資料表示法，而新一代的程式語言如
Smalltalk 及C++則具有類別封裝的表示方式。
一個理想的物件導向程式語言(OOPL)能夠確實的將問題的定義域(Domain)映射
到程式中。換句話說，在前面數章所描述的各種物件特性都應該被包含進OOPL。
很不幸地，各種語言都不能很完備地包含那些特性。例如說：多重繼承
(multiple inheritance)並不存在於較舊的OOPL中，例如C++ 1.2等。而對於多重
繼承(multiple inheritance)解決模稜兩可 (ambiguity) 的方法也不盡相同。
此外，我們希望程式語言能夠提供一套標準的類別程式庫(Class library)，就
像Smalltalk一樣，設計師可以自由運用上百個已定義的物件。而C++，頂多以
iostream的I/O物件充數。各家物件導向程式語言對於物件導向的詮釋都有所不
同，導致於它們在物件導向理論中的細節看法都不一樣，這點讀者不可不注意。
此外目前OOPL產生新類別的方法都是在程式寫作時在程式碼中載明遺傳方式
。將來則可能會出現在執行時期(run-time)可產生物件的程式語言。屆時相當多
的問題也可一併解決。
第八章 關於C++
雖然Smalltalk的歷史、名氣可能都來得比C++大，但C++的適用性較強。對
於C++的介紹真是多如過江之鯽，諸有興趣的讀者自行參考，在本章中將探討C++
在物件設計中的應用。
8.1 「類別」Vs「類別」
不要以為這節的名稱搞錯了。C++中的類別與物件模型 ( object model )中
的類別有啥差異呢？就抽象化的層次而言，兩者的意義是相等的。就實際情況來
說，C++的類別的成員存取屬性可分為公共(public)、保護(protected)及私有
(private)三區。在不討論遺傳的情形下，保護(protected)及私有(private)屬
均性是類別中被隱藏的部分。而只用於遺傳時，public及protected方能遺傳給
子類別。為什麼要這樣定義呢？這是個很有趣的問題。根據筆者的研究，
private成員事實上一樣也會被遺傳給子類別，但不能被子類別的成員存取。這
屬於一種隱性的遺傳(implicit inheritance ) ，但從另一個角度來看，private
成員可以被當成該類別暫時性成員，可能是為了要完成某個運作(operation)內
的方法(method)，而需要的內部類別(internal class)或輔助的子模組。這些成
員的遺傳不具意義，也就成了隱性遺傳。
8.2 凌越(overriding)與多重載入(overloading)
凌越及多重載入的性質恰恰相反。凌越在前面的章節就談過了，意思是子類
別的運作取代父類別運作內部的方法，而更換成適合子類別的新方法。而多重載
入(overloading)又被稱為「名稱的重覆使用」。產生的情況是這樣的：函數ABC
被多重載入成兩個函數ABC(int)及ABC(char)，也就是說名稱是相同的，但其參
數不一樣，導致簽名(signature)不同。在呼叫ABC函數時，若呼叫的型式是
ABC('A')，參數是字元A，就和ABC(char)的簽名相同，此時便適用ABC(char)這
個函數。不只是函數，連運算符號也可多重載入。複數的運算就是一個明顯的例
子，實數的加法是被加數和加數相加，而複數相加卻是實部加實部，虛部加虛部
，但卻可以共同使用加號為代表不同的加法運算。
8.3 虛擬函數(virtual functions)與抽象類別(abstract class)
關於抽象類別(abstract class)在「物件設計」一節中，曾經提及它的性質
，在這節中將看看C++是如何表示一個抽象類別。
虛擬函數的存在為的是要表明該函數的執行內容現在無法定義，或現在已定
義，將來卻可能會被改變。在物件模型一章中，曾提過一個幾何繪圖的例子。所
有的圖形，如圖、線．．．．等基本圖樣都是由一個最原始的父類別，也就是「
圖形」類別。在「圖」類別中有項運作(operation)叫「畫圖(draw)」這項目。
但各個圖樣的畫法卻有差距，因此「畫圖」這項運作在「圖形」類別中存在，但
卻沒法子真正的動起來，只有在遺傳子代， 也就是那些圖樣類別中才能定義，
因此這個「畫圖」函數就是個虛擬函數。另外一種情形是這樣的：假定有個「四
邊形」類別，定義它「繪圖(draw)」這項運作當然沒問題。現在假設遺傳出「正
方形」這個類別，我們可以重新定義「繪圖」這項運作，因此這個繪圖函數又是
一種虛擬函數。針對於前者的情形，必須把該函數設為「純函數」(pure
function)，寫法是virtual ABC (void)=0；而具有至少有一個這算型純函數的
類別便是抽象類別。但後者那種情況的類別便不算是抽象類別，因為抽象類別無
法產生案例(instance)，只能用來遺傳出子類別。
8.4 模板(Template)
模板(template)是AT&T C++ 2.1新定義的功能。它和物件導向的理論倒是沒
多大關係，不過在減少重複編碼上卻省去設計師不少力氣。
請看這個例子：堆疊(Stack)是一種先進後出(FILO)的資料結構。理想中的
堆疊沒有容量限制，另外，它不限定被推入堆疊的資料之型態，是整數，浮點數
或其它。但在實際狀況下又是一回事。在2.0以前的C++中，你可以多重載入push
（推入）這個運作，但寫起來很囉嗦，因為推入的方式都一樣，但只因參數型態
不同，就要重覆寫很多極類似的多重載入函數。而現在用template，就可以由編
譯器自動產生類似的函數，如表8.1所示。因此，事實上也如此，編譯器只是把
這個模板命令視為一個展開巨集(MACRO)的指令而已。
8.5 預設參數值
預設參數值是C++ 新增加的功能。前面曾提過單色與彩色繪圖系統中畫點運
作的一致化時所作的改變。例如說：point(int x, int y, int color=1)這個繪
圖函數的簽名。假如程式拿呼叫單色繪點的方法來呼叫這個函數，它可能只傳入
座標值而已，但它可能不知道系統正處於彩色模示下，此時顏色color參數的預
設值便派上用場了。此外，有預設值的參數最好被放在參數列的最後頭，這樣預
設參數值才能發揮正確的效用。
8.6 雜要
關於C++與物件導向設計較有關的重點，就介紹到這邊。坊間關於C++的書不
少，請讀者自行參考。
不過，還是有些關係C++的有趣問題想提出來同諸君討論討論。在一般情況
下，指派(assign)變數值是很簡單的事，例如X=3等等，但類別的指派呢？一個
非常基本的作法是：重覆載入”＝”這個運算子，當A=B時便將B案例中所有的成
員一個一個搬到A案例中。編譯器又是怎麼作呢？在C++ 1.2中，電腦是以一個一
個byte拷貝過去，而C++ 2.0則是採前面所提，遂次拷貝成員的方式。換句話說
，編譯器「偷偷地」替我們多重載入了”＝”這個運算子。1.2及2.0的作法各有
不同，為什麼2.0要改呢？這個問題留給讀者自行討論。
另一個有趣的問題是關於編譯器本身。C++最早沒有獨立編譯器。要編譯C++
必須先用一個「前端處理器」將C++的程式碼轉換成Ｃ的原始碼，再交由Ｃ的編
譯器進行編譯的工作。造成這個有趣現象的原因是因為C++本身可被視為Ｃ語言
的巨集指令(MACRO)增強版。例如前面所提到的template就是一個明顯的例子。
又以轉譯class來講，前端處理器也只是將各類別的案例轉成「唯一名稱」的結
構(struct)而已。有興趣的讀者可以自己設計一個轉譯器，應該不會太難。
第九章 程式寫作的風格
一組好的程式編碼風格，對程式效率的影響雖然很小，但是在往後除錯，以
及維護階段來說卻很重要。因為程式碼不僅僅只是要給電腦執行而已，同是也必
需是可讀的、易於了解的。例如說註解應該寫明白，程式碼縮格、變數命名等等
。這些原則相信不論是任何教科書或是筆者以前的文章中都曾不只一次的強調過
。在本章中筆者不要重彈這些高調，筆者想介紹一個良好的範例。這個範例的來
源是Borland公司附加在TURBO C++/BORLAND C++中的CLASSLIB，類別程式庫。為
什麼要以CLASSLIB為例呢？筆者並沒有商業意圖，理由是因為它有明確的注解、
正確而良好的運用遺傳等等特質。這套程式庫的功能是提供一套標準化的資料結
構類別給予設計師，其中包含STACK堆疊、QUEUE佇列、ARRAY陣列、HASHTABLE雜
湊表、STRING字串......等等類別。以下舉其中的字串類別來做我們的範例，希望
各位能由以下的說明中，學習一套好的物件設計的風格。
9.1 String 類別的結構
雖然String字串類別不是一個資料結構實作的類別，而只是一個補強的資料
型態（因為C++ 並不內建字串的型別），但比起其它類別好講易懂，所以筆者挑
它出來討論。String類別本身由Sortable類別遺傳而來，Sortable所具的特性且
避不討論（因為Sortable也有它自己的功用）。String的軟體界面很符合要求，
茲分述如下：
class String: public Sortable
{
public: // 公共區，也就是String類別的界面部份
String( const char * );
String( const String& );
// 多重載入建構者
virtual ~String();
virtual int isEqual( const Object& ) const;
virtual int isLessThan( const Object& ) const;
// 以上這兩個函數是用來比較兩字串大小或相同
virtual classType isA() const;
virtual char *nameOf() const;
virtual hashValueType hashValue() const;
virtual void printOn( ostream& ) const;
String& operator =( const String& );
operator const char *() const;
private: // 私有區，String類別中受保護、不透明的內部資料
sizeType len;
// 紀錄字串的長度
char *theString;
// 字串的內容被存在這個字元指標中
};
表9.1 String類別的宣告內容列表
9.1.1 建構與破壞成員 (Constructor and Destructor)
String的建構成員是多重載入的，因為在String的案例產生時，也就是一個
字串變數開始其生命週期時，應該要指定一個文數字串給這個案例。各位可由此
瞭解一點，就是說不需要特別寫一個專門用來起始物件的成員函數。例如在此處
String類別的正確用法是：
String NewString ( "Hello C++" );
而不必要用兩階段的啟始化。這樣就失去建構者的意義了，就像：
String NewString ;
NewString.init ( "Hello C++" ); // String.init 是筆者假設的成員函數
那麼，為什麼建構者是兩個多重載入函數呢？在上面的說明中，String案例的啟
始都是直接指派一個字串給NewString物件，這是最直觀的用法，但在另外一種
情況中我們也會指派一個已經存在的String案例給它，這便需要用另一個建構者
了。那除構者有什麼用呢？話說建構者會向系統要求一塊空間來放置字串，而在
這個物件死掉的時後，便得要還回給系統，當然如果你自己設計一個相對於剛才
假定的init函數也可以，但讓物件自動收拾不是更好嗎？從這一小節我們可以瞭
解到當你設計一個物件時，應該善用建構者與除構者。
9.1.2 封閉的內部結構與開放的界面
String內部到底是怎樣子的呢？在私有區裡面儲存了兩個變數，一個整數變
數描述字串資料的長度，另一個字元指標則指向建構者所分配來儲存字串內容的
記憶空間。或許你覺得奇怪了，如果把字串資料放在私有區內，那我們不就無法
存取字串內容了嗎？是的，的確如此，但請看String的公共區，也就是它界面的
部份，有兩個主要的成員，一個是多重載入運算子"="，另一個是成員函數
printON()，多重載入運算子"="允許我們指派另一個字串案例的值，就像是A=B
這種方式，這樣便得以更改字串的內容；printON()成員函數則可以將字串的內
容輸出到指定的資料流(stream)上，藉此就可以取得字串的內容。那為什麼不把
字元指標直接放在公共區呢？這就是本小節討論的重點。在三章之前曾提到過資
訊隱藏的問題，在此有了一個很好的範例來詮釋。因為我們希望物件已外的的函
數或是程序不能夠隨意的改變物件的屬性，因為屬性若沒有作兩好的保護，是很
容易修改的。在String中有個變數是紀錄字串長度用的，試想只是改便字串內容
，而長度資訊沒有隨著更新的話，是不是會造成意外呢？而且很明顯的，成員函
數不容易被破壞，而且透過函數運作來存取函數也可以同時箝制資料範圍。但還
有個多重載入的鑄型(cast)運算子是用來幹嘛的呢？這是用來將String的物件指
標轉換成字元指標，而其實它所轉換出的字元指標實際上是指向String類別中存
放字元資料的儲存空間，或許你會說：好啊，那我就可以自己直接修改字串內容
了，是的你可以，不過它在註解中卻聲明說最好不要藉此修改字串內容，因此這
項功能的本意僅只供提取資料用的。當然，String的介面可能還不是很齊全，但
這也提供了設計師一個很大的發展空間。
9.2 註解的使用
CLASSLIB註解的使用是我見過最週延的一種。它藉由註解將程式很明顯的區
隔開來。它使用註解的規格如下所示，很值得讀者參考：
標頭檔部份(header files)
// Content ---------------------------------------------
// 在這個部份描述這個模組內含有那些函數、類別、變數、結構等等
// Description
// 這個模組的主要功能概述
// End --------------------------------------------------
// Interface Dependencies ------------------------------
// 引進(#include)其它模組的原始碼
// End Interface Dependencies ---------------------------
// Implementation Dependencies -------------------------
// 引進外界模組定義的函數原型，就像#include <stdio.h>之類
// End Implementation Dependencies ----------------------
// Class // 定義使用者資料型態，如class、struct、union.....
// Description -----------------------------------------
// 這部份緊接在型態定義完畢後，詳細說明這個型態的用法，功能。
// 並且把每個成員函數、成員變數的意義用法說明白。
// End --------------------------------------------------
在程式碼的部份
// Function // 或是 member function, constructor等等
// 以下定義函數原型
.......
// Summary ---------------------------------------------
// 函數功能的簡介
// Parameters
// 參數的意義
// Return Value
// 返回值的意義
// Functional Description
// 函數功能運作詳述
// Remarks
// 追加的附註，警告等等資訊
// End --------------------------------------------------
以下就是函數主體了，當然內容也該要有註解
..........
// End Function // 函數結束，以下接續其它函數，也是同樣的格式
這麼詳盡的註解有什麼用呢？在CLASSLIB的說明文件就很大膽的說，關於各物件
的用法看原始碼就會懂了。這夠明顯了吧，一個易讀的程式碼本身就是一份很好
的說明文件，尤其在這種極端明白的註解下。
展望與結語
假定你是位程式設計師，物件導向的軟體設計可以替你省去不少工夫，帶來
更多便利。Clipper 5.0中也增加了物件導向的功能。記得在它的廣告中說：
Clipper適合你的右腦。因為有人認為人的左腦掌管理性的思考，偏重於邏輯，
而右腦主掌人的創造力，因此藝術家的右腦往往來得發達，傳統的設計方式被那
些支持物件導向論的人抨擊為冷漠而不近人情。但就以筆者而言，用傳統方法寫
程式好幾年了，中毒也很深了，倒是無所謂。但是使用者呢？設計師在自己獲得
方便之餘是否也曾想過建立一個物件導向化的使用方法或使用者介面呢？
物件導向程式語言也並未發展完備。執行時期的動態繫結、自動衍生物件等
等功能都可能陸續出現。程式碼的最佳化也是努力的目標，因為與傳統語言比較
，OOPL的效率明顯的偏低，顯然在最佳化方面還有相當大的努力空間。此外，我
們也需要 CASE(Computer-Aided Software Engineering)來輔助我們作物件導向
的設計工作，很幸運的，這些都正在發展中。
撰寫這篇文章帶給筆者很大的壓力。因為眼見許多人對物件導向的看法多有
所偏頗，整個大環境的發展也很畸型，大部份人都被程式語言牽著鼻子走，但卻
很少討論物件導向軟體工程論。捨方法論而就OOPL，真是捨本遂末的行為，且此
弊不見於今日，必為明日之患！智者怎能不杜漸防微呢？筆者預測未來五到十年
間，物件導向技術將會發展成熟，而必將在二十一世紀成為主流。
在此感謝鄭泰銘兄在我那潦草的稿紙中挑錯。還有李瑞老師及資訊社諸隸也
在此一併致謝。
參考資料
1. Rumbaugh, Blaha, Premerlani, Eddy, Lorensen. " Object-Oriented
Modeling And Design ". N.J.: Prentice Hall, 1991
2. Bjarne Stroustrup. " The C++ Programming Language 2nd Edition ".
Reading, Mass.: Addison-Wesley, 1991
3. 軟體工程 第二版, R.S. Pressman, 陳澤風譯, 松崗
4. C++ 程式設計入門, 黃美玉譯, 格致
5. Turbo C++ V1.0 CLASSLIB.DOC, Borland International.
Borland C++、Turbo C++、Quattro Pro是Borland公司的註冊商標
dBASE III、dBASE IV是安信達公司的註冊商標
Objective-C是Stepstone公司的註冊商標
Smalltalk-80是ParcPlace System的註冊商標
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ If Winter comes, can Spring be far behind? - P.B. Shelley.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
--
* 國立中山大學 West BBS * From: 140.117.198.143 [已通過認證]
|