談元件技術(一) 必備知識. (轉)[@more@]

談技術(一)

------必備知識

何謂元件技術？元件技術有什麼作用？為什麼要應用元件技術？如何應用元件技術？我們現在都知道什麼？我們現在應該做什麼？又能做什麼？當這些問題纏繞在心頭時，也許您自己也承認，不得不學一學元件技術了，其碼要了解元件技術(元件技術本文以後將以元件代替)。那麼現在問一問自己，你是如何看待元件的？你心目中的元件是一個什麼樣子呢？感覺很好說，也許每個的人員對元件都有一個輪廓的概念，是的，平臺已經用了快十多年了，怎麼能沒有聽過元件？從大的方面而言，當MS應用了OLE的時候，元件已經在慢慢的發展著，從最初的OLE 到到CMO+甚至到了現在的，無處不見元件的存在，然而這僅僅是一個輪廓的影響，我想，在學習元件的時候，首先應該明白一些基本的概念。而寫這篇文章的最終目的就是要回答開篇是提出的幾個問題以及教您如何寫元件(本文將以編寫一個ocx元件、應用MTS元件、COM+元件結束，而對於COM+ 就是MTS的版本所存在的某些歧義也將給於解釋)。:namespace prefix = o ns = "urn:schemas--com::office" />

何謂元件技術？具體死板的概念在各種書籍上有很多的定義，元件技術就是利用某種程式設計手段，將一些人們所關心的，但又不便於讓最終去直接操作的細節進行了封裝,同時對各種業務邏輯規則進行了實現，用於處理使用者的內部操作細節,甚至於將機制和事物機制體現的淋漓盡止。而這個封裝體就常常的被我們稱作元件。或許這個定義有些勉強，但這樣的解釋對現在的你是有幫助的，而這個封裝的過程中，程式設計工具僅僅是充當了一個單純的工具罷了，沒有什麼實際的意義，也就是說為了完成某一規則的封裝，可以用任何支援元件編寫的工具來完成，而最終完成的元件是與語言本身已經沒有了任何的關係,甚至可以實現跨平臺。對我們而言，它就是實現了某些功能的、有輸入輸出介面的黑匣子罷了。

元件有什麼作用？這個問題似乎有些籠統，試著想一想windwos何以實現如此強大的生產力？而在它的背後到底有什麼在服務著？一句話：元件就是windows的靈魂，脫離了元件，windows將不再如今天一樣如日沖天，windows如此，也同樣是如此，作為一個，它所完成的功能無不提體著元件的服務，一個很輕鬆的Copy – Paster都要靠DDE來支援，而DDE就是一種元件服務，而具體到某一個細節，如今的大型ERP靠的是什麼？多層系統又靠的是什麼？元件！元件封裝了系統執行的各種規則甚至執行環境，而元件又何以完成如此多的服務？這兒就不得不提起元件物件，所謂的元件物件是元件的一個集合，而這個集合又並非是隨意性的組合，必須要考慮到元件物件中的各個元件的協調功能，雖然，在理論上講，一個元件物件裡的各個元件應該是互不干涉、互不影響的，但是這並不意味著元件物件就是一個無協調的元件的集合，我們必須理解，透過訪問一個元件物件中的某個元件，就有可能訪問此元件物件中的另外的元件以此迴圈下去.而這些都由誰來管理？肯定是元件物件，可以這樣理解：元件有其自身的規則實現，而規則的實現又提體到了介面的實現，但是元件物件本身也是一個元件，它也有業務邏輯規則需要處理，它也要起到所集合的元件的協調。如此一來，可以能過某一個元件物件來協調的實現一些、一部分的業務邏輯規則！而對於應用者來說，這一切完全沒有必要去得知，甚至是沒有意義的。

