There are many people in China to use Delphi as the preferred development tool. The reason is of course because Delphi provides developers with a number of features: object-oriented development, visual interface design, rich components, portable portability (new features of Delphi6).
However, for beginners, object-oriented ideas may not be the biggest feelings that Delphi will bring. The visual interface is designed, rich and diverse can be impressed with the most unforgettable impression. The serious consequences of this is that beginners are often in a long time, and only pay attention to the existing VCL components provided by Delphi, and ignore the object-oriented ideas for Delphi's entirety. The meaning of the component architecture system is contained.
One of the following sections contains the most common, and an error that is the most easy to commit. This error is not a grammar error, but it reveals that the user's object-oriented idea is to be strengthened:
Var Form1: TFORM1;
IMPLEMentation
{$ R * .dfm}
Procedure TForm1.Button1Click (Sender: TOBJECT); Begin ShowMessage (Form1.caption); // <- Some problems with the Form1 here. END;
Such a code, the thick look doesn't seem to be wrong. However, here, the appearance of FORM1 is somewhat saying. Obviously the code here, the implementation of the TForm1's ButtonClick method, and Form1 acts as an instance of TForm1 classes, is actually written to the implementation of the class, isn't it a single concept confusion? To change to object-oriented thinking, It is also very simple, there can be two ways:
1. ShowMessage (Self.caption); // <- This method is very clear, the information to show is the CAPTION of the current instance of the class.
2. ShowMessage (CAPTION); // <- The write method here and the above-mentioned mini, omitted the keyword Self;
The three major core contents of object-oriented ideas are packaged, inherited, and polymorphism. The problem of exposure of the above examples is the problem of packaging. Similar examples are:
VAR
FORM1: TFORM1;
......
VAR
Form2: TFORM2;
Procedure TFORM1.BUTTON1CLICK (Sender: TOBJECT);
Begin
Form2.show; // <- As a global variable, FORM2 is also confusing here.
END;
The above examples may be more universal, for most cases, in one project, TFORM1, and TFORM2 may only have one example, so this code is also a horse to pass. But from strict sense, it is also a request for encapsulation. Refer to the following code:
type TForm1 = class (TForm) Button1: TButton; procedure Button1Click (Sender: TObject); private {Private declarations} FNext: TForm; public {Public declarations} property NextForm: TForm read FNext write FNext; end;
Var Form1: TFORM1;
IMPLEMentation
Uses unit2;
{$ R * .dfm}
Procedure TFORM1.BUTTON1CLICK (Sender: Tobject); Begin if Assigned (Fnext) .Show; End;
/ / The following is the content in the project file:
PROGRAM Project1;
Uses form, unit1 in 'unit1.pas' {form1}, unit2 in 'unit2.pas' {form2};
{$ R * .res}
Begin Application.INITIALIZE; Application.createform (TFORM1, FORM1); Application.createform (TFORM2, FORM2);
Form1.nextform: = form2; // <- Increase this, barely let the code meet the requirements of the package
Application.run; end.
Put the Form2 pointer, as a property of Form1, passed to Form1, so that Form1 complies with the principles of encapsulation when calling! Of course, these code is just to reflect the idea of packaging, and in practice, it can determine whether it is really trying to do with personal habits. But this kind of thought should be rooted in your mind ... (until it is finished).
More articles
