Delphi Tripous

Years ago. There was a rumor. Borland (then) is preparing a “VB killer”. Google “VB killer Delphi” and you'll see what I mean. And then Delphi 1 came out.

Was Delphi 1 the long-roumored “VB killer”? Well, I can't tell for sure. For me, yes it was. I abandoned VB and never looked back.

Delphi, for me, was an apocalypse. You see Delphi provides all, well most of, the code of its library, the VCL. It gives you a tremendous opportunity to see and study code written by the best of best. And thus become a better programmer. It was a valuable tool for me and, I believe, many many others. Thank you Borlanders. Thank you very much.

But that “VB killer” notion is not always the best path to go. You see those modern IDEs like Delphi provide great flexibility and tools in building the user interface at design time. Delphi pushed that idea to a limit. Ok, its nice to have design time facilities like the Component Pallette, the Form Designer and the Object Inspector. Its really productive to be able to drop user interface elements on a window, set them up, connect them, etc etc.

But, hey, what a TDataset or a TTransaction component has to do with building a user interface? Or the TXMLDocument? Come on...

Ok. I understand that its not that bad thing to have a “designable” TTimer or TImageList component. But we have to remember that a (pascalish) IDE should promote best coding practices. What is the best place to have, say, a TQuery component initialized and activated? The Object Inspector or the constructor of a form? Or better the constructor of a business object?

You see when a programmer sets up properties using the Object Inspector he writes code. But that code goes to the .dfm file. Hidden. It's not there in the source code unit, along with the rest of the code, to see it and check it out when you reopen the project six months later.

My point is: User interface elements such as buttons and edit buttons are user interface elements and their place is a form. At design time they controlled by using the Object Inspector. And that's great. Non user interface elements should be created and initialized in a constructor. Most of the time. Non user interface elements are usually part of the business logic. So why not keep business logic code in a single place? Why hide it to a .dfm resource file? Does this technique promote maintainability? Readability of the code? No, in my humble opinion.

After all a programmer is a person who not only writes code, but he reads code too.

posted by Theo Bebekis  # 1:31 AM 0 Comments