ใช้ OOP ในชุดรูปแบบ


36

ฉันเห็นปลั๊กอินจำนวนมากใช้ประโยชน์จากการเขียนโปรแกรมเชิงวัตถุเมื่อไม่จำเป็นจริงๆ

แต่สิ่งที่แย่กว่านั้นคือผู้พัฒนาธีมเริ่มทำสิ่งเดียวกัน ชุดรูปแบบเชิงพาณิชย์และชุดรูปแบบฟรียอดนิยมเช่น Suffusion แม้กระทั่งชุดรูปแบบที่ชื่นชอบ - ไฮบริดมันทำหน้าที่ทั้งหมดของพวกเขาภายในชั้นเรียนยกตัวอย่างหนึ่งครั้งใน

WTF? จุดประสงค์ของการทำสิ่งนี้คืออะไร? เห็นได้ชัดว่าคุณจะไม่ได้ใช้อินสแตนซ์ของธีมเดียวกันสองรายการขึ้นไปในเวลาเดียวกัน

สมมติว่าปลั๊กอินทำสิ่งนี้สำหรับเนมสเปซ (ซึ่งไร้สาระ) แต่ธีมของข้อแก้ตัวคืออะไร ฉันพลาดอะไรไปรึเปล่า?

อะไรคือข้อดีของการเข้ารหัสธีมเช่นนี้?


5
@Ambitious Amoeba - คุณช่วยอธิบายได้ไหมว่าทำไมคุณถึงเชื่อว่าการใช้คลาสสำหรับปลั๊กอินเพื่อลดการชนของ namespace นั้นไร้สาระ? ในส่วนของชุดรูปแบบอาจจะมีประโยชน์เช่นกันหากคุณสามารถยกตัวอย่างสิ่งที่คุณพิจารณาว่าเป็นรหัสที่ดีในชุดรูปแบบและสิ่งที่คุณกำลังพิจารณาว่าไม่จำเป็น การอภิปรายเรื่องนี้ในบทคัดย่อนั้นไม่น่าจะทำให้คุณเข้าใจอย่างถ่องแท้สำหรับคุณหรือผู้อื่นโดยเฉพาะอย่างยิ่งคนอื่น ๆ ที่ไม่คุ้นเคยกับสิ่งที่คุณอ้างถึง
MikeSchinkel

1
ฉันใช้คลาสทุกที่ที่ฉันสามารถทำได้มันง่ายกว่าที่ฉันจะดูแลรักษาอัปเดตและใช้ซ้ำ ความชอบส่วนตัวนอกเหนือจากเหตุผลอะไรที่ดีสำหรับการใช้คลาส?
t31os

1
แปลกเพิ่งสูญเสียความคิดเห็นเดิมของฉัน (SE ข้อผิดพลาดอาจ?) .. ฉันจะทำซ้ำแม้ว่าเหตุผลอะไรดีมีไม่ใช้คลาส?
t31os

2
@MikeSchinkel: คุณสามารถทำได้โดยเพิ่มคำนำหน้าต่อท้ายชื่อฟังก์ชัน ฉันไม่คิดว่ามันคุ้มค่ากับค่าใช้จ่ายในชั้นเรียนพิเศษเพียงเพื่อให้มีชื่อฟังก์ชั่นที่ดี อย่างไรก็ตามฉันอยากรู้ว่าทำไมรูปแบบการทำเช่นนี้ไม่มากเกี่ยวกับปลั๊กอิน
onetrickpony

4
@Ambitious Amoeba - ฉันจะให้สิทธิ์คุณกับความคิดเห็นของคุณ แต่ความคิดเห็นของฉันแตกต่างกัน ฉันเชื่อว่าความชัดเจนที่คลาสนำมาสู่โค้ดโดยการลดฟังก์ชั่นที่ลอยอยู่ในเนมสเปซส่วนกลางนั้นคุ้มค่ากับสิ่งที่ฉันเชื่อว่าเป็นจำนวนค่าใช้จ่ายเพิ่มเติมที่ไม่สามารถวัดได้โดยเฉพาะเมื่อใช้ IDE ระดับมืออาชีพเช่น PhpStorm และคลาสจะสร้างหน่วยที่มีในตัวเองเพื่อให้ผู้พัฒนาสามารถรู้รหัสที่โมดูลต้องการ และในที่สุดหลังจากการพัฒนารูปแบบปลั๊กอิน WordPress ของฉันเพื่อใช้เรียนวิธีอื่นใดก็แค่รู้สึกว่าฉันชอบการเขียนเลอะเทอะ
MikeSchinkel

