閒聊設計模式和類 (轉)

閒聊設計模式和類 (轉)[@more@]

以下純屬閒聊,不過仁者見仁,智者見智,希望給大家一個思考.

2001-04-08 22:38:06 夢郎
必須更改,
我們第一必須保證資料庫是符合的計算要求.否則無法判斷錯誤在哪

2001-04-08 22:42:01 Leeseon
那就先這樣吧，
以後我建議把半成品單獨做成一個類，來封裝它的邏輯會好一些

2001-04-08 22:41:27 夢郎
以後很可能在程式中不分半成品還是材料,操作一致.把半成品單獨列出來,可以考慮

2001-04-08 22:45:22 Leeseon
做成從同一個介面類派生，用同樣的介面來實現我想會更好

2001-04-08 22:43:40 夢郎
你還記得不,最早的類設計中有綜合材的類

2001-04-08 22:47:13 Leeseon
記得，我想用相同的方法也可以處理的，只是介面的實現不同而已

2001-04-08 22:44:54 夢郎
對

2001-04-08 22:50:20 Leeseon
正在看的新寫的一篇文章，
不過好象你舉的那個例子沒有必要：
因為那種情況應該是你先要求好了基類，然後只要求別人做完子類的實現部分就好了，這種情況應該是在設計時就要求好的，而不是讓別人自己來設計完成的。這樣才可能更好的重用

2001-04-08 22:50:07 夢郎
這種方式就是設計中講到的如果採用派生方式的弊端就是:
必須瞭解他的父類,或者說父類必須公開

2001-04-08 22:53:44 Leeseon
那也沒有什麼，最多是從一個純虛類繼承

2001-04-08 22:52:36 夢郎
我對類的好處十分欣賞,但對類多層派生後的複雜度感到有些畏懼.

2001-04-08 22:56:26 Leeseon
還好吧，MFC中派生的就比較深，但是依然是最穩定的類庫

2001-04-08 22:55:47 夢郎
我自認為自己很難寫出如此簡潔而又實用的類庫來.
這是需要大公司的實力才能做的.
C++builder也許小了點,其派生的類庫中也免不了出這樣那樣的不便.

2001-04-08 23:01:27 Leeseon
但是我們也不寫類庫，而且層次也不算深，我覺得還是可以的

2001-04-08 23:02:10 Leeseon
而且以後使用STL會比較方便的

2001-04-08 23:02:20 夢郎
STL是前人總結的精華.我們應該使用,而且它也是c++的標準類庫了.

2001-04-08 22:58:58 夢郎
COM與類有很多不同.
曾經有人說VB就是因為它是完全基於COM技術做的,所以支援真正的類技術很差

2001-04-08 23:01:23 夢郎
如果針對各種不同的應用和不同的類操作.其複雜程度我是無法估計的.
比如,我們現在的預算類.採用及時計算後,類的派生必須注意父類做過什麼工作.如果中間有些特殊的處理,在子類也必須瞭解和處理.
繼承會把複雜度繼承下來的.
如果採用模式的思路,繼承會好一些

2001-04-08 23:04:40 Leeseon
COM中主要是用聚合，但聚合也需要類來支援，只是把類的粒度做得比較細小了，沒有很大的類。

2001-04-08 23:05:52 夢郎
不可否認,完全採用類的繼承機制,對於應用擴充套件性要好得多.
這是相對的,如果有足夠的靈活,肯定有不少的複雜度增加

2001-04-08 23:09:53 Leeseon
類與聚合與委託都很好，但是不能只用任何一個，最好是在該用的地方使用就好了

2001-04-08 23:10:53 夢郎
對,根據你的具體的性質來定.
如果預算類我採用那套介面來做,難度會很大.
但是,動態表格的設計與外部的資料的連結,就可以使用這種介面.外部的設計就會不受更多的限制.它開始完全不考慮如何去和表格設計連結,以及資料形式或類形式是什麼.
因為這種應用的介面非常規範,在這種情況下我寧可用函式介面要暢快得多

2001-04-08 23:11:55 Leeseon
你放在主頁上的Language有問題，不能開啟工程

2001-04-08 23:14:44 Leeseon
而且介面上都有一些問題，我看還是不要將它先放在上面比較好，還是對整個程式再調整一下再放上去會比較好，否則我怕會影響以後別人的積極性

2001-04-08 23:11:58 夢郎
是的,路徑等問題,我已經改了,但還沒有上載.

2001-04-08 23:13:12 夢郎
會的.不過已經有很長時間了,我必須放上去.
幸好現在到我這的人不多.
我放上去只是起一種訊號的作用