為什麼要應用元件技術？或許你會說，我們透過程式設計的手段同樣可以處理一些簡單的或稍微複雜的業務規則，的確，不否認，透過程式設計的手段我們可以實現如元件物件一般實現的規則處理。然而如果僅僅是因為此我們就說元件物件或元件和我們平時的編碼是一致的，那麼現在可以明確的告訴你，這是一個很糟糕的想法。使用元件技術的的目的是實現各種規則{你想要實現的規則}的實現，而且元件物件還將從更廣闊的方面來考慮，它能將一個大型的分散式系統進行統一的規劃、合理的處理冗餘、安全、平衡負載……等單純的程式設計手段不能實現的功能，這就是我們要應用元件的一個很重要的原因。再者，元件物件不是普通的可，更不是將各種規則定死在其內部，它可以很平滑的實現自身的升級、擴充套件(前提:不大量的更動介面)，舉一個很簡單的例子，當我們發現某項業務邏輯規則已經很陳舊的時候，我們不得不用新的業務邏輯規則去替換它，而這個替換過程將會提現出元件對於普通的.Dll檔案或是.Exe可執行檔案的具大差別。當我們需要進行更新的時候，對於元件物件而言，在最理想的情況下使用者可以一邊進行元件物件的應用，一邊無知覺的接受新的元件技術，而試問一個Dll檔案或是某一個可執行檔案可以達到這樣的效果嗎？答案是否定的。如果你說這些理由還不夠的話，我可以舉出很多的應用來說明元件應用的必要性，然而，理由實在太多，也沒有必要一一列舉，你可以參考其它的技術資料或是在平時的操作中去發現。

如何應用元件？在這點上或許我們更關心的是我們如何透過程式設計的手段來實現元件，在開篇的時候已經提起過，元件就是利用某種程式設計的手段來封裝業務規則，而且也強調了語言在此處僅僅是一個工具罷了。但你可以完整的寫出一個元件的時候，那麼對於其應用就會更明確，對其給工作帶來的而驚歎不已。那麼到底如何應用元件技術？元件技術屬於高組的應用部分，它可以從系統的底層作起，一直到我們可以感覺的明顯出來的功能的封裝。而在此過程中，我們就是要透過自己熟悉的工具來寫一個好的元件物件或是元件。

我們現在都知道什麼？雖然元件技術屬於高階程式設計範疇，但是隻要它是可以程式設計實現{又有那一種技術不可以實現呢？}的，我們就可以去實現一個元件。並且我們已經知道了元件的應用、作用，那們我們現在所應該做的就是熟悉一門開發工具，所謂的工欲善其事，必先利其器就是說我們只要很好的掌握了一個工具才有可能跨進元件技術這個大門(請不要在元件技術是語言無關性上和此處的表達方式進行糾纏，再如何的語言無慶性也必須要靠工具去實現，不是嗎？)，否則就算對元件技術理解的再透徹也只能站在門外徘徊。所以我們現在知道的無非就兩點：元件和我們所掌握的工具。

我們現在應用做什麼？又能做什麼？沒有基石的大廈必將會倒塌，我們沒有堅實的基礎做後盾，那麼我們所寫出來的元件必將也是一些垃圾！或是不成形的玩具罷了。或許你對元件很瞭解，而且也很明白的設計，但是這一切都是建立在對其核心不理解的基礎這上，只能說這是一種空白的設計，因為你將無法的切身體會的那種設計模設將會給你的元件帶來質的飛躍，元件如此，其它也如此，就如一個好的專案經理需要有靈敏的思維和高超或是相當不錯的技藝一樣，否則，別人只會認為他在空談自己的構想。所以我們現在應該做的就是充分的理解元件的應用之處、元件自身的規則以及我們的開發利器。這就是我們應該做的而且也是我們目前唯一可以做的。

當我們對元件有了一個基本的輪廓或是比較清楚的影響時，下一步就是來將我們的工具與元件結合起來。每一個開發工具都有其自身的特點，不同的語言雖然可以實現某些相同的功能，甚至被人們所說使用何種開發工具都一樣的言辭所一概而論，此時我們就應該意識到這點是錯誤的，因為開發工具都有其利有其弊，應用其利是我們應該做的(並非是要大家對弊端棄之)，此為其一，另外我們也必須要知道用什麼樣的技術所實現的更能給我們的元件帶來效益上的飛躍、冗餘上的放心、負載平衡上的可靠等。到現今為止，我們在熟悉我們的開發工具的同時還需要將物件導向程式設計的思想深深的滲透。為什麼要這樣說呢？.Net的Framework的設計給了我們很大的忠告，一個元件其實就是一個工程，一個專案，而實現工程、專案的最好方法就是充分的利用思想，當然，如果你要是能確定你此處的版本是最終版本的話，倒也無妨，無非就是在此版本中的編碼系統上覆雜一些罷了。可以看到出OOP程式設計對於我們寫元件有很大的幫助，如果您還不明確的話，不妨舉一個很簡單的例子：透過OOP可以充分的減少複用程度，提高可擴充套件程度。而一個元件將作為眾多個終端的應用，我們就一定要考慮到其執行效率、可擴充套件性等眾多特性。這是相互的一個過程。所以在這之後，我會先對OOP做一個簡單的概括{各位都是做OOP程式設計的，所以此處僅僅是作簡單的提起，省去N個字}.