คำตอบ:


26

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

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

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

เพื่อตอบคำถามของคุณ

WTF? จุดประสงค์ของการทำสิ่งนี้คืออะไร? เห็นได้ชัดว่าคุณจะไม่ได้ใช้อินสแตนซ์ของธีมเดียวกันสองรายการขึ้นไปในเวลาเดียวกัน

ไม่คุณจะไม่ใช้อินสแตนซ์ของธีมเดียวกันสองรายการขึ้นไป แต่ชอบพูดว่าคิดของโครงสร้างชั้นในกรณีนี้เป็นnamespacingฟังก์ชั่นที่ไม่ได้สร้างตัวอย่างวัตถุแบบดั้งเดิม การรวมทุกอย่างเข้าด้วยกันในชั้นเรียนและยกตัวอย่างเพื่อเรียกใช้เมธอด ( myClass->method();) หรือวิธีการโทรโดยตรง ( myClass::method();) เป็นวิธีที่สะอาดมากในการกำหนดชื่อสิ่งต่าง ๆ ในรูปแบบที่อ่านได้และใช้ซ้ำได้

แน่นอนว่าคุณสามารถใช้บางสิ่งบางอย่างmyClass_method();แทนได้เสมอ แต่ถ้าคุณต้องการใช้รหัสนี้อีกครั้งในธีมอื่นในปลั๊กอินหรือในกรอบงานแอนเทอร์โร่คุณต้องย้อนกลับไปและเปลี่ยนคำนำหน้าทั้งหมดของคุณ การรักษาทุกสิ่งในชั้นเรียนนั้นสะอาดและช่วยให้คุณพัฒนาและปรับใช้งานได้รวดเร็วยิ่งขึ้น

สมมติว่าปลั๊กอินทำสิ่งนี้สำหรับเนมสเปซ (ซึ่งไร้สาระ) แต่ธีมของข้อแก้ตัวคืออะไร ฉันพลาดอะไรไปรึเปล่า?

ในสถานการณ์ส่วนใหญ่ฉันเห็นด้วยกับคุณ อย่างไรก็ตามเสียงข้างมากนั้นกำลังจางหายไปอย่างรวดเร็ว ฉันโฮสต์หลายไซต์ในการติดตั้ง MultiSite ที่ใช้ชุดรูปแบบของชุดรูปแบบเดียวกัน แทนที่จะสร้างธีมเดียวกันซ้ำแล้วซ้ำอีกด้วยความแตกต่างเล็กน้อยฉันมี "คลาส" เดียวสำหรับธีมหลักและธีมลูกทั้งหมดขยายคลาสนั้น สิ่งนี้ทำให้ฉันสามารถกำหนดฟังก์ชันการทำงานที่กำหนดเองสำหรับแต่ละไซต์ในขณะที่ยังคงความรู้สึกทั่วไปของความสม่ำเสมอทั่วทั้งเครือข่าย

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

อะไรคือข้อดีของการเข้ารหัสธีมเช่นนี้?

หากคุณใช้ไฮบริดในเว็บไซต์ของคุณมีเพียงเล็กน้อยเท่านั้นที่จะได้รับประโยชน์จากการเป็นผู้ใช้ปลายทาง หากคุณกำลังสร้างธีมลูกสำหรับไฮบริดมีข้อดีจากการกำหนดเนมสเปซและการขยาย หากคุณทำงานกับThemeHybridความได้เปรียบจะอยู่ที่การใช้รหัสที่รวดเร็วและมีประสิทธิภาพในโครงการอื่น ๆ ของคุณ (Prototype, Leviathan ฯลฯ )

และถ้าคุณเป็นผู้พัฒนาธีมที่ชอบคุณสมบัติเฉพาะของไฮบริด แต่ไม่ใช่ทั้งธีมข้อดีนั้นอยู่ที่การนำโค้ดมาใช้อย่างรวดเร็วและมีประสิทธิภาพในโครงการที่ไม่ใช่ไฮบริดของคุณ (สมมติว่ามันเป็น GPL)