2001-04-08 23:16:25 Leeseon
對你剛才的那個問題，最好的方法是將結構與演算法與容器做為三種模式分開來設計，這個設計模式上有相應的說明

2001-04-08 23:17:46 夢郎
結構演算法容器是程式的基本模式.
我們在容器模式上只是剛剛介入.
把這三種結合起來使用是非常不錯的思路.不過他們之間應該有很好的一條物件脈絡,這是基準線

2001-04-08 23:22:14 Leeseon
STL是一個最好的例子，它就已經很好的解決了這中間的三個模式的連線問題，是用的visiter！

2001-04-08 23:20:59 夢郎
在我買的那本演算法書中講到的訪問者,包括訪問者還有資料所有權等,不知道是不是你所說的visitor

2001-04-08 23:24:08 Leeseon
就是它

2001-04-08 23:25:38 Leeseon
我現在覺得《設計模式》要是能早一些年，翻譯過來就好了。
現在大家的工程水平應該比現在要好多了

2001-04-08 23:23:46 夢郎
你發現了沒有,這些模式其實僅僅做的是一種通用模式的管理.
在我們的編輯器中,思路也是這樣,是一種通用編輯模式的管理,至於資料,外部另外掛接.
不過設計模式講述的是對所有程式應用設計的一種通用基層模式的方法論

2001-04-08 23:25:38 夢郎
不過,設計模式在全世界也是最近才被廣大的程式設計師採用到實際程式設計中.
原因很簡單:程式的規模越來越大,重複的工作是非常明顯的.

2001-04-08 23:28:57 Leeseon
不只吧，我覺得比較象STL中的方法論，如果不是看了它，我是沒有辦法理解的

2001-04-08 23:29:51 夢郎
我指的是廣大的程式設計師包括廣大的公司.

2001-04-08 23:33:14 Leeseon
也許吧！

2001-04-08 23:31:41 夢郎
在論壇中有人調查過,如同軟體工程學一樣,知道非常好,但就是在應用中或中途放棄或不被採納

2001-04-08 23:35:45 Leeseon
我覺得可能是管理上的問題，這些模式，還是很實用的，很多我們自己也發現並做了，比如command,還有其它幾種模式.

2001-04-08 23:34:00 夢郎
可是,我們付出的代價一般公司是不會接受的.這就是原因

2001-04-08 23:38:26 Leeseon
我覺得代價以後會漸漸的不成問題了，以後最需要的還是可複用性與可維護的問題

2001-04-08 23:39:41 夢郎
我一直在思索這樣一個問題:當我們真的抽象出最具複用性的模式程式時(指什麼應用都可以用它),可能會發現,這些模式都是非常小非常簡單的模組.當我們使用他的時候,發現我們會在海洋中找最適合此時此刻使用的模式模組.
所以得出結論,複用性最好的就是三種語法結構語句.
let, for, if

2001-04-08 23:43:03 Leeseon
呵呵，經典！
不過可能是0101010

2001-04-08 23:41:04 夢郎
我們還做什麼呀!
回家種田都比這強.
呵呵

2001-04-08 23:45:49 Leeseon
說不定以後種田也要用模式那就玩完了

2001-04-08 23:44:18 夢郎
呵呵
今天出現軟體界的新概念:模式田

2001-04-08 23:47:16 Leeseon
呵呵

2001-04-08 23:47:21 夢郎
你可以想像,預算中這麼多細節工作能夠採用哪種模式?
我們只能站在山頭上往下看:一行行,一片片的方方正正的稻田.這才是我們要使用模式的地方.
否則,每塊泥土都要模式為方方正正的,豈不連種田都沒得做了

2001-04-08 23:51:29 Leeseon
沒有仔細考慮過，不過我剛才所想的那三種模式，也是昨天突然想到的

2001-04-08 23:52:44 夢郎
我們可以歸納和抽象預算中的程式要求,來設計模式.但模式最大的不足就是去套模式,先有棺材再選死人的做法.
不過那本確實是前人總結的精華,程式設計師不得不看一看,至少是應該開開竅,懂得現實世界有許多共同點可尋,而且可以設計得很巧妙.

2001-04-08 23:56:09 Leeseon
應該吧

2001-04-08 23:57:28 夢郎
好了,模式倒成了今天的主要話題.
關於模式,就像程式設計序一樣,有得推敲.不過,我和老楊已經打算在這個做完後,開始編寫一些認為很有用的模式程式,最後給一個類庫.
不知道現在老楊還有沒有這個打算?問問他
......................................