※ 引述《renderer.bbs@ptt.cc (rendering)》之銘言：
> OO 應該分 OOA OOD 與 OO Language
> 用 C 來實作 OOA OOD 並沒有什麼不可以的
> gsj 大大呀
> 您到底是反對 OOD 還是 OO Language
> 這點要分清楚
> 為物件(struct)畫關連圖已慢慢踏入 OOD 的層次 ...
不管這些名詞的內涵是什麼，我可以很清楚的直指
我反對的就是將Function與 Data 搞在一起，也就是Class這種東西
它在實體世界找不到與之對稱性的東西，也不符合結構性的邏輯
而且會破壞SA的規則性，將它放入系統中是混亂的開始
其實循序化的程式也在處理物件，也有物件的議題
只是這個所謂 "物件" 是指 "Struct" ，而不是Class
"物件導向" 這個名詞我已經不敢用了，以免造成混淆
Struct 其實就是一個參數包，至於它與實體世界的關連，它可以類比為
1.實物代卡，例如身份證：代表自然人，上面有一些參數欄來說明這個自然人的特性
如姓名、出身年月日、性別、住址等，程式的寫法為：
Struct 身份證 {
Char[6] 姓名;
Char[6] 出生年月日;
Bool 性別;
Char[100] 住址;
.....
}
2.隊卡：例如棒球隊
Struct 棒球隊{
function* 投手姓名;
function* 補手姓名;
function* 一壘手姓名;
function* 二壘手姓名;
......
}
3.通信卡：例如TCP/IP的封包
4.命令代表卡：例如去泡沫紅茶店，他們會給你一張Menu讓你去勾選
可以寫成
Struct 點餐單{
int 珍珠奶茶點取數量;
int 百香綠茶點取數量;
......
} 餐單*
如果有一天我去泡沫紅茶，然後點飲料，這個動作可以映射成以下的程式
飲料* Waitor(餐單*);
void (飲料*);
main()
{
[go to a shop]
餐單* 餐單A;
Struct 點餐單 我的餐單;/取得一張空白餐單/
餐單A = &我的餐單
餐單A->珍珠奶茶點取數量=1; /填寫餐單/
飲料= Waitor(餐單A); /將餐單交給服務生並取得飲料/
喝(飲料);
}
除了這些，還有很多例子，只要是自然界的東西、程序皆可類比
它是系統分析的基礎與利器
--
Ξ Origin: 中興大學天樞資訊網 <bbs.nchu.edu.tw>
Ξ From : 220-139-8-127.dynamic.hinet.net