個人觀點隨筆-RAD和麵向物件 (轉)

個人觀點隨筆-RAD和麵向物件 (轉)[@more@] 

個人觀點隨筆-RAD和麵向

  網上經常有討論開發工具的優劣性文章。彷彿結果一定是一派要壓倒另一派。特別是RAD與非RAD的爭論。如“VC和BCB哪個更好”、“vs Dephi”等等。

  有人曾經說做一個好的員一定要懂得。雖然、VB把API封裝了起來，簡化了工作，但也阻礙了成為高手的機會。極力倡導使用VC進行程式設計。我想之樣的人他一定是Win32的程式設計好手，是VC的熟練工種。但他一定對RAD的開發工具不甚瞭解，特別是Delphi。（VB暫且先不討論）。

   RAD的開發工具確實很簡單。拖拽幾個，寫幾個事件。一個小程式就做完了。似乎對這個程式是怎樣執行的不甚瞭解。確實造成了一大批人對BCB,Delphi的誤解。BCB真簡單。我想敢說這樣的話的人不是一個剛剛對BCB入門的人，就是一個絕頂的WIN32程式設計師，對VCL和API很精通的人。第二種人那就無話可說了，他真的有資格說簡單。第一種人BCB的VCL不但會方便你的開發，而且他決不會成為你成為高手的機會。如果你精通 Pascal那麼VCL將成為你學習的絕好參考。

  我要強調的是要多多弄清內部機理，不要成為的砌磚奴隸。

  Nicrosoft的一篇文章寫得很好《把物件導向貫徹到底》。很多人用Delphi來做開發只是用到了它的元件提供的功能。很精通，精通什麼呢，精通應用元件。現成元件所有功能特性他都會。可離了現成元件他什麼也幹不了。元件能做的就是他能力的極限。一旦用到相對低階的API他就束手無策了。認為開發工具不足正是報漏了開發人員自身的不足。抱怨Delphi不能做低階的事，正報漏了他本身這方面能力的欠缺。如果不是，他完全可以自己去開發、去擴充套件它。用慣了RAD開發工具不要被它華麗的外表所迷惑而不去探求更深的東西。我常常見到這樣寫程式碼的程式設計師：

unit Unit1;

 :namespace prefix = o ns = "urn:schemas--com::office" />

interface

 

uses

  , Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

  StdCtrls;

 

type

  TForm1 = class(TForm)

  Button1: TButton;

  procedure Button1Click(Sender: TObject);

  private

  { Private declarations }

  public

  { Public declarations }

  end;

 

var

  Form1: TForm1;

 

implementation

 

{$R *.DFM}

 

procedure TForm1.Button1Click(Sender: TObject);

begin

  Form1.Button1.Caption:='開發';

end;

 

end.

  畫線的的那行程式碼是有嚴重的邏輯錯誤的，雖然編譯可以透過。Form1不過是Tform1類的一個例項而已。我們現在寫的是一個TForm1的類。這段程式碼犯的錯誤就是以偏蓋全，以一個特例去描述一個類，這是典型的白馬非馬論。

最起碼的這句話應該這樣寫Button1.Caption:='快速開發';而最好要寫成Self. Button1.Caption:='快速開發';這才不會以偏蓋全。

我們要做的事物件導向，而不是基於物件。

要你去寫對一個的操作（如F檔案）你會如何寫呢？

定義一堆結構，寫一堆。然後去挨個這些函式對檔案進行操作。

還是定義一個DBF檔案的類，然後把對它的操作都封裝起來，只留下需要呼叫的函式（如讀、寫）作為公有。

或許第一種方法的程式碼要遠遠的少於第二種。但第二種有著第一種方法不可比擬的優勢。

1．  思路清晰，更符合人的邏輯思維。而第一種方法更像一盤散沙。

2．  可靠，我只把共有函式讓你呼叫，而其他的都由內部封裝好了，你根本看不見，也不需要考慮它是如何實現的。

3．  方便維護，哪個地方錯了我只要把這個類的相關部分作以下改動即可，不會造成混亂。

好處不止這些。

我的意思是說要多多運用物件導向的方法，不要成為基於物件的工人。