讓物件導向程式設計滲透到我們的每一個實現的細節中。

{因為此處要設計到一些例子，而我所熟悉的工具又是，所以，此處將以Delphi作為OOP的物件來講}

物件導向思想的三大核心內容是封裝，繼承，多型。那麼我們就對這三點進行分析，並就其中的一些例子進行點評。

在此處省去了分析類、物件這兩個概念，但應該明白的是物件，作為類例項，從某種意義或是一般而言，它就是一個指標，當然，如果此處有人一定要強調Delphi是一個引用/物件模型，而並非是物件指標的話，我不以辯解。

封裝：元件物件要封裝元件，而元件又要封裝介面，最終介面還是需要封裝其所實現的業務邏輯規則，所以，單一的從OOP的這一點上來考慮的話，元件物件和OOP就應該有某種分不開的關係。封裝主要提體在兩個方面：類封裝、物件封裝，具體的細節可以參考相關資料。

封裝就是一種UI分離，為什麼我會這樣說呢？提到封裝，也許我們最容易想到的就是黑匣子。的確，我也承認封裝就是一個基於黑匣子的實現方式，而且也是相當恬當的一種比喻，如何說呢？因為封裝也一樣有兩個“介面”，一個是活的，一個是穩定的，而所謂的活就是封裝內部所處理業務規則的實現方法，如果不去計較其效率的話，我們可以用任何的手段去實現其內部的功能，可以進行隨意性修改（此處的隨意性修改僅僅是為了體提它的“活”而給出的。）但是無論其是如何的活，如何的隨意性，它都有一個最終的目的，就是為了實現一個穩定的“介面”，內部的內容可以進行改動，而穩定的介面是不應該隨意更動的。類如此、物件如此，一個介面、元件、元件物件更是如此。單純的從一個專案而言，這種封裝就是一種UI分離，不要固執的認為UI分離就是將使用者操作和邏輯規則處理放在了兩個“物理”上很遠的操作就是封裝，如果這樣認為，我只能說你的OOP理解的不好。此處給一個例子來進行分析：

  TCustomFo= class(TScrollingWinControl)

  private

  FActiveControl: TWinControl;

  FFocusedControl: TWinControl; 

  function GetMDIChildren(I: Integer): TForm;

  function GetMonitor: TMonitor;

  ……

 public

  constructor Create(AOwner: TComponent); overr;

  procedure AfterConstruction; override; 

  ……

  end;

想說明的是此處的private 就是我們剛剛所說的活的部分，它的內部可以進行任何的改動的，但是，它必須要保證最終的Public 是穩定的。這就是一種封裝的提體，也是一種UI操作的例項。同時我們也應該注意到，正是因為封裝性，所以就要求我們在考慮穩定部分的時候做一些工作，當一個專案投於應用之中之後，我們就沒有辦法再去更改這些穩定的部分，因為這些部分是直接於使用者進行關聯的，使用者的操作就是對急定部分的操作，如果一但改動了某一個使用者正在使用的穩定部分的屬性，其後果就是專案的重新規劃、開發。總之一句話：封裝可以隱藏實現細節，使得程式碼模組化,實現程式碼的可複用性。不知道封裝的闡述各位是否明白？如果有任何的疑問可以與我聯絡，歡迎您和我一起探討。

