封裝與重用演變史

封裝與重用演變史
                                                       ----Mingo寫於2012.07.16

 

轉載請註明出自:blog.csdn.net/mingojiang


目錄
概述
一、明碼重用與封裝
二、靜/動態庫/COM
2.1靜態庫
2.2動態庫
2.3COM技術
三、跨語言/跨進程/跨機器
四、分佈式技術
4.1WebService
4.2WCF技術
五、總結

 

概述

經常喜歡思考些問題,一直對編程技術的封裝與重用的發展有些想法,想寫下來,不過純屬人個觀點,本人知識有限,生怕擾亂視聽,如果有謬誤萬望指正。

編程技術從彙編(甚至更原始的其他語言)C發展到現在的C++JavaC#等高級語言,這是語言的演變,技術方面從開始的明碼重用、靜態庫、動態庫發展到如今的COMDCOMActiveXWebService再到WCF,無任是語言還是技術從未脫離兩個主題,那就是封裝與重用。下面對每一個階段從背景與解決的問題兩個方面講講。

 

一、明碼重用與封裝

C語言開始講講吧,更原始的語言我也不懂,C語言時代,應該是明碼粘貼,把某一段代碼貼來貼去,以達到重用的目的,後來程序員會把自己比較常用的一些方法,封裝到函數裏面,以達到重用加封裝的效果,要用到某一功能時,把函數考貝過來,直接調用,不用去管函數裏面的具體實現。當時感覺應該挺好的,,不錯,把不同的功能模塊封裝到不同的函數中,這權且稱之爲明碼重用與封裝吧。

後來人們發現,通過函數封裝重用,麻煩大大的,明碼copycopy,總是個麻煩事吧,其次,明碼不好維護,一不小心就改了,再一個封裝不好,明碼誰都看得見,有些東西是不想給人家看的,你懂的。讓人更蛋痛的是,C++語言的一段明碼在C#環境下使用,還得有些修改。這種背景下,靜態庫誕生了,解決了這些問題。

二、靜/動態庫/COM

        靜態庫與動態庫都是基於二進制文件的重用,所以說原則上,可實現跨語言重用,只要接口是規範的,C++編寫的靜/動態庫CC#等都可重用。前提是它們得符合接口規範。

2.1靜態庫

靜態庫是一種把方法封裝在一個二進制文件裏,只把方法的接口暴露出來即可供人調用的一種技術。這樣就好辦了,即省去了copy明碼的麻煩,調用時也不用看那些不該看的,靜態庫提供者也放心不少,自己的勞動成果有一定保護了(可以在庫裏面加密鑰,加有效期等)。使用範圍也寬了,靜態庫的接口是標準的,所以C環境可以調用,C++環境也可以調用,後來發展起來的C#也一樣可以調用。牛吧!

慢慢的,靜態庫的問題來了,靜態庫雖然是封裝好了一個獨立模塊,但是調用的時候是直接鑲嵌在主調環境中的,不夠靈活,要更換升級的話得重新讓技術人員編譯一邊。再一個重用上有侷限性,想要調用靜態庫的程序都得鑲嵌一份靜態庫,導致資源浪費,如果靜態升級就更麻煩,所有的主程序都得拿回來重新編譯一遍,麻煩呀。總之應該是升級麻煩,不靈活,再一個浪費空間,如果一個PC機中N個程序要用到某一個靜態庫,那就有N份相同的靜態庫,佔內存,佔空間。

那怎麼辦呢?當然是想辦法弄個分體了,你看人家造車的就先想到這一步,車軲轆與軸承之間的連接,人家就沒有用電焊燒死,而是留好螺絲孔,軲轆壞了,或者主人想升級了(換個好軲轆),把新軲轆拿來,在路邊把螺絲一擰,舊的下下來,新的換上,OK,更不需要把車開回廠家讓專業人員重新裝卸。不知道是不是從這裏得到了啓發,先人們發明的動態庫,解決了這些問題。這個比喻不是很形象,這裏沒有解決重用的問題,車輛與車之間不能共用4個軲轆,即使可以,那同時也只有一輛車能正常運行。而動態庫是可以同用一個備份的。

2.2動態庫

動態庫是怎麼回事呢,接口與靜態庫差不多,也是定好了規範的接口,不同的是,調用方法時,是動態調用的,與主調環境是不在一塊的,一個計算機上只需要把動態庫載入內存一次,所以同計算機下的程序都可以共用動態庫,也就是說你要調用時,打開那接口就OK,就能得到結果。這樣說太繞了,還是來打個比喻吧,你家樓下那個粗的自來水管好比動態庫,你與你的鄰居都可以通過小水管(接口)接到粗水管上,你與你鄰居打開各自的水龍頭都能用清水,並不需要每家都去自來水廠拉一根水管到自己家中。這解決了資源浪費的問題,因爲大家共用一根水管。如果某一天自來水廠換場地了,從西麗水庫搬到了深圳水庫,別急,你並不需要去把自己的水管從西麗水庫接到深圳水庫去,那是自來水廠的事,他們會把供水的粗水管安裝好,你家樓下的接口不用動,在家等着用水就OK了。

總結一下,一、所有程序(同一計算機下)可共用一份動態庫,一次載入多方使用,解決了佔空間內存的問題,二、動態庫要升級,只更換動態庫就OK,調用動態庫那些程序都不用更新,也不用修改,解決了升級麻煩問題。除非你想要使用新版本動態庫中的新接口,那樣主調程序纔要改。

但是DLL也有些問題,DLL主要是解決函數的封裝重用問題,對於二進制文件的交互沒有很好的支持,還有接口適用性有限,接口得用一些基本的數據類型,不然其他環境可能會面臨調用的麻煩。下一步該COM出場了。

