个人观点随笔-RAD和面向对象

核心提示：个人观点随笔-RAD和面向对象 网上经常有讨论开发工具的优劣性文章，仿佛结果一定是一派要压倒另一派，个人观点随笔-RAD和面向对象，特别是RAD与非RAD的争论，如“VC和BCB哪个更好”、“VC vs Dephi”等等，好处不止这些，我的意思是说要多多运用面向对象的方法， 有人曾经说做一个好的Win32程序员一定要

个人观点随笔-RAD和面向对象   网上经常有讨论开发工具的优劣性文章。仿佛结果一定是一派要压倒另一派。特别是RAD与非RAD的争论。如“VC和BCB哪个更好”、“VC vs Dephi”等等。 　 有人曾经说做一个好的Win32程序员一定要懂得API。虽然Delphi、VB把API封装了起来，简化了编程工作，但也阻碍了成为高手的机会。极力倡导使用VC进行编程。我想之样的人他一定是Win32的编程好手，是VC的熟练工种。但他一定对RAD的开发工具不甚了解，特别是Delphi。（VB暂且先不讨论）。    RAD的开发工具确实入门很简单。拖拽几个控件，写几个事件。一个小程序就做完了。似乎对这个程序是怎样运行的不甚了解。确实造成了一大批人对BCB,Delphi的误解。BCB真简单。我想敢说这样的话的人不是一个刚刚对BCB入门的人，就是一个绝顶的WIN32程序员，对VCL和API很精通的人。第二种人那就无话可说了，他真的有资格说简单。第一种人BCB的VCL不但会方便你的开发，而且他决不会成为你成为高手的机会。如果你精通Object Pascal那么VCL将成为你学习的绝好参考。 　 我要强调的是要多多弄清内部机理，不要成为组件的砌砖奴隶。 　 Nicrosoft的一篇文章写得很好《把面向对象贯彻到底》。很多人用Delphi来做开发只是用到了它的组件提供的功能。很精通，精通什么呢，精通应用组件。现成组件所有功能特性他都会。可离了现成组件他什么也干不了。组件能做的就是他能力的极限。一旦用到相对低阶的API他就束手无策了。认为开发工具不足正是报漏了开发人员自身的不足。抱怨Delphi不能做低阶的事，正报漏了他本身这方面能力的欠缺。如果不是，他完全可以自己去开发、去扩展它。用惯了RAD开发工具不要被它华丽的外表所迷惑而不去探求更深的东西。我常常见到这样写代码的程序员： 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:='快速开发'; end;   end. 　　 画线的的那行代码是有严重的逻辑错误的，虽然编译可以通过。Form1不过是Tform1类的一个实例而已。我们现在写的是一个TForm1的类。这段代码犯的错误就是以偏盖全，以一个特例去描述一个类，这是典型的白马非马论。 最起码的这句话应该这样写Button1.Caption:='快速开发';而最好要写成Self. Button1.Caption:='快速开发';这才不会以偏盖全。 我们要做的事面向对象，而不是基于对象。 要你去写对一个文件的操作（如DBF文件）你会如何写呢？ 定义一堆结构，写一堆函数。然后去挨个调用这些函数对文件进行操作。 还是定义一个DBF文件的类，然后把对它的操作都封装起来，只留下需要调用的函数（如读、写）作为公有。 或许第一种方法的代码要远远的少于第二种。但第二种有着第一种方法不可比拟的优势。 1．  思路清晰，更符合人的逻辑思维。而第一种方法更像一盘散沙。 2．  安全可靠，我只把共有函数让你调用，而其他的都由内部封装好了，你根本看不见，也不需要考虑它是如何实现的。 3．  方便维护，哪个地方错了我只要把这个类的相关部分作以下改动即可，不会造成混乱。 好处不止这些。 我的意思是说要多多运用面向对象的方法，不要成为基于对象的工人。