繼承 :封裝隱藏了實現細節，那麼繼承呢？繼承是為了擴充套件已經存在的模組(如類、介面)，同樣它也是實現了程式碼的可複用性，在封裝部分已經強調了，封裝就是將一個模組很明確的劃分成了“活”的實現部分和穩定的實現部分，而我們也提起了，其實現之後並且進行了分發就不應該進行更動，特別是當一個專案已經投入到應用之後，再次修改穩定的部分將破壞了原有的初衷，繼而將有可能造成整個系統成為垃圾，在介面中，提體的更明顯，那麼我們如何也不可能對於某一個模組永遠的不進行功能的添充、修改等操作，我們如何辦？修改其中的一個介面嗎？肯定不行， 修改介面其實就是在說：我這個元件將不再為我的使用者所服務，因為使用者正在應用的介面我將重新進行規劃，而且其它元件中有可能此介面的接也將不再使用，試想一下，這種結果是什麼？{說明：對像可以實現多個介面，而一個元件又可以包含多個實現介面的多個物件，同時一個元件物件又是多個元件的集合}。怎麼辦？廢棄這個元件物件或是專案嗎？那麼使用者怎麼辦？老闆允許我們這樣做嗎？肯定不成。而此時就是用繼承的時候了。如介面A中的某一個方法要進行改變(此處的方法其實就是屬性！)，同時要增加另外一個屬性，有兩種方法，重新寫一個介面，另外一種就是繼承於介面A，讓介面B作為介面A的派生介面，它可以實現所有介面A中的可繼承屬性，同時又可以覆蓋掉某一個屬性而用另一種規則進行實現並且也可以再新新增自己的方法、屬性。而這一切對於使用者來說是完全透明的，他們不知道你做了些什麼，更不知道，它應用的某個介面已經被替換掉了(可以替換嗎？注意Delphi中的As的用法).

多型：在理解了封裝和繼承的同時，再讓我們來看一看多型，如果要對多型進行形象、明瞭的闡述，將會花太多的篇幅，而現在關於多型的闡述又很多，您可以參考一些資料進行理解，此處僅僅進行簡單的說明：多型是OOP中三個基本概念中最不好理解而且也是最有趣的部分，我們提到了封裝可以隱藏實現細節，使得程式碼模組化；繼承可以擴充套件已存在的程式碼模組（類）；它們的目的都是為了——程式碼重用。而多型則是為了實現另一個目的——介面重用！多型的本質就是將子類型別的指標賦值給父類型別的指標（在OP中是引用，實質上也是一種指標），只要這樣的賦值發生了，多型也就產生了，因為實行了“向上對映”。

符加部分