ฉันไม่เห็นด้วยกับส่วน "ความสามารถในการขยาย" คุณมีการควบคุมในระดับเดียวกับธีมพาเรนต์เหมือนกับที่คุณใช้หากคุณใช้การกระทำและฟังก์ชั่นทั่วไป ทำไม? คุณพูดด้วยตัวเองนี่ไม่เป็นความจริง OOP ฉันไม่เห็นด้วยกับการกำหนดเนมสเปซ - นี่คือเหตุผลที่ฉันเริ่มต้นคำถามนี้ตั้งแต่แรก - ลองกำหนดฟังก์ชันใหม่จากไฮบริดในปลั๊กอินใด ๆ และคุณจะเห็นว่าฟังก์ชั่นจะชนกัน ทำไมคุณคิดว่าพวกเขายังคงเพิ่มคำนำหน้า? :) คุณไม่สามารถปิดชุดรูปแบบทั้งหมดในชั้นเรียนมันไม่สมเหตุสมผลเลย ...
onetrickpony

ฉันไม่ได้บอกว่าจะไม่ใช้ OOP ในรูปแบบเช่นบางคนที่นี่อาจจะเข้าใจในทางตรงกันข้าม (ดู 2.8 วิดเจ็ตสำหรับเช่น. วอล์กเกอร์และอื่น ๆ ) แต่ไม่ชอบสิ่งนี้
onetrickpony

1
ดูเหมือนว่าคุณมีปัญหากับการใช้งานเฉพาะของไฮบริดสลีไม่ใช่การฝึกใช้ OOP ในธีมหรือแม้กระทั่งการใช้คลาสเพื่อกำหนดชื่อฟังก์ชันที่กำหนดในธีม ฉันพยายามที่จะตอบคำถามที่กว้างขึ้นของคุณอีกครั้งทำไมทำเช่นนี้? และ Re: อะไรคือข้อดีของการทำเช่นนี้? ฉันจะไม่ใช้เวลาในการปกป้องสิ่งที่ดูเหมือนจะเป็นการดำเนินการแบบครึ่งใจหรือโต้เถียงกับความเกลียดชังที่เห็นได้ชัดของคุณไปยังโครงสร้างของชุดรูปแบบเฉพาะ บรรทัดล่างถ้าคุณไม่ชอบวิธีการสร้างของไฮบริดใช้อย่างอื่น
EAMann

1
ไม่เลยฉันชอบ Hybrid (แต่ไม่ใช่ของคลาสแน่นอน) ไฮบริดทำให้ฉันต้องสร้างเฟรมเวิร์กธีมของตัวเอง ยกตัวอย่างอีกอย่าง Suffusion การฝึกฝนแบบเดียวกัน อีกครั้งเนมสเปซในกรณีนี้ใช้ไม่ได้กับธีมฟังก์ชั่นทั้งหมดภายในคลาส wrapper จะขัดแย้งกับปลั๊กอินเสมอเนื่องจากปลั๊กอินถูกโหลดโดย WP "ภายใน" ธีม
onetrickpony

1
ยุติธรรมพอสมควร เพียงแค่จำไว้ว่างาน WP ส่วนใหญ่ไม่ใช่ OOP ที่จะเริ่มต้นด้วย (เนื่องจาก WP ไม่ใช่) แต่การใส่ธีมวิธีการในคลาสเพื่อเลียนแบบการทำงานของปลั๊กอินอย่างน้อยหนึ่งขั้นตอนทางด้านขวา การชี้นำ ... แม้ว่าจะเป็นชั้นเรียนที่มีผู้ตั้งครรภ์ครึ่งหนึ่งและได้รับการปฏิบัติน้อย ฉันเห็นด้วยอย่างแน่นอนว่าการห่อทุกอย่างในชั้นเรียนและการเรียกสิ่งต่าง ๆ นั้นค่อนข้างแปลก (และไม่มีประโยชน์จากมุมมองของนักพัฒนาบุคคลที่สามที่พยายามใช้ระบบ) แต่ถ้าทำอย่างถูกต้อง (และในแบบไฮบริดก็ไม่ชัดเจน) การใส่รหัสในคลาสของคุณfunctions.phpจะมีประสิทธิภาพมาก
EAMann

29

ความเร็ว

