Talking to the object-oriented thinking - talk about Delphi development (the second)

zhaozj2021-02-11  167

(First article)

Think of the object-oriented thought, this topic seems to be big. I just said here, mentioned, actually only some small problems should be paid to when coding. So 'running through the use of this, change to' keep in mind that in mind 'may be more appropriate.

Little comments on certain features of Delphi:

I don't know all the components (including controls) placed in Delphi's Form, which are visible and accurately, these components are the contents of the form of the Form. Such a result is good, because of its flexibility, other classes can easily reference these components on the Form, set their properties, perform their methods, events, etc., but on the other hand it is also obvious. , That is, the loss of packaging of Form. In my opinion, these components placed on Form, in terms of the original meaning of the user, should be existing as the private attribute of the form, and should be invisible for other classes or other forms. Even if you need to access them, you should also access indirect access by providing a series of properties by form.

For example, let everyone have some sense of understanding:

Procedure TFORM1.BUTTON1CLICK (Sender: TOBJECT);

Begin

Form2.edit1.text: = 'abc'; // <- This sentence is written, I don't agree.

END;

Maybe many people have such code, there is no package in the mind, but you have seen this article, you don't do this, you will do something like this (change evil.!). In my opinion, TFORM1 is TFORM1, TFORM2 is TFORM2, which are all existing for certain features, so they provide some interfaces to the outside world (some attributes, methods, and events, event say strictness, also attributes ) To achieve the features they commit to themselves. As for the specific implementation of these interfaces, they should be maintained by themselves, and the outside world is not necessary, and there is no way to intervene. This idea, correspond to practical applications, that is, Form2.edit1 is necessary to be directly accessed by from1. I personally tend to be the implementation below:

/ / The following is part of TFORM1 in Unit1

Procedure TFORM1.BUTTON1CLICK (Sender: TOBJECT);

Begin

TFORM2 (FANOTHERFORM) .edittext: = 'abc'; // <- This implementation reflects the idea of ​​packaging

END;

/ / The following is the definition of TFORM2 in Unit2

Type

TFORM2 = Class (TFORM)

EDIT1: TEDIT;

Private

Function startText: string;

Procedure setEditText (const value: string);

public

Property EditText: String Read atText Write setTETTEXT;

// <- my recommended usage;

END;

......

Function TFORM2.GETEDITTEXT: STRING;

Begin

Result: = Edit1.Text;

END;

Procedure TFORM2.SETEDITTEXT (Const value: String);

Begin

IF value <> EditText Then

Edit1.Text: = Value;

End; FANOTHERFORM here is a private property of TForm1, which is a pointer to one instance of TFORM2 (this usage emphasizes in the first article). Access TFORM2's edittext attribute, not a reckless direct access to TFORM2's edit1.text, reflecting a kind of thought, that is, the idea of ​​dividing labor collaboration, that is, the idea of ​​the independence, which is the idea of ​​encapsulation.

(Until it, to be continued)

More articles

转载请注明原文地址:https://www.9cbs.com/read-5330.html

New Post(0)