2.3COM技術

COM對接口做了更好的規範,接口是用idl描述的(DLL對語言有一定的依賴性,接口是通過基本數據類型來協調,也就是公認數據類型,或者說能相互轉化的數據類型),使它能適應更多的環境,交互性得到了更好的支持,爲跨進程,跨機器重用打下了基礎,後來發展起來的COM+,DCOM就是基於這種技術。對於COM本人水平有限,不多說,如果想多瞭解的可參看《COM本質論》。總之,COM解決了DLL接口問題,與DLL交互問題(DLL一般只被調用,交互方面支持有限)COMDLL的一種延伸,COM某種程度上可以說是DLL,DLL並不是COM.

 

三、跨語言/跨進程/跨機器

        COM局部的實現的跨語言重用,但是它只是本地重用(同一機器下),爲支持跨進程,跨機器,後來誕生了COM+,DCOM,ActiveX

        無論是COM+,DCOM,還是ActiveX都是基於COM技術,在這裏我們簡單介紹一下就可以。這些技術都是爲了支持跨進程,與跨機器(跨網絡)重用的,DCOM開始萌發了分佈式的思想,COM+DCOM都能跨越這些邊界問題。後來感覺網頁調用DCOM之類可能有些不便,纔有了ActiveX,ActiveX就更牛了,可以網頁調用,一般程序調用就更不用說了,它的接口比COM更先進,適應性更強,ActiveX載入的時候,可生成相應語言的類,C++調用會生成C++的類,C#亦然,使用起來非常方便,更何況它還能供網頁調用。我在這裏說一個例子吧,公司開發的一個網頁需要訪問串口來讀寫串口設備上的IC,網頁要訪問串口那是個麻煩事,後來我用C++寫了個ActiveX控件,把與串口的所有操作都封裝到了ActiveX控件中,網頁只管調用接口即可。

 

四、分佈式技術

        這是基於網絡環境中的一種技術封裝與重用,先後有Enterprise Architect技術、RPCWebServiceWCF等技術。這就更復雜了,這個服務可以在世界的任意角落,只要把接口暴露在網絡上即可,這就涉及到通信,接口規範。先說通信,WebService說說,WebService一般能實現即問即答通信模式,也就是你請求接口,給你返回結果,它不主動給你通知,也不主動給你結果。通信協議也有侷限,是基於XMLhttp技術,不支持tcp,管道等通信協議。在這裏就介紹一下WebServiceWCF吧。

4.1WebService

        WebService是基於xmlhttp的一種技術,WebService寄宿在IIS,配置好一些接口,可以通過Inter網向WebService發出請求,得到想要的數據。原則上支持跨機器、跨網絡共享,還跨語言,原則上C++C#等,支持XMLhttp技術的都可調用。

WebService數據用XML描述,通信基於http協議,一般用.Net技術開發的,.Net環境下調用WebService非常方便,C++調用那就有些麻煩了,得通過一個叫作SOAP的第三方插件來協調接口問題。java訪問就有麻煩,總之,不是很理想了,WebService是微軟搞的,.Net之外的技術要使用能不沒點麻煩嗎?

 

4.2WCF技術

        WCF叫作Windows Communication Foundation,它是WebService的延伸,從接口規範,通信支持,宿主環境等方面做了擴充與完善。WCF接口使用WSDL描述,能通過工具生成相應語言的調用方法,如能生成C++的調用方法,不再需要那個SOAP,通信方面,在協議與技術上都得到了完善,它支持TCP、管道、http等協議,而且可以雙向交互,也能像打電話一樣,你說說我說說,相互交流了,宿主方面,WebService一般是寄宿在IIS上的,WCF可寄宿在IIS,也可寄宿在桌面程序上。

五、總結

        總之,這些都是圍繞着封裝與重用在討論,粗略地介紹了些原理,技術細節要再看相應的技術文檔。

        開始是面向過程,如彙編,C這些都是面向過程的技術;後來誕生了C++,面向對象,通過來具體表現。再後來發展了面向組件,就是模塊化,分工化。把業務切成N個模塊,各自生產各自維護封裝,然後把成品湊一起做個大拼圖。再後來發展成了面向服務,也就是剛介紹的WebServiceWCF技術。面向服務簡稱SOA,這裏舉個例子:開始一堆廣東人在一起,他們都講粵語大家勾通都沒有問題,後來客家人、北方人、外國人都來了,說廣東話不合適了,但是說什麼話好呢,世界上並沒有一種語言大家都能聽懂的呀,後來有個天才發明了一種翻譯機制叫作WSDL,可以把任何語言轉化成英語,然後又可以把英文轉化成任何語言,如:客家人說一句話,翻譯機把客家話翻譯與英語,到了廣東人那裏,英語再變成粵語,到了福建人那裏英語譯成了閩南話,這樣勾通就無阻了。後來翻譯機制不但能翻譯人直接說的話還可以翻譯電話通話,還翻譯文字信息,這叫支持多協議。

        發展軌跡是:面向過程、面向對象、面向組件、面向服務。現在大家又開始扯”,不過目前在中國還是雲裏霧裏的,也沒讓我們在現實中真正體會到什麼是”,什麼雲電視,雲手機,個人感覺炒作概念、忽悠成分多於真實意義。我個人只把它理解成面向服務的一種新思維,如面向對象一樣,開始就是一種思想,僅此而已,至於後來有那麼多具體實現,那是後話。

 

轉載請註明出自:blog.csdn.net/mingojiang

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章