ชุดรูปแบบฐานปัจจุบันของฉันมี 13 ชั้น เมื่อฉันสร้างชุดรูปแบบใหม่ฉันอาจใช้คลาสเหล่านี้ตามที่พวกเขาเป็นหรือฉันขยายพวกเขา ระบบดังกล่าวทำให้กระบวนการสร้างชุดรูปแบบใหม่นั้นเร็วมาก

ขอบเขตแน่น

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

ซ่อมบำรุง

แต่ละคลาสเป็นหนึ่งไฟล์ หากฉันต้องการอัปเดตธีมของลูกค้าฉันแค่อัปเดตไฟล์บางไฟล์ สิ่งที่เกิดขึ้นภายในชั้นเรียนนั้นขึ้นอยู่กับฉันตราบใดที่ฉันเสนอ API เดียวกัน

ตัวอย่าง: เหนือการcomment_form();โทรฉันใช้การกระทำที่เรียบง่าย:

do_action( 'load_comment_class' );
comment_form();

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

ลองวิธีนี้ด้วยวิธีการที่บริสุทธิ์และคุณจะรู้สึกแย่ :)

การอ่าน

มันง่ายกว่ามากในการอ่านซ้ำและเข้าใจรหัสของคุณเองในอีกหลายเดือนต่อมาถ้าคุณแยกทุกอย่างออกจากงานของมัน

ตัวอย่างบางส่วนสำหรับลำดับชั้นของชั้นเรียนที่มีประโยชน์

  • Meta_Box-> ขยายโดยShortdesc_Meta_BoxและSimple_Checkbox_Meta_Box-> ขยายโดยSidebar_Switch
  • User_Profile_Addon-> ขยายโดยUser_Profile_Checkbox(ดูคำถาม 3255 )
  • Comment_Form -> ขยายโดย {$theme_name}_Comment_Form

1
โอกาสใดที่จะได้คลาส 'ธีม' ของคุณ? ฉันต้องการเขียนของตัวเองและฉันต้องการทราบวิธีการที่คุณทำ
Horttcore

1
ฉันยังไม่ได้ตัดสินใจ บางทีฉันอาจจะสร้างธีมพื้นฐานใหม่พร้อมกับ @bueltge ในปีหน้าซึ่งใช้คลาสเหล่านี้บางส่วน มีโอกาสมากที่จะไม่เดินขบวนก่อนฉันกลัว
fuxia

5
โดยเฉพาะอย่างยิ่งสำหรับกรณีของคุณธีมและกรอบฟรี OOP เป็นวิธีที่จะไป คนอื่นต้องทำงานกับรหัสเหล่านี้ ผู้เขียนควรทำให้กระบวนการนี้ง่ายและยืดหยุ่นที่สุด การแทนที่คลาสนั้นง่ายกว่าการแทนที่ 20 ฟังก์ชันเนื่องจากคลาสที่เขียนได้ดีมี API ที่กำหนดไว้อย่างชัดเจน
fuxia

2
ฉันไม่สามารถพูดอะไรเกี่ยวกับไฮบริด ฉันไม่เคยใช้มัน แต่ใช่ตัวควบคุมที่จัดการทุกอย่างหลังม่านนำเสนอตัวกรองที่ดีและแทรกรูปแบบ MVC บางอย่างในระเบียบธีมปกติ - เป็นสิ่งที่ดี อย่าเชื่อฉัน ลองมัน. :)
fuxia

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

3

อีกจุดที่ต้องพิจารณา: ความเร็ว

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

หลังจากดูสั้น ๆ / พิมพ์ออกมาฉันพบ ~ 1.700 ฟังก์ชั่นภายในและ ~ 1.400 ฟังก์ชั่นผู้ใช้ = ~ 3.100 / 3.200 ฟังก์ชั่น VS ~ 250 คลาส ฉันเดาว่าสิ่งนี้จะบอกได้ว่าต้องการการค้นหามากแค่ไหน หากคุณต้องการ!function_exists('')ฟังก์ชั่นประมาณ 50-100 ฟังก์ชั่นในชุดรูปแบบของคุณ ... เพียงแค่ตั้งเวลาหนึ่งแล้วเริ่มทำคณิตศาสตร์ แม้ว่าจะไม่ใช่ OOP มันเป็นวิธีที่ดีในการสร้างรหัส