{

也談多型

封裝、繼承、多型構成了OOP的三大基本核心，封裝、繼承在之前我們曾作過介紹，而多型沒有進行詳細的介紹，在此給以補充，以完成OOP的三大主題來結束OOP的那一塊。關於多型在很多資料上都有介紹，而且介紹的非常精彩，那麼就讓這篇文章再來進行一次總紹吧。

首先說點廢話，以下的介紹以及例項中，我將以 Pascal作為講解的工具，而多型實質上是OOP的，不屬於某一個工具的，它是一種信仰。在此處雖然以Objec Pascal來進行描述，其實可以擴充套件到任何的語言中。言歸正轉，繼續我們的話題。

什麼是多型？多型的本質是什麼？多型和封裝、繼承有什麼關係？它在OO中站有什麼樣的地位？多型給我們的工作代來了什麼？本文就對這些問題加以闡述，在闡述的過程中來理解多型，認識多型，應用多型。

什麼是多型？似乎沒有一個統一的定義來規範多型，或許以我們自己的理解方式來解釋多型更為貼切，在此我們不引用一些術語來進行定義，就初學者也可以理解的方式來形像這個定義：多型，顧名思議，就是多種形態，而這種多種形態又具體又體現在了什麼地方？可以這樣理解，我們可以用一種輪廓的物體來描述不至一種的多個物體，而至於我們到底要描述那個物體的狀態，對於我而言不很重要。為什麼要這樣說呢？多型就是給我們體供了這樣一種機制，我們對它僅僅是一個形式上的宣告、定義，而具體的實現上的細節我們沒有必要在此進行關心。或是具體的實現細節將交給別的東西去實現。我們所宣告的這個基類從某種意義上而言只是一種定義。就如介面一樣，沒有實現部分，說到這兒，不得不說多型的本質了。多型的本質就是基類提供一系列的虛擬方法，如果試圖去實現這個基類的話，將被告之這樣是行不通的。多型性的完整提體是交物件和他的子物件共同完成的一個思維方式。 多型性是允許你將父物件設定成為和一個或更多的他的子物件相等的技術，賦值之後，父物件就可以根據當前賦值給它的子物件的特性以不同的方式運作。對於使用者而言，他們所關心的只不過是那些沒有實現細節的父類所提供的虛擬方法罷了。如果以介面的話來講就是：我們不去關心，也沒有必要去關心介面的實現細節，我們所關心的僅僅是介面為我們提供的方法來完成我們的功能，而至於介面以何種方式來實現我們所需要的不同功能甚至是一個特定方式的多個功能都是其內部的事。不知道這樣的解釋是否讓大家感覺很模糊，在理解上是否感覺不能很好的接受。請繼續往下看。

談到多型，我們首先要明白，對於多型而言，其父類提供了很多的虛擬方法，所以我們沒有辦法去直接實現這個父類，只能透過它的派生類去覆蓋其提供的虛擬的方法，所以這就產生了多型。我們都知道，一個類可以被多個子類所繼承，而每個子類所實現的方法又不一至，或是根據它們自己特有的特點對一個特定的方法的實現上因為類差別而存在著差別，但是我們完全可以透過父類去模糊化這些操作。對子類的方法的呼叫完全都可以透過基類去實現。由此而言，如果此基類沒有被派生，那麼這個類是完全沒有存在的意義的！只有它被某一個子類派生了，那麼它就正真的有存在的意義了。這種意義又提體在什麼地方？或我們以什麼手段來讓這種意義成為焦點呢？這就是我們需要進一步走進多型的原因，如下所示：

TA = Class

  Public

  Procedure A ; virtual ; abstract;

  Procedure B ; Virtual ; abstract;

  Procedure C ; virtual ; abstract;

  end;

當我們宣告瞭類TA時，可以看到它有三個方法，而且也注意到了這三個方法都是完全虛擬的，如果此時我們試圖例項化這個TA，將會沒有任何的意義的，因為我們無法去實現類TA給我們提供的各種方法，或者說編譯器將不提供空間/機制來讓我們實現這些虛擬的方法。只有透過其子類進行覆蓋這些虛擬方法才可以正真的將它們提體出它的作用。而覆蓋就是說子類重新的定義、實現了基類的方法。如：

TB = Class(TA)

  Private

  B_Str : String;

  Public

  Constructor Create(Value : String);

  Destructor  Destroy();override;

{這是覆蓋。設麼地方可以用override?當他積累相對應的方法是虛擬的或是動態的時候才可以用override}

  Procedure A ; override;

  Procedure B ; override;

  Procedure C ; override;

  end;

 

 TC = Class(TA)

  Private

  C_Str : String;

  Public

  Constructor Create(Value : String);

  Destructor Destroy();override;

  Procedure A ; override;

  Procedure B ; override;

  Procedure C ; override;

  end;

這裡有一個初學者或是不太注意語法的人經常混淆的概念。覆蓋（override）和過載（overload）。上面說了，覆蓋是指子類重新定義父類的虛的做法(inherted的用法是什麼意思你真正的明白嗎？)。而過載，是指允許存在多個同名函式，而這些函式的參數列不同（或許引數個數不同，或許引數型別不同，或許兩者都不同）。如下：

  Procedure Open(Sender : TADOQuery;SQLStr : String); overload;

  {當重複時，返回為False,否則返回為True}

  Function OpenSQL(SQLStr : String) : Boolean ; overload;

 

Function ifrepeat(TableName,FieldName,FieldValue : String;IntValue : Integer = 0):Boolean;overload;

  Function ifRepeate(TableName : String;FieldName , FieldValue :

  Array of String) : String ;overload; 

可以很清晰的看到上邊的程式碼就是一個子類覆蓋了基類的虛擬方法的過程，而此時還不能很明確的提體出來多型的特性，或是說多型的本質問題還沒有提體出來，並且您可能於晚期繫結也不是很明白，下邊將給以解釋。

當我們從抽象類TA派生出了類TB和TC，並且，子類也覆蓋了基類的虛擬方法，現在如何應用這些方法呢？我們將以什麼樣的形式去呼叫這些方法呢？這才是多型最值得焦點的時刻，也是最能體現多型的本質的地方，之前已經給您灌輸了多型的本質就是將子類型別的指標賦值給父類型別的指標，只要這樣的賦值發生了，多型也就產生了，因為實行了“向上對映”。何以這樣說呢？請繼續我們的例項，假設它們的實現方法分別如下：

{ TC }

 

procedure TC.A;

begin

  inherited;

{inherted的意思就是把相應的訊息交給其父類去處理，他不屬於我們討論的範疇}

  ShowMessage('TC' + C_Str);

end;

……

{ TB }

 

procedure TB.A;

begin

  inherited;

  ShowMessage('TB' + B_Str);

end;

……

現在我們就可以透過父類來來對子類進行呼叫，而這個過程其實就是一個“向上對映“的過程，既：子類型別的指標賦值給父類型別的指標；我們可以在此定義一個全域性的過程來驗證我們上邊的話：

Procedure Test(Const pA : TA);

begin

  pa.A;

{請將您的注意力放在此處，我們說了，TA是一個抽像類，它所提供的方法都是虛擬的，只有被覆蓋了才可以進行應用，那麼此處的處理是否是正確的呢？答案是肯定的，於是，多型在此處便提體的淋漓盡止，同時我也給出了呼叫的過程}

end;

procedure Tform.ButtonClick(Sender: TObject);

var

  vTC : TC;

begin

  vTC := TC.Create('多型例項_vTC');

  Test(vTC);

  vTC.Free;

end;

{此時你是否可以看明白了這種“向上對映“的機制呢？vTC做為一個子類TC的引用值(物件指標)，完全可以賦值給其基類TA，於是，此處就發生了子類型別的指標賦值給父類型別的指標，於是多型就產生了！！！}

此處再一次的對晚期繫結或是動態進行說明：當子類重新定義了父類的虛擬函式後，父類指標根據賦給它的不同的子類指標，動態（記住：是動態！）的呼叫屬於子類的該函式，這樣的函式呼叫在編譯期間是無法確定的（呼叫的子類的虛擬函式的地址無法給出）。因此，這樣的函式地址是在執行期繫結的（晚邦定）。

我想，此時，你應該對多型很明白了吧，那麼我們講了多型是OOP的一個重中之重，那麼它倒底有什麼作用？它給我們的專案將會帶來什麼效率上的飛躍呢？僅僅是為了完成某種實現方法嗎？僅僅是作為一個概念而存在嗎？這些都是我們在理解了多型之後必須去思考的東西。那麼下邊就多型將會如何的影響我們的效率進行闡述。我們知道，封裝可以隱藏實現細節，使得程式碼模組化；繼承可以擴充套件已存在的程式碼模組（類）；它們的目的都是為了——程式碼重用。而多型則是為了實現另一個目的——介面重用！

如果還沒有很明白多型，不妨參考下邊的例子。

在這個問題上可以這樣說：大炮可以打鳥，火槍也可以打鳥，你用那個？我不管是大炮還是火槍，我只知道他們都可以打鳥！向恐龍一樣大的鳥我用大炮(就是一個例子，哪有那麼大的鳥啊？打什麼鳥對於長官來說就是一句話：打死它們，用什麼？他不管)，小鳥我用火槍。敵人來了我還可以打敵人，這就是動態的最終解釋和一種介面重用！
有很多地方我是應用前輩的話。

}

