重複問一個問題
鹹酥雞beta v1.0
以前已經問過,但是都沒有人鳥我,所以再請教大家:
問題是 : 既然Borland C++ Builder 已經出了,
編譯出來的程式已經可以很快了,
那麼,學習 MFC or OWL豈不是沒有用了嗎?
但是這些產品依然存在,是不是有些方面用
RAD仍然做不到?
對於MFC or OWL沒有說徹底的了解,因此希望有人
能夠解答這個問題,謝謝!
--
【 成大工程科學‧bbs.es.ncku.edu.tw 】● 使用者來自: 168.95.29.213 ●
visualge
【 在 moli...@bbs.es.ncku.edu.tw (鹹酥雞beta v1.0) 的大作中提到: 】
: 以前已經問過,但是都沒有人鳥我,所以再請教大家:
: 問題是 : 既然Borland C++ Builder 已經出了,
: 編譯出來的程式已經可以很快了,
: 那麼,學習 MFC or OWL豈不是沒有用了嗎?
: 但是這些產品依然存在,是不是有些方面用
: RAD仍然做不到?
: 對於MFC or OWL沒有說徹底的了解,因此希望有人
: 能夠解答這個問題,謝謝!
這個問題問的很好，用 Borland C++ Builder 或 Delphi 來寫程式，的確很方便。
因為兩者以物件導向的術語來說，是以 Component為中心的設計方式，不像
MFC 或 OWL 是以 Framework 為中心的。
如果說 Borland C++ Builder 出來之後，MFC 或 OWL 將會被逃汰，那到未必。
就 MFC、Visual C++ 而言，若要學會 Microsoft 的先進的技術，
如 OLE、ActiveX，…等，用 MFC 來學是最適合不過了。主要是因為 MFC 是以
Framework 為中心的設計方式，不像 Component，Framework適合將複雜的觀念，
用物件導向的方式，將它有系統的組織化，故對於學習者而言，非常方便。如我最
近學習 OLE Control，我翻了很多本書，都還不知道如何寫 OLE Control，直到我
用了 Visual C++ 的 MFC 與 它的 Wizard，並配合 其 Help，很快就可以把程式給寫
好了，並且也大概知道程式的架構，這就是 Framework的好處。
對於 OWL 而言，雖然與 MFC 相比，OWL 44是非常物件導向化的 Framework，但就
時效上來說，OWL 支援新技術的速度，永遠比不 MFC，因為 OWL 是非 Microsoft 的
，雖然與 OWL 相比 MFC 的架構設計的不太好，但不可穢言的，MFC是學習
Microsoft新技術的最好學習工具。
對於 Builder 而言，或許比較適合設計大型的應用程式，而不必在乎
內部的運作吧！不知您認為如何呢？
--
[m [1;31m※ 來源:‧神秘之旅 bbs.ice.cycu.edu.tw‧[FROM: 140.135.11.93] [m
鹹酥雞beta v1.0
: 這個問題問的很好，用 Borland C++ Builder 或 Delphi 來寫程式，的確很方�: 因為兩者以物件導向的術語來說，是以 Component為中心的設計方式，不像
: MFC 或 OWL 是以 Framework 為中心的。
: 如果說 Borland C++ Builder 出來之後，MFC 或 OWL 將會被逃汰，那到未必。
: 就 MFC、Visual C++ 而言，若要學會 Microsoft 的先進的技術，
: 如 OLE、ActiveX，…等，用 MFC 來學是最適合不過了。主要是因為 MFC 是以
: Framework 為中心的設計方式，不像 Component，Framework適合將複雜的觀念，
: 用物件導向的方式，將它有系統的組織化，故對於學習者而言，非常方便。如我最
: 近學習 OLE Control，我翻了很多本書，都還不知道如何寫 OLE Control，直到我
您指的應該算是"元件設計"這個方面吧..
可是這些OCX將來的VB5.0 , VFP5.0 ....Delphi97 等,
好像都可以自己產生了,用它們來開發不是比MFC or OWL還要快嗎?
: 對於 OWL 而言，雖然與 MFC 相比，OWL 44是非常物件導向化的 Framework，但
: 時效上來說，OWL 支援新技術的速度，永遠比不 MFC，因為 OWL 是非 Microsoft 的
: ，雖然與 OWL 相比 MFC 的架構設計的不太好，但不可穢言的，MFC是學習
: Microsoft新技術的最好學習工具。
: 對於 Builder 而言，或許比較適合設計大型的應用程式，而不必在乎
: 內部的運作吧！不知您認為如何呢？
可是這麼一來,MFC or OWL將被淘汰的原因就更明確了呀!
設計大型的應用程式可以更快,那小型的也會非常快...
但是,為何Borland還宣佈OWL 和 BCB將來是兩條不同的
主力生產線呢?
個人的感覺是,大概是低階的控制(例如VXD,device driver大概都要
MFC or OWL才能生產吧)...我並沒有寫過VxD,只是猜測!
--
【 成大工程科學‧bbs.es.ncku.edu.tw 】● 使用者來自: 168.95.29.212 ●
居家型小男孩
: 您指的應該算是"元件設計"這個方面吧..
: 可是這些OCX將來的VB5.0 , VFP5.0 ....Delphi97 等,
: 好像都可以自己產生了,用它們來開發不是比MFC or OWL還要快嗎?
: 設計大型的應用程式可以更快,那小型的也會非常快...
: 但是,為何Borland還宣佈OWL 和 BCB將來是兩條不同的
: 主力生產線呢?
: 個人的感覺是,大概是低階的控制(例如VXD,device driver大概都要
: MFC or OWL才能生產吧)...我並沒有寫過VxD,只是猜測!
對於 database 型態的,以rad開發是較快的.
可是對於一些較細部或是一般不常見的功能可能就要透過 framework
甚至 sdk 來完成.
整體而言,rad 是開發中小型程式的好幫手
而mfc 或 owl則適合大型程式開發.當一個程式過大時
framework 與 rad 的執行效益與容量會有差別
至於 vxd 或是 device driver 則是透過組語完成
這又是另外的話題了
--
生為程式人，
死為程式魂.....
--
※ Origin: 元智工學院風之塔 BBS <bbs.yzit.edu.tw> ◆ From: [140.138.251.165]
Roland
==> 在 DeathVa...@bbs.yzit.edu.tw (居家型小男孩) 的文章中提到:
> : 您指的應該算是"元件設計"這個方面吧..
> : 可是這些OCX將來的VB5.0 , VFP5.0 ....Delphi97 等,
> : 好像都可以自己產生了,用它們來開發不是比MFC or OWL還要快嗎?
> : 可是這麼一來,MFC or OWL將被淘汰的原因就更明確了呀!
> : 設計大型的應用程式可以更快,那小型的也會非常快...
> : 但是,為何Borland還宣佈OWL 和 BCB將來是兩條不同的
> : 主力生產線呢?
> : 個人的感覺是,大概是低階的控制(例如VXD,device driver大概都要
> : MFC or OWL才能生產吧)...我並沒有寫過VxD,只是猜測!
> 對於 database 型態的,以rad開發是較快的.
> 可是對於一些較細部或是一般不常見的功能可能就要透過 framework
> 甚至 sdk 來完成.
但以DELPHI OR BCB...若您很熟SDK (API)的話,也可以在DELPHI OR
BCB 完成....我看不出有什麼東西是傳統的 SDK 可以完成的,而DELPHI
OR BCB 不能做的(也許寫OCX算是一種吧)....但VB起碼 4.0 版以前就
不行了.起碼 CALL BACK FUNTION, NOTIFY MESSAGE...可能都會卡住...
]
> 整體而言,rad 是開發中小型程式的好幫手
> 而mfc 或 owl則適合大型程式開發.當一個程式過大時
> framework 與 rad 的執行效益與容量會有差別
> 至於 vxd 或是 device driver 則是透過組語完成
> 這又是另外的話題了
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>