20 Rules for Delphi Object-Oriented Programming (by Marco Cantu) (Rule 16-20)

Rule 16: visual form inheritance)
If used properly, this will be a powerful tool. Based on my experience, the larger the project you develop, the more valuable it can be. In a complex program, you can use different levels of forms to process the polymorphism (polymorphism) of a group of related forms ).
Visualized form inheritance allows you to share some common actions of multiple forms: You can use shared methods, common attributes, and even event handlers, components, and component attributes, component event handling methods.

Rule 17: restrict the use of domain data (Limit protected data)
When creating classes with different classification systems, some programmers tend to primarily use protected domains because private data cannot be accessed by quilt classes. I cannot say that this is unreasonable, but it must be incompatible with encapsulation. The implementation of data protection can be shared by all inherited forms, and once the original definition of the data changes, you must change all relevant parts.
Note that if you follow the rule of hiding components (Rule 14), it is impossible to access the private components of the base class by inheriting the form. In an inherited form, code similar to edit1.text: = ''will not be compiled. Although this is quite inconvenient, at least theoretically this is something worthy of recognition, rather than a denial. If you feel that encapsulation is the most important and necessary, put these component references in the private section of the base class.
 

Rule 18: protected access methods)
In the base class, it is better to place the component references in the private domain and add some access functions for these components to get their attributes. If these access functions are only used within these classes and are not part of the class interface, you should declare them in the protected domain. For example, the gettext and settext methods described in rule 11 can be declared as protected, and we can call settext ('') to edit the text.
In fact, when a method is mirrored to an attribute, we can simply use the following code to edit the text: Text: = '';
 

Rule 19: Protect Virtual Methods in the domain (protected virtual methods)
Another key aspect of implementing a flexible classification system is defining virtual methods that you can call from external classes to obtain polymorphism. If this method is used properly, there will be very few other public method calls to protect virtual methods in the domain. This is an important technique, because you can customize the virtual method of the derived class to modify the object action.
 

Rule 20: Virtual Methods for properties)
Even the method for accessing the attribute can be defined as virtual, so that the derived class can change the attribute action without redefining them. Although this method is rarely used in VCL, it is indeed flexible and powerful. To achieve this, you only need to define the get and set methods in rule 11 as virtual. The code of the base class is as follows:

Type Tformdialog = Class (tform) Procedure formcreate (Sender: tobject ); Private Edit1: tedit; Protected Function gettext: string; virtual; Procedure settext (const value: string); Virtual; Public Constructor create (Text: string): reintroduce; overload; Property text: String read gettext write settext; End;

In the inherited form, you can add some additional actions to overload the virtual method settext:
 

Procedure tforminherit. settext (const value: string ); Begin Inherited settext (value ); If value = ''then Button1.enabled: = false; End;

Summary
To make a good Delphi Object-Oriented Programming programmer is far from being as simple as the rules I mentioned above. Some of the above 20 rules may require sufficient patience and time to implement. Therefore, I cannot force you to follow all these rules. However, these rules should be applied to your program as appropriate. The larger the application you develop, the more programmers you participate in. The more important these rules are. However, even some small programs always remember these rules and use them in the right place will be helpful to you.
Of course, there are many other experience rules I have not involved, especially the memory processing and rtti problems, because they are very complicated and need special instructions.
My conclusion is that you will pay a certain price to follow the rules listed above, especially the extra code, but these costs will give you a more flexible and robust program. We hope that later versions of Delphi will help us reduce these costs.