Delphi随笔一

一、老生长谈
    Delphi VS VC已经是很古老的话题了，但是我还是想在这里谈一下，全是一家之言，如果不同意，请一笑之。
    RAD的好处是很易见的，界面的设计上Delphi实在是高过VC。我要写一个非常规的透明按钮，Delphi只要找个控件，点一下鼠标，修改一下Caption就OK了，VC呢？至少要写上10几行代码才能搞定，当然MFC的做法让人了解windows底层的原理，但是OOP的封装性没有很好的体现，开发者要了解所有的底层才能写代码，对我对大多数的入门者是个折磨，因为没必要，现在是开发期限永远紧张，时间永远不够，我们不能指望程序员知道Windows编程的所有的方面，有人对视频很了解，有人对网络很在行，但是没有人是全才，样样在行是不现实的，所以封装是很重要的。如果每次开发新产品我都要在一个透明按钮或者一个漂亮的界面上花30%甚至更多的时间，那我就去跳河：）Delphi在界面上的确比MFC好！当然不是说MFC就设计不出漂亮的界面，只是花费的时间太长，不值得。
    RAD就真的全是好处？也不是。至少对于初学者不是，因为它让人误会编程只是动动鼠标，拉拉框架，最后的结果就是让人觉得，Delphi就是用来写界面的，底层什么都不能做。好像MFC程序员都是这么讲Delphi程序员的：“你们的程序除了界面漂亮，还能做什么？”错！其实除了DDK，Delphi什么不能开发？API的头文件Delphi哪个没有？Borland没有转换的，JEDI都转换了，即使JEDI没有转，自己动手也是一样的，只要给我C的头文件，我就可以转换，JEDI上那篇短短的转换说明应该是每个Delphi程序员的必备文档。头文件转换了，剩下的就是开写了，MFC能做的，Delphi也可以！视频？网络？directx？Audio？哪个Delphi不能做？

二、子过程
    写一个事件，很多人就是直接开写，不管代码有多长，做的事情有多少，只要是在一个事件里做的，一古脑写下去，结果是几个月后重新修改的时候无从下手，因为代码段实在太长了。那么为什么不把代码段拆开呢？人的注意力有有限的，超过100行的代码一口气看下来会晕的，Delphi的前辈告诉我一件事情：所有的过程（这里的过程包括PRocedure和function）不要超过25行！因为这个长度的代码看起来不会让你头晕，你会很容易了解这个过程要做的事情。
    那么怎么把原本在一个事件做的事情拆开呢？方法很多，我的经验是模块化。比如一个事件里要做很多不同的事情，那么就把不同的事情化为不同的子过程，然后在主过程里调用，主过程里大多数就是一些判断和循环，不会出现具体的实现过程，这样会生出很多的代码段，但是会让你的注意力集中！
    原则：一个过程只做一件事情，并且做好它。
    参考：VCL的源代码。看看VCL的源代码，很少有超过25行的代码段！

三、参数名
    记得当初学SDK的时候，我一看到匈牙利表示法就头晕，太多了！记不住啊！所以我恨那个发明者：）终于Delphi出现了，戴着镣铐跳舞的日子过去了！在Delphi里，定义一个字符串用strDoSometing这样的变量名是可笑的和不必要的。只要你的过程很短，不出现全局变量，就不需要这样的前缀。比如：
procedure SubPro;
var
  i : byte;
  Width, Height : integer;
begin
  Width := GetWidth;
  Height := GetHeight;
  for i:=0 to 9 do
  begin
    DrawThread := TDrawThread.Create;
    DrawThread.Width := Width;
    DrawThread.Height := Height;
    DrawThread.Start;
  end;
end;
    我想这样的代码段虽然没有注释，也很容易知道他要做的事情。所以，请去掉所有的前缀和下划线，Delphi的程序不需要这些！我们的参数名只要动词+名词就可以，只要说明这个参数的作用就可以，多余的东西我们不要，简单就是美，Pascal的好处就在于代码像在说话，而不是读天书，你的脑袋里是怎么想的，代码就是什么样子的。优美、简单，这是Pascal的好处，请遵守！
    原则：简单就是美！

四、子窗口
    很多人在调用子窗口的时候是直接对子窗口里的控件操作的，比如：
  if SetAlarmParamDlg.ShowModal = MrOK then
  begin
    AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
    AlarmArea  := SetAlarmParamDlg.SpinEdit1.Value;
  end;
    天，假如明天用户觉得你用的Edit或者SpinEdit的样子难看，换了一个漂亮的控件，你怎么办？不但要修改子窗口的代码，还要修改主窗体的代码。一两个子窗口的程序当然不会让你痛苦，假如是一个有二十多个子窗体的程序呢？花一天的时间，原因却只是因为换了一个控件！为什么不换一个方法？把要用的参数用属性表示，你会少写无数的代码。
// 主窗体
  if SetAlarmParamDlg.ShowModal = MrOK then
  begin
    AlarmTimes := SetAlarmParamDlg.AlarmTimes;
    AlarmArea  := SetAlarmParamDlg.AlarmArea;
  end;

// 子窗体
interface
private
  FAlarmTimes : integer;
  FAlarmArea : integer;
published
  property AlarmTimes : integer read FAlarmTimes write FAlarmTimes;
  property AlarmArea : integer read FAlarmArea write FAlarmArea;

implementation
...
  FAlarmTimes := StrToInt(Edit1.Text);
  FAlarmArea := SpinEdit1.Value;
 
  ModalResult := MrOK;
...

    只要这样坚持下来，你会发现好处大大的，一个子窗口只做他自己的事情，主窗口和他的交互是通过属性来做的，只要接口不变，子窗口的修改不会影响到主窗口的代码，不管子窗口的样子怎么变换，控件怎么更换，代码怎么修改，整个程序都还是老样子，只是界面变了而已。
    原则：模块化你的子窗口，窗口也是类，类之间怎么通信，窗口之间就应该怎么通信