1) นำมาใช้ซ้ำได้
2) บำรุงรักษาได้
3) แลกเปลี่ยนได้
4) เร็วขึ้นเล็กน้อย

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


2

บางคนแย้งว่า encapsulation เป็นประโยชน์อย่างเดียว (หรืออย่างน้อยหลัก) ที่ OOP เสนอให้และการสืบทอดและสถานะนั้นอยู่ระหว่างการเบื่อและความชั่วร้าย:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

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

ฉันอาจเขียนปลั๊กอิน WordPress ของฉันต่อไปใน Haskell


1
บล็อกเปิดให้ผู้ใช้ "เชิญ" เท่านั้นโชคไม่ดี เพียงเตือนความจำอีกว่าทำไมเราไม่ควรโพสต์ข้อมูลของเราในบริการฟรีและควรโฮสต์บล็อกของเราแทน Facebook เป็นเช่นเดียวกันในเรื่องนี้ ลิงค์ทรัพยากรที่อัปเดตน่าจะดี FWIW ฉันเห็นด้านมืดของ OOP และจะไม่ใช้มันอีกเว้นแต่จะมีความจำเป็นอย่างยิ่งในบริบทเนื่องจากฟังก์ชั่นการสั่งซื้อที่สูงขึ้นสามารถขยายการทำงานได้และช่วยลดการใช้classคำสำคัญในทางที่ผิด
Josh Habdas

2

โอ้การอภิปรายค่อนข้าง! ฉันต้องยอมรับเช่นกันว่าฉันใช้คลาสเพื่อห่อหุ้มบ่อยกว่ามาก ความคิดที่อยู่ที่นี่ในปลั๊กอินของฉันฉันสามารถห่อฟังก์ชั่นของฉันในชั้นเรียนและภายในชั้นเรียนนั้นใช้ชื่อเมธอดที่เรียบง่ายและมีความหมายซึ่งเป็นชื่อสามัญแม้ในปลั๊กอินอื่น ๆ ที่ฉันเขียน ในอินสแตนซ์นั้นคลาสเป็นสิ่งทดแทนสำหรับเนมสเปซซึ่งฉันถูกบังคับให้หลีกเลี่ยงสภาพแวดล้อม 5.2.x

ในขณะที่มีบางกรณีที่ OOP มีประโยชน์สำหรับการแยกส่วนการกระทำที่เรียบง่ายของการห่อหุ้มฟังก์ชั่นของคุณยังสร้างโบนัสเพิ่มของความสามารถในการขยายข้ามปลั๊กอิน ตัวอย่างเช่นเมื่อเร็ว ๆ นี้ฉันได้ขยายโซลูชันการแจ้งหนี้ที่อิงกับคลาสและเมื่อเป็นเช่นนั้นฉันสามารถขยายคลาสหลักเพิ่มรหัสพิเศษให้กับฟังก์ชั่นต่างๆ (w / parent :: call) หรือแม้แต่แทนที่ฟังก์ชั่น

อย่างไรก็ตามการห่อคลาสส่วนใหญ่เป็นเพียงการแทนที่เนมสเปซ


-4

ประเด็นของการบ่นเกี่ยวกับโค้ดที่คุณไม่ได้เขียนคืออะไร?

หากคุณไม่ชอบโค้ดให้เขียนด้วยตัวคุณเอง!

ง่าย แก้ไขปัญหา.

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

รหัสไม่ใช่บทกวี รหัสคือชุดรูปแบบของเพลง Sinatra "My Way" ...


10
คำถามนี้ไม่ได้บ่นเกี่ยวกับรหัส แต่จะขอคำอธิบายที่ชัดเจนว่าทำไมรหัสจึงถูกเขียนขึ้นในลักษณะเฉพาะ WP core ส่วนใหญ่นั้นเป็นโพรซีเดอร์ที่มีฟีเจอร์ใหม่บางอย่างที่ใช้วิธีการของ OOP ปลั๊กอินที่ทันสมัยจำนวนมากยังใช้ OOP เพื่อห่อหุ้มฟังก์ชันการทำงาน แต่ธีมส่วนใหญ่ไม่ได้ OP ได้ถามว่าเหตุใดจึงใช้วิธีหลอก -OOP และให้ไฮบริดเป็นตัวอย่าง คุณไม่ได้ตอบคำถามคุณกำลังคุยโว
EAMann
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.