รหัสของบุคคลที่สามคืออะไร?

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

ตัวอย่างจาก PHP:
หากฉันกำลังสร้างแอปพลิเคชันโดยใช้เฟรมเวิร์กของ Zend ฉันควรปฏิบัติต่อไลบรารีเฟรมเวิร์กของ Zend เป็นรหัสบุคคลที่สามหรือไม่

ตัวอย่างจาก C #:
ถ้าฉันสร้างแอปพลิเคชันเดสก์ท็อปฉันควรปฏิบัติต่อคลาส. Net ทั้งหมดเป็นรหัสบุคคลที่สามหรือไม่

ตัวอย่างจาก Java:
ฉันควรปฏิบัติต่อไลบรารีทั้งหมดใน JDK เป็นห้องสมุดบุคคลที่สามหรือไม่

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

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

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

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

เป้าหมายของการรวมไลบรารี่คือการแบ่งการพึ่งพาโค้ดของคุณเองในไลบรารี่นั้นเพื่อเปิดใช้งาน:

• การทดสอบหน่วย - คุณจะต้องสามารถทดสอบรหัสของคุณได้ หากห้องสมุดไม่อนุญาตให้คุณเลียนแบบคลาสหรือบังคับให้ตอบกลับที่คุณต้องการสำหรับการทดสอบของคุณคุณจะต้องล้อมไลบรารีนั้น นี่เป็นปัญหาที่เห็นได้ชัดและอาจไม่ใช่กรณีที่คุณสงสัย
• การเปลี่ยนแปลงการติดตั้งใช้งาน - ในฐานะผู้เขียนโค้ดคุณต้องเข้าใจการเปลี่ยนแปลงที่อาจเกิดขึ้นในแบบของคุณและการเปลี่ยนแปลงเหล่านั้นมีค่าใช้จ่ายเท่าใดในการเตรียมการเปรียบเทียบกับความเป็นไปได้ คุณสามารถเปลี่ยนจาก. NET เป็น JVM ได้หรือไม่ นั่นเป็นเรื่องยากและไม่น่าเป็นไปได้ อย่างไรก็ตามคุณมีแนวโน้มที่จะเปลี่ยนเทคโนโลยี UI ในอนาคตหรือเครื่องมือ XML

การแยกไลบรารีและกรอบงานของบุคคลที่สามเป็นเพียงส่วนย่อยของการแยกการเปลี่ยนแปลง

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

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

ฉันจะพิจารณาห้องสมุดที่จัดทำโดยภาษาการเขียนโปรแกรมเฉพาะเป็นส่วนหนึ่งของภาษา

กว่าฉันจะพิจารณาบุคคลที่สามห้องสมุดทั้งหมดที่มีให้โดยหน่วยงานอื่นใดเป็นส่วนขยายหรือเครื่องมือที่แยกต่างหากจากภาษาโปรแกรมเอง

ยกตัวอย่างของคุณฉันจะพิจารณา Zend บุคคลที่สาม ฉันจะสร้างแอปพลิเคชันของฉันในแบบที่ตรรกะทางธุรกิจหลักของฉันจะไม่ขึ้นอยู่กับ Zend

Wikipedia กำหนดองค์ประกอบบุคคลที่สามเป็น:

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

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

ดูเพิ่มเติมที่: /programming/148747/what-is-the-difference-between-a-framework-and-a-library