(첫번째 글에서 이어집니다)
전체적으로 객체 지향적 사고를 유지하면서 이 주제는 좀 큰 것 같습니다. 제가 방금 말하고 언급한 내용은 실제로 코딩 시 주의해야 할 몇 가지 사소한 문제일 뿐입니다. 따라서 '전체적으로'라는 표현을 '유념하다'로 바꾸는 것이 더 적절할 수 있습니다.
Delphi의 일부 기능에 대한 의견:
Delphi 양식에 배치된 모든 구성 요소(컨트롤 포함)가 다른 양식에서도 표시된다는 사실을 알고 계셨는지 궁금합니다. 정확하게 말하면 이러한 구성 요소는 양식의 공개 부분에 대한 내용입니다. 한편으로는 이 결과는 유연성 때문에 다른 클래스가 쉽게 Form에서 이러한 구성 요소를 참조하고 해당 속성을 설정하고 해당 메서드, 이벤트 등을 실행할 수 있다는 점에서 좋은 결과입니다. 그러나 다른 한편으로는 결함도 분명합니다. 예, 그러면 Form의 캡슐화가 손실됩니다. 내 생각에는 사용자의 의도에 관한 한 Form에 배치된 이러한 구성 요소는 Form의 개인 속성으로 존재해야 하며 다른 클래스나 다른 Forms에 표시되어서는 안 됩니다. 접근이 필요하더라도 Form에서 제공하는 일련의 속성 메소드를 통해 간접적으로 접근해야 합니다.
모든 사람에게 지각적 이해를 제공하기 위해 예를 들어보세요.
PROcedure TForm1.Button1Click(Sender: TObject);
시작하다
Form2.Edit1.Text := 'abc'; // <-- 이 문장의 작성 방식에 동의하지 않습니다.
끝;
많은 사람들이 이러한 코드를 작성할 때 캡슐화 개념을 염두에 두지 않을 수도 있지만 이 기사를 읽고 나면 다시는 그런 일을 하지 않을 것입니다(방식을 바꾸십시오!). 제 생각에는 TForm1은 TForm1이고, TForm2는 TForm2입니다. 이들은 모두 특정 특정 기능을 달성하기 위해 존재하므로 외부 세계에 대한 일부 인터페이스(일부 속성, 메소드 및 이벤트. 엄밀히 말하면 이벤트도 속성입니다.)를 제공합니다. 약속된 기능을 달성합니다. 이러한 인터페이스의 구체적인 구현은 자체적으로 유지 관리되어야 하며 외부 세계가 개입할 필요도 없고 방법도 없습니다. 이 아이디어는 실제 응용 프로그램, 즉 Form2.Edit1에 From1이 직접 액세스해야 하는지 여부에 대한 질문에 해당합니다. 나는 개인적으로 다음 구현을 선호합니다.
//다음은 Unit1의 TForm1 내용의 일부입니다.
절차 TForm1.Button1Click(Sender: TObject);
시작하다
TForm2(FAnotherForm).EditText := 'abc'; // <-- 이 구현은 캡슐화 아이디어를 구현합니다.
끝;
//다음은 Unit2의 TForm2 정의입니다.
유형
TForm2 = 클래스(TForm)
편집1: T편집;
사적인
함수 GetEditText: 문자열;
프로시저 SetEditText(const 값: 문자열);
공공의
속성 EditText: 문자열 읽기 GetEditText 쓰기 SetEditText;
// <-- 내가 권장하는 사용법;
끝;
…
함수 TForm2.GetEditText: 문자열;
시작하다
결과 := Edit1.Text;
끝;
절차 TForm2.SetEditText(const 값: 문자열);
시작하다
값 <> EditText이면
편집1.텍스트 := 값;
끝;
여기서 FAnotherForm은 TForm2의 인스턴스에 대한 포인터인 TForm1의 개인 속성입니다(이 사용법은 첫 번째 기사에서 강조되었습니다). TForm2의 Edit1.Text에 무작정 직접 접근하는 대신 TForm2의 EditText 속성에 접근하는 것은 아이디어, 즉 노동의 분업과 협업의 아이디어, 즉 독립의 아이디어, 즉 캡슐화.
(미완성, 계속)
더 많은 기사