個人觀點隨筆-RAD和面向對象
網上經常有討論開發(fā)工具的優(yōu)劣性文章。仿佛結果一定是一派要壓倒另一派。特別是RAD與非RAD的爭論。如“VC和BCB哪個更好”、“VC vs Dephi”等等。
有人曾經說做一個好的Win32程序員一定要懂得API。雖然Delphi、VB把API封裝了起來，簡化了編程工作，但也阻礙了成為高手的機會。極力倡導使用VC進行編程。我想之樣的人他一定是Win32的編程好手，是VC的熟練工種。但他一定對RAD的開發(fā)工具不甚了解，特別是Delphi。（VB暫且先不討論）。
RAD的開發(fā)工具確實入門很簡單。拖拽幾個控件，寫幾個事件。一個小程序就做完了。似乎對這個程序是怎樣運行的不甚了解。確實造成了一大批人對BCB,Delphi的誤解。BCB真簡單。我想敢說這樣的話的人不是一個剛剛對BCB入門的人，就是一個絕頂的WIN32程序員，對VCL和API很精通的人。第二種人那就無話可說了，他真的有資格說簡單。第一種人BCB的VCL不但會方便你的開發(fā)，而且他決不會成為你成為高手的機會。如果你精通Object Pascal那么VCL將成為你學習的絕好參考。
我要強調的是要多多弄清內部機理，不要成為
組件的砌磚奴隸。
Nicrosoft的一篇文章寫得很好《把面向對象貫徹到底》。很多人用Delphi來做開發(fā)只是用到了它的組件提供的功能。很精通，精通什么呢，精通應用組件?，F成組件所有功能特性他都會?？呻x了現成組件他什么也干不了。組件能做的就是他能力的極限。一旦用到相對低階的API他就束手無策了。認為開發(fā)工具不足正是報漏了開發(fā)人員自身的不足。抱怨Delphi不能做低階的事，正報漏了他本身這方面能力的欠缺。如果不是，他完全可以自己去開發(fā)、去擴展它。用慣了RAD開發(fā)工具不要被它華麗的外表所迷惑而不去探求更深的東西。我常常見到這樣寫代碼的程序員：
unit Unit1;
interface
uses
Windows, 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:='快速開發(fā)';
end;
end.
畫線的的那行代碼是有嚴重的邏輯錯誤的，雖然編譯可以通過。Form1不過是Tform1類的一個實例而已。我們現在寫的是一個TForm1的類。這段代碼犯的錯誤就是以偏蓋全，以一個特例去描述一個類，這是典型的白馬非馬論。
最起碼的這句話應該這樣寫B(tài)utton1.Caption:='快速開發(fā)';而最好要寫成Self. Button1.Caption:='快速開發(fā)';這才不會以偏蓋全。
我們要做的事面向對象，而不是基于對象。
要你去寫對一個文件的操作（如DBF文件）你會如何寫呢？
定義一堆結構，寫一堆函數。然后去挨個調用這些函數對文件進行操作。
還是定義一個DBF文件的類，然后把對它的操作都封裝起來，只留下需要調用的函數（如讀、寫）作為公有。
或許第一種方法的代碼要遠遠的少于第二種。但第二種有著第一種方法不可比擬的優(yōu)勢。
1． 思路清晰，更符合人的邏輯思維。而第一種方法更像一盤散沙。
2． 安全可靠，我只把共有函數讓你調用，而其他的都由內部封裝好了，你根本看不見，也不需要考慮它是如何實現的。
3． 方便維護，哪個地方錯了我只要把這個類的相關部分作以下改動即可，不會造成混亂。
好處不止這些。
我的意思是說要多多運用面向對象的方法，不要成為基于對象的工人。