在對OOP的總結部分，我想說一說我對現在的員的一些看法，或就我而言對於自己的OOP思想的滲透進行檢討，我曾一度的迷惑，的確，我一直認為Delphi的確是一個優秀的開發工具，高效、、易用……，然而在相當長的一段時間內，我不知道我作專案、寫程式碼的時候是否有一些OOP滲透在裡邊？有種感覺，我好像只會將那些脫來應用，編碼也僅僅是對其進行編碼，視覺化的介面設計，豐富多樣的可用元件讓我感覺很不安，我不知道自己是否只是如作圖一樣，從一個地方拉來一個圖，然後只會對這個圖進行修飾，雖然這讓我對VCL元件有了很好的應用，可從來都沒有過喜悅，一直都很鬱悶，難道VCL只是給了我們這些嗎？於是我不再瘋狂的購買VCL元件使用的書。只有當自己接觸了介面程式設計、元件技術時，我才發現我以前在很長一段時間裡，甚至是貫穿於我的整個程式設計生涯到那時，只將注意力集中在Delphi提供的現有的VCL元件的使用上，而忽視去思考物件導向的思想對於Delphi的整個元件構架體系所蘊含的意義。我也才深深的明白了為什麼曾有前輩在說“Delphi在毒害程式設計師”；在此，衷心的希望各位不要停留在VCL元件的使用上，而應該用物件導向的思想去理解Delphi的整個元件構架體系所蘊涵的意義。

  在理解了OOP之後，我們對於元件所要必備的另一個知識點：介面 進行闡述，也許作為剛剛接觸介面的您來說，這有些枯燥，但是必須給您說明的是，此處所說的介面將會百分百的引用到以後的元件技術或是元件物件中，因為它們最終就是對介面的實現、封裝！

  請關注下一篇文章。

 轉貼請註明 作者：dprogram