โดยปกติแล้วเรามักจะเขียนโค้ดจำนวนมากเพื่อบริษัท เพื่อตัวเราเองหรือเพื่อเพื่อน บางครั้งเพื่อยืนยันความคิดของตนเองหรือเพื่อการเรียนรู้
สำหรับเทคโนโลยีบางอย่าง จะมีการเขียนโค้ดการทดลองบางอย่าง วงจรชีวิตของโค้ดดังกล่าวสั้นมากและโดยพื้นฐานแล้วไม่ต้องการการบำรุงรักษา คุณสามารถเขียนมันได้ตามที่คุณต้องการ
โดย. อย่างไรก็ตาม เมื่อคุณต้องการทำให้ PProject เสร็จสมบูรณ์ การออกแบบโค้ดมีความสำคัญมาก เพราะโค้ดดังกล่าวต้องใช้ระยะยาว
การบำรุงรักษา การดัดแปลงหรือการปรับปรุงอย่างต่อเนื่อง การออกแบบโค้ดที่ยุ่งเหยิงทำให้การบำรุงรักษาทำได้ยากหรือเป็นไปไม่ได้
สิ่งนี้จะนำไปสู่ข้อบกพร่องหรือภัยพิบัติมากขึ้น
เนื่องจากการออกแบบโค้ดมีความสำคัญมาก เราจึงไม่สามารถเพิกเฉยได้ แล้วคุณจะออกแบบโค้ดของคุณอย่างไร? เทคนิคการเขียนโปรแกรมเชิงวัตถุสามารถช่วยได้
ช่วยเราด้วย ตรงนี้ เพื่ออธิบายให้เข้าใจง่าย โปรแกรมเมอร์จำนวนมากสับสนระหว่างเทคโนโลยีการเขียนโปรแกรมเชิงวัตถุ (OOP) กับเทคโนโลยีเชิงวัตถุ (OO) ทันที
จากความเข้าใจของฉันเอง เทคโนโลยีเชิงวัตถุเป็นความรู้ที่กว้างและลึกซึ้ง มันเป็นวิธีการหรือมุมมองโลก ในขณะที่เทคโนโลยีเชิงวัตถุเป็นวิธีการหรือมุมมองโลกประเภทหนึ่ง
เทคนิคการเขียนโปรแกรมเชิงวัตถุช่วยให้สามารถใช้การเขียนโปรแกรมเชิงวัตถุเมื่อเขียนโค้ดได้
ต่อไปนี้เป็นประสบการณ์ของผู้เขียนหลังจากอ่านหนังสือที่เกี่ยวข้องและแบบฝึกหัดประจำวันแล้ว และหวังว่าจะแบ่งปันกับคุณ
ขั้นแรก ให้แยกโค้ดอินเทอร์เฟซและโค้ดการทำงานออกจากกัน หลักการหนึ่งที่ต้องจำไว้คือไม่ต้องเขียนตรรกะการทำงานที่ซับซ้อนในโค้ดอินเทอร์เฟซ
รหัสเข้า ไฟล์การใช้งานของแบบฟอร์มอินเทอร์เฟซใช้เพื่อจัดเก็บโค้ดอินเทอร์เฟซเท่านั้น และแยกโค้ดการทำงานที่ซับซ้อน ขอยกตัวอย่างง่ายๆว่า
สมมติว่าคุณต้องการรับรายการสตริงจากที่ไหนสักแห่งแล้วแสดงใน TListBox รหัสนี้น่าเชื่อถือ:
ObjectXXX := TObjectXXX.สร้าง;
ListBox1.Items := ObjectXXX.GetStringList;
ObjectXXX.ฟรี;
ด้วยวิธีนี้ ตรรกะที่ซับซ้อนของการได้รับรายการสตริงจะถูกห่อหุ้มไว้ในโค้ดการใช้งานของคลาส TObjectXXX และคำจำกัดความของคลาสนี้สามารถเป็นได้
และการนำไปใช้งานจะอยู่ในไฟล์ .pas แยกจากกันเพื่อการบำรุงรักษาที่ง่ายดาย การแยกโค้ดอินเทอร์เฟซและโค้ดการทำงานมีประโยชน์อีกอย่างหนึ่ง
โค้ดการใช้งานของฟังก์ชันอาจถูกเรียกโดยโมดูลอินเทอร์เฟซหลายตัว หากคุณคัดลอกโค้ดการใช้งานฟังก์ชันเมื่อจำเป็น
คุณจะมีโมดูลที่เหมือนกันหลายโมดูลที่ต้องบำรุงรักษา หากคุณต้องการแก้ไข ฮ่าๆ แทบจะเป็นไปไม่ได้เลยที่จะรับประกันว่าคุณจะไม่ทำผิดพลาด
ประการที่สอง ทำให้ตรรกะของแต่ละโมดูลเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ ประสบการณ์บอกเราว่าตรรกะที่ซับซ้อนเกินไปจะทำให้ผู้คนเข้าใจได้ยาก
ภัยพิบัติ. ดังนั้น ควรทำให้โค้ดของแต่ละโมดูลเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ โดยทั่วไปแล้วจะมีความยาวโค้ดไม่เกิน 25 บรรทัด เมื่อคุณพบว่าตรรกะที่คุณเขียนมีแนวโน้ม
ซับซ้อน ถึงเวลาที่คุณต้องมองหาวัตถุและดูว่าคุณสามารถแยกตรรกะบางส่วนออกได้หรือไม่
สุดท้ายนี้ ให้ความสนใจกับการตั้งชื่อตัวแปร ตรวจสอบซอร์สโค้ด VCL บ่อยครั้งแล้วคุณจะพบว่าตัวแปรสมาชิกส่วนตัวในคลาส VCL ทั้งหมดเริ่มต้นด้วย "F"
เริ่มต้นด้วย ชื่อชั้นเรียนทั้งหมดเริ่มต้นด้วย "T" และอื่นๆ ประโยชน์ของสิ่งนี้คืออะไร? เวลาคนอื่นมองโค้ดแบบนี้ พอเห็นตัว "F"
ในตอนเริ่มต้น คุณสามารถรู้ได้ทันทีว่ามันเป็นสมาชิกส่วนตัวของคลาส ซึ่งอำนวยความสะดวกในการบำรุงรักษาโค้ด