1. คำพูดของชายชรา
Delphi VS VC เป็นหัวข้อที่เก่ามากแล้ว แต่ฉันยังอยากพูดถึงมันที่นี่ มันเป็นความคิดเห็นของฉันทั้งหมด หากคุณไม่เห็นด้วยโปรดหัวเราะ
ประโยชน์ของ RAD นั้นมองเห็นได้ง่าย ในแง่ของการออกแบบอินเทอร์เฟซ Delphi นั้นดีกว่า VC ฉันต้องการเขียนปุ่มโปร่งใสที่แหวกแนว ใน Delphi ฉันแค่ต้องค้นหาตัวควบคุม คลิกเมาส์ และแก้ไขคำบรรยายภาพ แล้ว VC ล่ะ? ต้องใช้โค้ดอย่างน้อย 10 บรรทัดเพื่อทำให้สำเร็จ แน่นอนว่าแนวทางของ MFC ทำให้ผู้คนเข้าใจหลักการพื้นฐานของ Windows แต่การห่อหุ้ม OOP นั้นไม่ได้สะท้อนให้เห็นอย่างดีนักถึงหลักการพื้นฐานทั้งหมดก่อนจึงจะสามารถเขียนโค้ดได้ สำหรับฉันและส่วนใหญ่ การเป็นมือใหม่ถือเป็นเรื่องทรมานเพราะไม่จำเป็นต้องทำ ใช่ กำหนดเวลาในการพัฒนานั้นจำกัดอยู่เสมอและเวลาก็ไม่เคยเพียงพอ เราไม่สามารถคาดหวังให้โปรแกรมเมอร์รู้ทุกแง่มุมของการเขียนโปรแกรม Windows ได้ บางคนรู้เรื่องวิดีโอมากและบางคนก็เก่งเรื่องเครือข่าย แต่ก็ไม่มีใครเก่งรอบด้านและเก่งกาจ ทุกสิ่งไม่สมจริง ดังนั้นการห่อหุ้มจึงมีความสำคัญมาก หากฉันต้องใช้เวลา 30% หรือมากกว่านั้นไปกับปุ่มโปร่งใสหรืออินเทอร์เฟซที่สวยงามทุกครั้งที่ฉันพัฒนาผลิตภัณฑ์ใหม่ ฉันจะกระโดดลงแม่น้ำเลย :) Delphi นั้นดีกว่า MFC ในแง่ของอินเทอร์เฟซอย่างแน่นอน! แน่นอนว่าไม่ได้หมายความว่า MFC ไม่สามารถออกแบบอินเทอร์เฟซที่สวยงามได้ แต่เพียงใช้เวลานานเกินไปและไม่คุ้มค่า
RAD เป็นเรื่องเกี่ยวกับผลประโยชน์จริงๆ หรือไม่? ไม่ใช่ทั้งสองอย่าง. อย่างน้อยก็ไม่ใช่สำหรับผู้เริ่มต้น เพราะมันทำให้ผู้คนเข้าใจผิดว่าการเขียนโปรแกรมเป็นเพียงการเลื่อนเมาส์และดึงเฟรมเท่านั้น ผลลัพธ์สุดท้ายคือผู้คนคิดว่า Delphi มีไว้สำหรับเขียนอินเทอร์เฟซเท่านั้น และเลเยอร์ด้านล่างไม่สามารถทำอะไรได้เลย ดูเหมือนว่าโปรแกรมเมอร์ MFC ต่างก็พูดถึงโปรแกรมเมอร์ Delphi: "นอกจากจะมีอินเทอร์เฟซที่สวยงามแล้ว โปรแกรมของคุณทำอะไรได้อีกบ้าง" ผิด! จริงๆ แล้ว นอกจาก DDK แล้ว มีอะไรที่ไม่สามารถพัฒนาใน Delphi ได้บ้าง? ไฟล์ส่วนหัว API ใดที่ Delphi ไม่มี บอร์แลนด์ยังไม่ได้แปลง แต่ JEDI ได้แปลงมันแล้ว แม้ว่า JEDI จะไม่ได้แปลงมันก็ตาม หากคุณทำการแปลงด้วยตัวเอง ตราบใดที่คุณให้ไฟล์ส่วนหัว C แก่ฉัน ฉันสามารถแปลงมันได้ ควรเป็นสิ่งจำเป็นสำหรับเอกสารที่จำเป็นของโปรแกรมเมอร์ Delphi ทุกคน เมื่อแปลงไฟล์ส่วนหัวแล้ว สิ่งที่เหลืออยู่คือเริ่มเขียน สิ่งที่ MFC สามารถทำได้ Delphi ก็สามารถทำได้เช่นกัน! วิดีโอ? เครือข่าย? ไดเร็กเอ็กซ์? เสียง? เดลฟีทำอะไรไม่ได้?
2. กระบวนการย่อย
เวลาเขียน Event หลายๆ คนก็แค่เริ่มเขียนโดยตรง ไม่ว่า Code จะยาวแค่ไหนหรือทำไปกี่อย่างก็ตาม ตราบใดที่ทำใน Event เสร็จก็จดไว้ในหัวเท่านั้น ผลลัพธ์ก็คือ พวกเขาไม่มีทางที่จะเริ่มแก้ไขได้ในอีกไม่กี่เดือนต่อมา เนื่องจากข้อมูลโค้ดยาวเกินไป แล้วทำไมไม่แยกส่วนย่อยของโค้ดออกจากกันล่ะ? ความสนใจของมนุษย์มีจำกัด และคุณจะรู้สึกเวียนหัวหากคุณอ่านโค้ดมากกว่า 100 บรรทัดในครั้งเดียว ผู้อาวุโสของ Delphi บอกฉันอย่างหนึ่ง: กระบวนการทั้งหมด (กระบวนการที่นี่รวมถึง PROcedure และฟังก์ชัน) ไม่ควรเกิน 25 บรรทัด! เนื่องจากโค้ดที่ยาวขนาดนี้จะไม่ทำให้คุณเวียนหัว คุณจึงเข้าใจได้ง่ายว่ากระบวนการกำลังทำอะไรอยู่
แล้วคุณจะแยกสิ่งต่าง ๆ ที่เคยทำกันในเหตุการณ์ออกมาได้อย่างไร? มีหลายวิธี ประสบการณ์ของฉันเป็นแบบแยกส่วน ตัวอย่างเช่น หากมีสิ่งต่างๆ มากมายที่ต้องทำในเหตุการณ์ สิ่งต่าง ๆ จะถูกแปลงเป็นกระบวนการย่อยที่แตกต่างกัน จากนั้นจะถูกเรียกในกระบวนการหลัก ส่วนใหญ่ของกระบวนการหลักคือการตัดสินและการวนซ้ำ และจะมี ไม่มีขั้นตอนการใช้งานที่เฉพาะเจาะจง สิ่งนี้จะสร้างข้อมูลโค้ดจำนวนมาก แต่จะทำให้คุณมุ่งเน้น!
หลักการ: กระบวนการทำสิ่งเดียวเท่านั้นและทำได้ดี
อ้างอิง: ซอร์สโค้ด VCL เมื่อดูซอร์สโค้ด VCL โค้ดจะมีความยาวไม่เกิน 25 บรรทัด!
3. ชื่อพารามิเตอร์
ฉันจำได้ว่าตอนที่ฉันเรียน SDK ครั้งแรก ฉันรู้สึกเวียนหัวเมื่อเห็นสัญลักษณ์ภาษาฮังการี มันมากเกินไป! ฉันจำไม่ได้! ฉันเลยเกลียดนักประดิษฐ์คนนั้น :) ในที่สุดเดลฟีก็ปรากฏตัวขึ้น และวันแห่งการเต้นรำที่ถูกพันธนาการก็จบลง! ใน Delphi การกำหนดสตริงด้วยชื่อตัวแปรเช่น strDoSometing นั้นไร้สาระและไม่จำเป็น ตราบใดที่ขั้นตอนของคุณสั้นและไม่มีตัวแปรร่วมปรากฏ คุณไม่จำเป็นต้องมีคำนำหน้าดังกล่าว ตัวอย่างเช่น:
ขั้นตอน SubPro;
var
ฉัน : ไบต์;
ความกว้าง ความสูง : จำนวนเต็ม;
เริ่ม
ความกว้าง := รับความกว้าง;
ความสูง := รับความสูง;
สำหรับ i:=0 ถึง 9 ทำ
เริ่ม
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 ที่คุณใช้ดูน่าเกลียดและแทนที่ด้วยการควบคุมที่สวยงาม คุณจะทำอย่างไร? คุณไม่เพียงแต่ต้องแก้ไขโค้ดของหน้าต่างย่อยเท่านั้น แต่คุณยังต้องแก้ไขโค้ดของฟอร์มหลักด้วย แน่นอนว่าโปรแกรมที่มีหน้าต่างย่อยหนึ่งหรือสองหน้าต่างจะไม่ทำให้คุณลำบากใจ ใช้เวลาหนึ่งวัน แต่เหตุผลก็คือเพียงเปลี่ยนการควบคุม! ทำไมไม่ลองวิธีอื่นล่ะ? หากคุณใช้แอตทริบิวต์เพื่อแสดงพารามิเตอร์ที่คุณต้องการใช้ คุณจะบันทึกโค้ดได้จำนวนนับไม่ถ้วน
//แบบฟอร์มหลัก
ถ้า SetAlarmParamDlg.ShowModal = MrOK แล้ว
เริ่ม
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
จบ;
//แบบฟอร์มย่อย
อินเตอร์เฟซ
ส่วนตัว
FAlarmTimes : จำนวนเต็ม;
FAlarmarea : จำนวนเต็ม;
ที่ตีพิมพ์
คุณสมบัติ AlarmTimes : จำนวนเต็มอ่าน FAlarmTimes เขียน FAlarmTimes;
คุณสมบัติ AlarmArea : จำนวนเต็มอ่าน FAlarmArea เขียน FAlarmArea;
การดำเนินการ
-
FAlarmTimes := StrToInt (แก้ไข1.ข้อความ);
FAlarmarea := SpinEdit1.Value;
ModalResult := MrOK;
-
ตราบใดที่คุณยังยืนหยัดในลักษณะนี้ คุณจะพบประโยชน์มากมาย หน้าต่างย่อยทำหน้าที่ของมันเองเท่านั้น และการโต้ตอบระหว่างหน้าต่างหลักกับหน้าต่างนั้นจะดำเนินการผ่านคุณลักษณะต่างๆ ตราบใดที่อินเทอร์เฟซยังคงไม่เปลี่ยนแปลง หน้าต่างย่อยจะไม่ส่งผลกระทบต่อหน้าต่างหลัก ไม่ว่ารูปลักษณ์ของหน้าต่างย่อยจะเปลี่ยนไปอย่างไร การควบคุมถูกแทนที่ หรือวิธีการแก้ไขโค้ด โปรแกรมทั้งหมดยังคงเหมือนเดิม มีเพียงอินเทอร์เฟซเท่านั้นที่เปลี่ยนไป
หลักการ: ทำให้หน้าต่างย่อยของคุณเป็นโมดูล Windows ก็เป็นคลาสเช่นกัน วิธีการสื่อสารระหว่างคลาสควรเป็นวิธีการสื่อสารของ windows