1. 노인의 이야기
Delphi VS VC는 이미 아주 오래된 주제이지만 여기서는 모두 제 생각입니다. 동의하지 않으시면 웃어주세요.
RAD의 이점은 인터페이스 디자인 측면에서 보면 실제로 Delphi가 VC보다 우수합니다. 색다른 투명 버튼을 작성하고 싶습니다. 델파이에서는 컨트롤을 찾고, 마우스를 클릭하고, 캡션을 수정하기만 하면 됩니다. 이를 완료하려면 최소한 10줄의 코드가 필요합니다. 물론 MFC의 접근 방식을 통해 사람들은 Windows의 기본 원칙을 이해할 수 있지만 OOP의 캡슐화는 개발자가 코드를 작성하기 전에 모든 기본 원칙을 이해해야 합니다. . 저와 대부분의 경우 초보자가 되는 것은 고문입니다. 왜냐하면 그럴 필요가 없기 때문입니다. 예, 개발 기한은 항상 빡빡하고 시간은 결코 충분하지 않습니다. 프로그래머가 Windows 프로그래밍의 모든 측면을 알 것이라고 기대할 수는 없습니다. 어떤 사람은 비디오에 대해 많이 알고 있고 어떤 사람은 네트워킹에 능숙하지만 다재다능하고 좋은 사람은 없습니다. 모든 것이 비현실적이므로 캡슐화가 매우 중요합니다. 새로운 제품을 개발할 때마다 투명한 버튼이나 아름다운 인터페이스에 시간의 30% 이상을 소비해야 한다면 강에 뛰어들 것입니다 :) 인터페이스 측면에서는 델파이가 MFC보다 확실히 낫습니다! 물론 MFC가 아름다운 인터페이스를 디자인할 수 없다는 의미는 아니지만 시간이 너무 오래 걸리고 그럴 가치가 없습니다.
RAD는 정말 혜택이 전부인가요? 어느 것도 아니다. 적어도 초보자에게는 그렇지 않습니다. 프로그래밍이 단지 마우스를 움직이고 프레임을 당기는 것에 불과하다는 오해를 만들기 때문입니다. 최종 결과는 사람들이 델파이는 인터페이스를 작성하는 데에만 사용되며 맨 아래 레이어는 아무 것도 할 수 없다고 생각하게 되기 때문입니다. MFC 프로그래머는 모두 Delphi 프로그래머에 대해 다음과 같이 말하는 것 같습니다. "당신의 프로그램은 아름다운 인터페이스를 갖는 것 외에 또 무엇을 할 수 있습니까?" 사실, DDK 외에 델파이에서 개발할 수 없는 것은 무엇입니까? Delphi에 없는 API 헤더 파일은 무엇입니까? 볼랜드는 변환을 안했는데 JEDI가 변환을 해줬는데, JEDI가 변환을 안 했어도 마찬가지고 C헤더 파일만 주면 변환이 가능하다. 모든 Delphi 프로그래머에게 필요한 문서입니다. 헤더 파일이 변환되면 남은 것은 쓰기를 시작하는 것뿐입니다. MFC가 할 수 있는 일은 Delphi도 할 수 있습니다! 동영상? 회로망? 다이렉트엑스? 오디오? 델파이는 무엇을 할 수 없나요?
2. 하위 프로세스
이벤트를 작성할 때 많은 사람들이 그냥 작성하기 시작하는데, 코드가 얼마나 길든, 얼마나 많은 일을 하든, 이벤트 안에서만 이루어진다면 그 결과는 그냥 머릿속에 적어 두는 것입니다. 코드 조각이 너무 길기 때문에 몇 달 후에 수정하면 시작할 방법이 없습니다. 그렇다면 코드 조각을 분리해 보는 것은 어떨까요? 인간의 주의력은 제한되어 있으므로 한 번에 100줄이 넘는 코드를 읽으면 어지러움을 느낄 것입니다. 델파이 선배들이 제게 한 가지 말씀해 주셨습니다: 모든 프로세스(여기서의 프로세스에는 PROcedure 및 함수가 포함됩니다)가 25줄을 초과해서는 안 됩니다! 이 코드 길이는 머리를 어지럽히지 않으므로 프로세스가 수행하는 작업을 쉽게 이해할 수 있습니다.
그렇다면 원래 이벤트에서 수행된 작업을 어떻게 분해합니까? 많은 방법이 있습니다. 제 경험은 모듈식입니다. 예를 들어, 이벤트에서 수행할 작업이 여러 개인 경우 해당 작업은 서로 다른 하위 프로세스로 변환된 다음 기본 프로세스에서 호출됩니다. 대부분의 주요 프로세스는 일부 판단과 루프로 구성됩니다. 구체적인 구현 프로세스는 없지만 많은 코드 조각이 생성되지만 집중할 수 있습니다!
원칙: 프로세스는 한 가지 일만 수행하며 그 일을 잘 수행합니다.
참조: VCL 소스 코드. VCL 소스 코드를 보면 코드가 25줄을 넘는 경우가 거의 없습니다.
3. 매개변수 이름
SDK를 처음 배웠을 때, 헝가리어 표기법을 보고 어지러웠던 기억이 납니다. 너무 과해요! 기억이 나지 않아요! 그래서 저는 그 발명가를 싫어합니다 :) 마침내 델파이가 등장하고 족쇄를 차고 춤추던 시대는 끝났습니다! Delphi에서 strDoSometing과 같은 변수 이름으로 문자열을 정의하는 것은 터무니없고 불필요합니다. 절차가 짧고 전역 변수가 나타나지 않는 한 이러한 접두사는 필요하지 않습니다. 예를 들어:
절차 SubPro;
var
나는 : 바이트;
너비, 높이 : 정수;
시작하다
너비 := GetWidth;
높이 := GetHeight;
for i:=0 ~ 9 do
시작하다
DrawThread := TDrawThread.Create;
DrawThread.Width := 너비;
DrawThread.Height := 높이;
DrawThread.Start;
끝;
끝;
이러한 코드 세그먼트에는 주석이 없더라도 그것이 무엇을 할 것인지 쉽게 알 수 있다고 생각합니다. 따라서 모든 접두사와 밑줄을 제거하십시오. Delphi 프로그램에는 이러한 것이 필요하지 않습니다! 매개변수 이름에는 동사 + 명사만 필요합니다. 중복되는 내용을 원하지 않습니다. Pascal의 장점은 코드가 천국에서 읽는 것보다 아름답다는 것입니다. . 당신의 머리 속에서, 당신이 생각하는 것은 코드의 모습입니다. 우아함과 심플함, 이것이 파스칼의 장점이니 꼭 지켜주세요!
원칙: 단순함이 아름답다!
4. 하위 창
많은 사람들이 다음과 같이 하위 창을 호출할 때 하위 창의 컨트롤을 직접 조작합니다.
SetAlarmParamDlg.ShowModal = MrOK인 경우
시작하다
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
끝;
맙소사, 만약 내일 사용자들이 당신이 사용하는 Edit나 SpinEdit이 보기 흉해 보인다고 생각하고 그것을 아름다운 컨트롤로 바꾸면 어떻게 하시겠습니까? 서브 윈도우의 코드를 수정해야 할 뿐만 아니라, 메인 폼의 코드도 수정해야 합니다. 물론 하위 창이 1~2개 있는 프로그램은 문제가 되지 않습니다. 하위 창이 20개가 넘는 프로그램이라면 어떨까요? 하루가 걸렸는데 이유는 바로 컨트롤을 바꾸기 위해서였습니다! 다른 방법을 시도해 보는 것은 어떨까요? 사용하려는 매개변수를 나타내기 위해 속성을 사용하면 수많은 코드를 절약하게 됩니다.
//메인폼
SetAlarmParamDlg.ShowModal = MrOK인 경우
시작하다
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
끝;
// 하위폼
인터페이스
사적인
FAlarmTimes : 정수;
FAlarmArea : 정수;
출판됨
속성 AlarmTimes: 정수 읽기 FAlarmTimes 쓰기 FAlarmTimes;
속성 AlarmArea : 정수 읽기 FAlarmArea FAlarmArea 쓰기;
구현
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
ModalResult := MrOK;
...
이런 방식으로 지속하는 한, 하위 창은 자체 작업만 수행하며, 기본 창과 창 사이의 상호 작용은 인터페이스가 변경되지 않은 한 속성을 통해 수행됩니다. 하위 창은 기본 창에 영향을 주지 않습니다. 하위 창의 모양이 어떻게 바뀌든, 컨트롤이 어떻게 바뀌든, 코드가 어떻게 수정되든 전체 프로그램은 동일하게 유지되며 인터페이스만 변경됩니다.
원칙: 하위 창을 모듈화하세요. 창도 클래스입니다. 클래스 간 통신 방법은 창과 통신하는 방법이어야 합니다.