Rule 1: Create a unit (One Class, One Unit) for each class, keep this: Private and protection (Protected) part only for classes and processes in other cells (procedure) Hidden. So if you want to get effective encapsulation, you should use a different unit for each class. For some simple classes, such as those that inherit other classes, you can use a shared unit. However, the number of classes that share the same unit is limited: don't place more than 20 complex classes in a simple unit, although Borland's VCL code has been doing so. If you use a form, Delphi will default to follow the rules of "a class using a unit", which is also very convenient for programmers. When you add a class without a form to your project, Delphi creates a new independent unit.
Rule 2: It is important to give each form and unit for each form and unit. The names of the form and unit must be different, but I tend to use similar names for them, such as using AboutForm and About.PAS for them, using the descriptive name for the component. It is also very important. The most common naming method is to start using the lowercase of the class, plus the components, such as btnadd or editname. With this naming method, there will be a lot of similar names for component naming, and there is no best name. In the end, it should be chosen that should be based on your personal hobbies.
Rules 3: Name Event is more important for event processing methods to give appropriate names. If you give a proper name for the component, the system default name ButtonClick will turn btnaddClick. Although we can guess the function of this event handler from this name, I think it is a better way to use a name that describes the role of the method, not the name of Delphi attached is a better way. For example, the BTNADD button's onclick event can be named ADDTOLIST. This will make your program more readable, especially when you call this event handler in other methods of this class, and this helps programmers use the same way to similar events or different components. But I have to declare that the action (Actions) is my favorite approach when developing important procedures.
Rules 4: Use Form Methods Forms All class, so the form of the form is organized in methods. You can add event handlers to the form that completes some special features, and they can be called by other methods. In addition to the event handling method, you can add a specially defined method for the form and a method of accessing the form state. Add some public (public) methods to other forms to other forms to do his components directly than other forms.
Rules 5: Add Form Constructors, the second form created at runtime, except for a default constructor (inherited from Tcomponent class), other special constructors will also provide other special constructors. If you don't need to consider compatibility with Delphi4 previous version, I suggest you overload CREATE method to add the necessary initialization parameters. 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 (Avoid Global Variables) It should be avoided using global variables (that is, those defined in the unit's interface part). There will be some suggestions to help you do it. If you need to store additional data for the form, you can add some private data to the form class. In this case, each form instance has its own copy of the data. You can use unit variables (variables defined in units of the unit) declare those shared by multiple instances of the form. 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, how to use methods, or attributes to get data.
Rule 7: Never use Form1 in the TForm1 class (Never USE Form1 in TForm1) You should avoid using a specific object name in the class, in other words, you should not use Form1 directly in the TForm1 class. If you really need to use the current object, you can use the Self keyword. Keep in mind: Most of you don't have to use the method and data of the current object directly. If you don't follow this rule, when you create multiple instances for a form class, you will fall into trouble.
Rules 8: Try to avoid using Form1 in other forms, even in other forms of form, you should try to avoid direct use of global variables, such as Form1. Define some local variables or private domains For other forms, it will be better than the direct call global variable. For example, a program's main form can define a private domain for a dialog. Obviously, this rule will be very useful if you plan to create multiple instances for a derived form. You can keep a list within the code range of the main form, or you can easily use the form an array of global SREEN objects.
Rules 9: Remove Form1 (Remove Form1) In fact, my suggestion is to remove the global form object that Delphi automatically created in your program. This is also possible even if you prohibit the automatic add function of the form, because this form may still be added in Delphi. The suggestion for me to give you should try to avoid using a global form object. I think it is useful for Delphi's newcomers, which is useful to remove global form objects so that they are not confused about the relationship between classes and global objects. In fact, after the global form object is removed, all the code related to it will generate errors.
Rules 10: Add form property, as I have mentioned, when you need to add data to your form, add a private domain. If you need to access other classes, you can add properties to your form. Using this method You can change the code and data of the current form (included in its user interface) without having to change the code of other forms or classes. You should also use attributes or methods to initialize the partial form or dialog, or access their final state. As I said earlier, you should use the constructor to complete the initialization work.
Rules 11: Display Component Properties When you need to access other forms, you should not directly access its components. Because this will combine other forms or other classes and user interfaces, and the user interface is often the most prone to change in an application. The best way is to define a form properties for the component properties you need to access. To achieve this, you can implement the set method of the component state and the set method of setting component status. If you need to change the user interface now, replace existing components with another component, then you only need to modify the GET method and SET method related to this component properties, do not have to look up, modify all references to this component. Source code for class. See the detailed implementation method of the following code: 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;
Rule 12: ARRAY Properties If you need to handle a series of variables in the form, you can define an attribute array. If these variables are some information about the form, you can also define them to form an array of properties of the form, so you can use Specialform [3] to access their values directly. The following code shows how to define an item of a ListBox component into a form default attribute array.
type TformDialog = class (TForm) private listItems: TlistBox; function GetItems (Index: Integer): String; procedure SetItems (Index: Integer: const Value: String); public property Items [Index: Integer]: string; end; function TFormDialog .GetItems (Index: Integer): string; begin if Index> = ListItems.Items.Count then raise Exception.Create ( 'TformDialog: Out of Range'); Result: = ListItems.Items [Index]; end; procedure TformDialog. Setitems (index: integer; const alue: string); begin if index> = listitems.items.count the Raise Exception.create ('tformdialog: out of range'); ListItems.Items [index]: = Value;
Rules 13: Use the Additional Side-Effects In Properties to remember: One of the benefits of using properties instead of accessing global variables (see Rule 10, 11, 12) is to set or read the value of the attribute. When you may not intend to gain. For example, you can directly drag the components directly on the form interface, set the value of multiple properties, call special methods, change the state of multiple components, or revoke an event (if needed), etc.. Rule 14: Hide Components I often hear those mad pursuits that are object-oriented to the Delphi form that contains some components declared in the Published part, which is incompatible with the encapsulation principle of object-oriented ideas. They did put forward an important topic, but most people in them did not realize that the solution was actually on their hand, without rewriting the Delphi code, nor will they turn to other languages. The components added to the form can be moved to the Private section such that other forms cannot access them. If you do this, you will need to set some form properties to the component (see Rule 11) and use them to access the status of the component. Delphi puts all of these components in the Published section, because this way can ensure that these domains must be created in the .dfm file. When you change the name of a component, VCL can automatically associate this component object with it in the form. Because Delphi uses the RTTI and TOBJECT methods to implement this function, if you want to use this automatic implementation, you must place the reference to the Published section (this is why Delphi puts all the components in the Published part. ). If you want to know more details, please refer to the following code:
procedure Tcomponent.SetReference (Enable: Boolean); var Field: ^ Tcomponent; begin If Fowner <> nil then begin Field: = Fowner.FieldAddress (Fname); If Field <> nil then Field ^: = Self else Field ^: = NIL; end;
The above code is the SetReference method for the Tcomponent class, which can be called by INSERCOMPONENT, REMOVAMPONENT, and SETNAME. When you understand this, you should not think that if you move the component reference from the Published section to the privated segment, you will lose the automatic accessibility of the VCL. In order to solve this problem, you can add the following code in the form's oncreate event: edit1: = findcomponent ('edit1') as tedit; you should do next is to register these components in the system, when you are After they registered, they can enable RTTI into the compiler and can be used by the system. When you move these types of components to the Private section, you only need to register them once for each component class. Even when registration is not necessarily necessary, you can do this because additional calls for RegisterClasses are beneficial. Usually you should be responsible for generating the initialization section of the form to generate the following code: RegisterClass ([TEDIT]); Rules 15: Object-Oriented Form Wizard (The OOP Form Wizard) for each component of each form Repeating the above two operations are not only very annoying, but also quite wasting time. In order to avoid additional burden, I have written a simple wizard program for this. This program will generate some code that can complete the above two steps, and you need to do it several times to copy and paste it. Unfortunately, this wizard program cannot automatically place the code in a suitable place in the unit. I am currently modifying this wizard, I hope to implement this feature. You can find more complete programs to my website (www.marcocantu.com).
