ส่วนที่ 4 – WordPress และการเขียนโปรแกรมเชิงวัตถุ: ตัวอย่าง WordPress – การออกแบบ

ณ จุดนี้ เรามีข้อกำหนดที่ชัดเจนตามที่อธิบายไว้ในส่วนที่ 3 ของชุดนี้ (โปรดดูที่นี่ หากคุณพลาดไป)

ตอนนี้เป็นเวลาที่จะเริ่มคิดเกี่ยวกับการออกแบบปลั๊กอินใหม่และปรับปรุงของเรา!

เราขอเตือนคุณว่าขั้นตอนนี้อาจใช้เวลานานเมื่อคุณทดลองใช้ในโครงการของคุณเอง คุณอาจไม่ได้รับทุกอย่างถูกต้องในครั้งแรกเช่นกัน เป็นไปได้มากที่คุณจะคิดออกแบบ เริ่มใช้งาน แล้วตระหนักว่าคุณต้องย้อนกลับไปคิดแนวทางใหม่

มันคุ้มค่ากับความพยายามอย่างยิ่งยวด แต่ต้องใช้เวลาให้มากเท่าที่จำเป็นเพื่อทำให้ทุกอย่างถูกต้อง โปรเจ็กต์ที่มีโครงสร้างที่ดีจะทำให้ดูแลรักษาและขยายได้ง่ายขึ้น หรือแม้กระทั่งการนำโค้ดกลับมาใช้ใหม่ในโครงการอื่นๆ ดังนั้นในระยะยาวจึงเป็นการใช้เวลาที่ดี

ต่อไป เราจะเน้นที่ส่วนสำคัญของปลั๊กอินและหารือว่าเราคิดอย่างไรกับการออกแบบของเรา

ผ่าหน้าการตั้งค่า

มาดูหน้าผู้ดูแลระบบของปลั๊กอินกันดีกว่า

คุณจะสังเกตเห็นว่ามีชื่อ ("จำกัดการตั้งค่าความพยายามในการเข้าสู่ระบบ") หลายส่วนที่มีบางฟิลด์ และปุ่ม "เปลี่ยนตัวเลือก" ที่ด้านล่างของหน้า

แต่ละส่วนจะประกอบด้วยชื่อ เช่น "สถิติ" และบางฟิลด์

แต่ละฟิลด์มีชื่อเรื่องทางด้านซ้าย และเนื้อหาที่เหลือทางด้านขวา มีฟิลด์ข้อความ ปุ่มตัวเลือก และช่องทำเครื่องหมาย และบางช่อง เช่น "Total Lockouts" จะแสดงเฉพาะข้อมูลเท่านั้น ผู้ดูแลระบบไม่สามารถแก้ไขได้โดยตรง

บางช่องมีคำอธิบาย เช่น ช่อง "การเชื่อมต่อเว็บไซต์" แต่ไม่ใช่ทุกช่อง

ด้วยความคิดข้างต้น เราต้องแบ่งมันออกเป็นชิ้นแนวคิดที่จะกลายเป็นชั้นเรียนในภายหลัง

WordPress Settings API ช่วยให้เราสามารถลงทะเบียนหน้าการตั้งค่า ส่วนต่างๆ ภายในหน้าเหล่านั้น และช่องต่างๆ ภายในส่วนต่างๆ:

หน้า → ส่วน → เขตข้อมูล

เราคิดว่า ทำไมไม่เพิ่ม "เลเยอร์" เข้าไปอีก Elements เพื่อทำให้ปลั๊กอินของเราขยายได้ง่ายขึ้นในอนาคต

หน้า → ส่วน → ฟิลด์ → องค์ประกอบ

ดังนั้น หน้าและส่วนคือสิ่งที่เราได้อธิบายไว้ข้างต้นแล้ว และฟิลด์จะมีองค์ประกอบของประเภทเนื้อหาใดๆ ทางด้านขวา

