Rule 1: Create a unit for each class (One Class, One Unit)
Always keep this in mind: the private (PRivate) and protected (protected) parts of a class are hidden only from classes and procedures in other units. Therefore, if you want effective encapsulation, you should provide each A class uses a different unit. For some simple classes, such as those that inherit from other classes, you can use a shared unit. However, the number of classes that share the same unit is limited: don't put more than 20 complex classes in a simple unit
Rule 2: Name Components
It's also important to use descriptive names for components. The most common way to name is to start with a lowercase letter of the class, plus the function of the component, such as BtnAdd or editName.
Rule 3: Name Events
It is even more important to give appropriate names to event handling methods. If you give the component an appropriate name, the system default name ButtonClick will become BtnAddClick. Although we can guess the function of this event handler from the name, I think it is a better way to use a name that describes the function of the method rather than using the name attached by Delphi. For example, the OnClick event of the BtnAdd button can be named AddToList. This will make your program more readable, especially when you call the event handler in other methods of the class, and it will help programmers choose the same method for similar events or different components.
Rule 4: Use Form Methods
Forms are classes, so the code of the form is organized by methods. You can add event handlers to a form. These handlers perform special functions, and they can be called by other methods. In addition to event handling methods, you can add specially defined methods to a form for completing actions and methods for accessing form state. It is better to add some public (Public) methods to the form for other forms to call than for other forms to directly operate its components.
Rule 5: Add Form Constructors
The second form created at run time provides special constructors in addition to a default constructor (inherited from the Tcomponent class).
I suggest you overload the Create method and add the necessary initialization parameters. The specific code can be found in the following code:
Public
Constructor Create(Text:string): reintroduce; overload;
Constructor TformDialog.Create(Text:string);
Begin
Inherited Create(application);
Edit1.Text:=Text;
End;
Rule 6: Avoid Global Variables
Global variables (those defined in the interface section of a unit) should be avoided. Below are some suggestions on how to do this.
If you need to store additional data for a form, you can add some private data to the form class. In this case, each form instance will have its own copy of the data. You can use unit variables (variables defined in the implementation section of the unit) to declare data that is shared by multiple instances of a form class.
If you need to share data between different types of forms, you can define them in the main form to achieve sharing, or use a global variable, use methods or properties to obtain data.
Rule 7: Never use Form1 inside the Tform1 class
You should avoid using a specific object name in the methods of the class. In other words, you should not use Form1 directly in the methods of the TForm1 class. If you really need to use the current object, you can use the Self keyword.
Rule 11: Expose Components Properties
When you need to access the state of another form, you should not access its components directly. Because this will combine the code of other forms or other classes with the user interface, and the user interface is often the most changeable part of an application. The best approach is to define a form property for the component property you need to access. To achieve this, you can use the Get method to read the component status and the Set method to set the component status.
If you now need to change the user interface and replace an existing component with another component, then all you need to do is modify the Get method and Set method related to the properties of this component, without having to find and modify all the forms that reference this component. and class source code. For detailed implementation methods, please see the code below:
private
function GetText:String;
procedure SetText(const Value:String);
public
property Text:String;
read GetText write SetText;
function TformDialog.GetText:String;
begin
Result:=Edit1.Text;
end;
procedure TformDialog.SetText(const Value:String);
begin
Edit1.Text;=Value;
end;
Rule 16: Visual Form Inheritance
If applied correctly, this can be a powerful tool. According to my experience, the larger the project you develop, the more valuable it is. In a complex program, you can use different hierarchies of forms to handle polymorphism in a group of related forms.
Visual form inheritance allows you to share some common actions of multiple forms: you can use shared methods, common properties, even event handlers, components, component properties, component event handling methods, and so on.
For more information, please see: http://lincosoft.go.nease.net/