20 Rules of Delphi Object-Oriented Programming (by Marco Cantu)

introduction
Marco Cantu is a well-known Delphi expert. He has published a series of "proficient Delphi" books, delphi development manual and e-book proficient Pascal (this e-book is available for free online ). He teaches basic and advanced development skills in Delphi. You can get more information about him through his website (www.marcocantu.com), or contact him through his public news group. For more information, see his website.

preface
most Delphi Program workers use their hands as they do with Visual Basic. development tools, you are not aware of the powerful functions of Delphi, let alone using these functions. (Here, the editor raised his hand with fear. How can this problem be solved ?) Different from Visual Basic, Delphi is fully built on the object-oriented structure, which not only affects the VCL structure, but also affects every program developed using Delphi.
In this article, I don't want to involve all theories of Object-Oriented Programming (OOP), but I just propose some simple empirical rules. We hope these rules can help improve your program structure. No matter what type of programs you develop, these empirical rules apply. You should take them as some suggestions, remember them, and apply them to your programs.
encapsulation is a key principle I want to emphasize about object-oriented programming. We all want to create some flexible and robust classes, because such classes allow us to modify their implementation methods in the future without affecting other parts of the program. This is the benefit of encapsulation. Although encapsulation is not the only standard for creating a good object-oriented program, it forms the basis of Surface object programming. Therefore, in this article, I may emphasize encapsulation too much, don't be surprised. I have enough reason to do this.
finally, I want to explain the fact that this article focuses on the development of forms (although some of these rules are also applicable to component development ), therefore, these rules are applicable to all Delphi programmers. Programmers who write components must take the surface object programming and class as the core elements, but those who use component programming often forget the object-oriented. This article serves as a prompt to remind them to always remember object-oriented programming.

Part 1: form is a class (Rule 1-rule 15)
Programmers often regard the form as an object, while the form is actually a class. The difference between the two is that you create multiple form Objects Based on the same form class. It is confusing that Delphi creates a default Global Object for each form class you define. This is quite convenient for new users, but it will also lead to bad habits.

Part 2: inheritance (inheritance) (Rule 15-rule 20)
After talking about a series of rules about classes, especially about form classes, the second part will be some suggestions and tips on class inheritance and visual form inheritance.

AboutCode
All the code segments in this article can be found in the oopdemo project on the disk attached to this magazine (the Delphi magazine issue 47. In particular, you should check the frm2 unit and inher unit in the routine. If you want to use the code, pay attention to the necessary initialization settings and private component references of the constructor, and set the oldcreateorder attribute of the form. Otherwise, the initialization code of the form constructor with components will be executed before the oncreate event of the form.
On this disk, you can also find the first version of the compilation package of the OOP Form Wizard, but I want you to visit my website to obtain a more complete version of the program.