เมื่อพิจารณาถึงองค์ประกอบประเภทต่างๆ เหล่านี้ เราจึงเลือกใช้คลาส Element และหลายคลาส ขยายสำหรับช่องกาเครื่องหมาย ปุ่มตัวเลือก ตัวเลข ฯลฯ ที่จะแสดงผลเอาต์พุตที่แตกต่างกัน

เราอาจจำเป็นต้องเพิ่มหน้าและส่วนเพิ่มเติมในอนาคต ดังนั้นจึงมีแนวโน้มว่าเราจะต้องขยายคลาสของหน้าผู้ดูแลระบบและส่วนเหล่านี้

เช่นเดียวกับทุ่งนา คลาสสำหรับ "Total lockouts", "Active lockouts" ฯลฯ จะขยายคลาส (พาเรนต์) เดียวกัน

นี่เป็นภาพแบบง่ายที่แสดงให้เห็นความสัมพันธ์เหล่านั้น:

แน่นอนว่าไม่ได้รวม "ส่วนประกอบ" ทั้งหมดไว้ในแผนภาพ

โครงสร้างแบบนี้ทำให้ปลั๊กอินขยายได้ง่ายขึ้น เราสามารถเพิ่มฟิลด์ องค์ประกอบ หรือส่วนได้อย่างง่ายดาย หากจำเป็น เราจะสามารถเพิ่มส่วนประกอบต่างๆ ได้อย่างง่ายดาย เช่น ฟิลด์ องค์ประกอบ หรือส่วน โดยการสร้างคลาสย่อยใหม่ โดยไม่ต้องแก้ไขคลาสที่มีอยู่

การคิดและการทำให้เป็นนามธรรม

ตอนนี้เป็นเวลาที่ดีที่จะเริ่มคิดเกี่ยว กับ ส่วนประกอบต่างๆ ของปลั๊กอินของเรา ในระหว่างขั้นตอนการออกแบบ เราไม่ต้องลงรายละเอียดมากเกี่ยวกับ วิธีการ ทำงานของบางสิ่ง

ตัวอย่างเช่น พิจารณาองค์ประกอบ ตาราง สถิติ และสิ่งอื่น ๆ เกือบทั้งหมดที่จะแสดงต่อผู้ใช้ พวกเขาอาจเป็นส่วนประกอบที่แยกจากกันโดยไม่มีอะไรเหมือนกัน แต่ทั้งหมดจะแสดงผลบางส่วนในที่สุด ดังนั้น การทำงานบางอย่างจึงเป็นเรื่องปกติสำหรับส่วนประกอบที่ไม่เกี่ยวข้องกันโดยสิ้นเชิง แน่นอนว่าสิ่งนี้ครอบคลุมถึงส่วนประกอบอื่นๆ ของเราด้วยเช่นกัน

ในภาพด้านบน เราจะเห็นว่าอินเทอร์เฟซ UI ถูกใช้งานโดยหลายคลาสอย่างไร

ให้ความสนใจกับความจริงที่ว่าอินเทอร์เฟซ UI ถูกใช้งานโดยคลาสสถิติ, บันทึกการล็อก, ตาราง และองค์ประกอบ ที่ถูกอ้างถึงเป็น คลาส พาเรนต์ ไม่จำเป็นสำหรับคลาส Radio/Number/Checkbox Element เพื่อใช้งานอินเทอร์เฟซโดยตรง เนื่องจากพวกมันสืบทอดอินเทอร์เฟซทั้งหมดจากคลาสพาเรนต์ อย่างไรก็ตาม คลาสลูก สามารถ แทนที่เมธอดของคลาสพาเรนต์ได้

เนื่องจากเราทราบดีว่าปลั๊กอินของเราจะจัดการกับการตั้งค่า เราจึงสามารถสรุปได้อย่างปลอดภัยว่าเราจะอ่านและเขียนค่าของมัน นั่นคือความสามารถในการ รับ ตั้งค่า และ ลบ ตัวเลือก

การดำเนินการทั้งหมดนี้จะรวมกลุ่มกันในชั้นเรียน เราอาจเก็บตัวเลือกของเราไว้ในฐานข้อมูล WordPress หรืออะไรทำนองนั้น สำหรับตอนนี้ เราไม่ต้องสนใจว่าเราจะจัดเก็บข้อมูลของเรา อย่างไร หรือ ที่ไหน

เราสามารถเก็บ get/set/remove ตัวเลือก ที่เป็นนามธรรม ไว้ในใจ ทำให้สิ่งต่าง ๆ ง่ายขึ้นตามแนวคิด และออกแบบปลั๊กอินของเราต่อไป

ไฟล์ปลั๊กอินหลัก

เราจะให้ข้อมูลบางอย่างเกี่ยวกับปลั๊กอิน WordPress ผ่านความคิดเห็นของส่วนหัวและดำเนินการเริ่มต้น เราจะจัดระเบียบโค้ดของเราโดยรวมทุกอย่างไว้ในคลาสย่อย

ขึ้นอยู่กับว่าคลาสของปลั๊กอินของเราจะทำงานร่วมกันอย่างไร คลาสหลักจะต้องสร้างอินสแตนซ์ส่วนใหญ่ เท่าที่เราทราบ จะรวมถึงคลาสที่เกี่ยวข้องกับตัวเลือก หน้าผู้ดูแลระบบ การลองใหม่ และการล็อกเอาต์

ชั้นเรียนที่มีศักยภาพ

เราใช้เวลาสักครู่เพื่อค้นหาว่าเราต้องการชั้นเรียนใดและเราได้รายชื่อดังต่อไปนี้:

• ลองใหม่
• ล็อกเอาต์
• คุ้กกี้
• ข้อความแสดงข้อผิดพลาด
• การแจ้งเตือนทางอีเมล
• ประกาศจากแอดมิน
• ปุ่ม
• ล็อกเอาต์ล็อก
• ใช้งานอยู่/ล็อกเอาต์ทั้งหมด
• ที่อยู่ IP

โปรดทราบว่าไม่มีวิธี "ถูกต้อง" วิธีเดียวในการจัดโครงสร้างปลั๊กอินของคุณ เช่นเดียวกับสิ่งต่างๆ ส่วนใหญ่ในการพัฒนาซอฟต์แวร์ มีวิธีการแก้ปัญหาที่หลากหลายและถูกต้องเท่าเทียมกัน

ในส่วน "ทั่วไป" ตัวอย่างเช่น ความสัมพันธ์ระหว่างชั้นเรียนของเราจะมีลักษณะดังนี้:

ส่วน "สถิติ" จะคล้ายกับสิ่งนี้:

สุดท้าย "ล็อกเอาต์ล็อก" จะคล้ายกับ "สถิติ" มาก:

บทสรุป

จนถึงตอนนี้ เราได้กำหนดข้อกำหนดและคิดเกี่ยวกับการออกแบบปลั๊กอินใหม่และปรับปรุงแล้ว เราอธิบายว่าเราสร้างโครงสร้างของเราได้อย่างไร และยังมีไดอะแกรมง่ายๆ ที่แสดงให้เห็นว่าชั้นเรียนของเราจะเกี่ยวข้องกันอย่างไร

คลิกที่นี่เพื่ออ่านส่วนที่ 5 ใน Objected Oriented Programming Series

ดูสิ่งนี้ด้วย

• WordPress และการเขียนโปรแกรมเชิงวัตถุ – ภาพรวม
• ส่วนที่ 2 – การเขียนโปรแกรม WordPress และ Object Oriented: ตัวอย่างในโลกแห่งความจริง
• ส่วนที่ 3 – WordPress และการเขียนโปรแกรมเชิงวัตถุ: Α ตัวอย่าง WordPress – การกำหนดขอบเขต