เมื่อพูดถึงการพึ่งพาคำศัพท์ทั้งสองสามารถใช้แทนกันได้ (อันตราย) ในบางครั้ง Reactเป็นเฟรมเวิร์กหรือไลบรารี่? แล้วBootstrapหรือLodash ล่ะ ? ทั้งคู่เป็น " แพ็คเกจ " ใช่ไหม?

แน่นอน แต่ก็ไม่มีผลกระทบต่อแอปของคุณเช่นเดียวกัน

ห้องสมุด

ห้องสมุด (“bibliothèque” ในภาษาฝรั่งเศส แต่คนฝรั่งเศสส่วนใหญ่เรียกว่า “librairie” ซึ่งจริงๆ แล้วแปลว่า “ร้านหนังสือ” ในภาษาฝรั่งเศส แต่ตรงกับการออกเสียงภาษาอังกฤษของ “library”) เป็นชุดของฟังก์ชันสำหรับวัตถุประสงค์ทั่วไป (เช่นunderscore.js ) หรือเฉพาะทาง (เช่นmoment.js )

คุณเรียกใช้ฟังก์ชันไลบรารีได้ทุกเมื่อที่ต้องการ เช่น คุณเลือกเครื่องมือในกล่องเครื่องมือ ไม่จำเป็นต้องมีการเปลี่ยนแปลงใดๆ ในการออกแบบซอฟต์แวร์ของคุณ

การโทรที่เป็นกรรมสิทธิ์

อย่างไรก็ตาม เนื่องจากการพึ่งพา พวกเขาต้องการให้คุณเรียกใช้ API ที่เป็นกรรมสิทธิ์ของพวกเขา ดังนั้น "การล็อก" รหัสของคุณกับพวกเขา (หรืออาจเป็นเวอร์ชันของรหัสเหล่านี้) ดังนั้นการเรียกใช้ไลบรารีควรมีลักษณะดังนี้:

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

จุดพึ่งพาเดียว

หากต้องการจำกัดการพึ่งพาดังกล่าว คุณสามารถซ่อนไว้หลัง wrapper:

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

อย่างไรก็ตาม การพูดทีละขั้นตอน โค้ดของคุณยังคงขึ้นอยู่กับไลบรารี

API ธุรกิจ

หวังว่าอย่างที่ David J. Wheeler ผู้ล่วงลับเคยกล่าวไว้ว่า:

ปัญหาทั้งหมดในวิทยาการคอมพิวเตอร์สามารถแก้ไขได้โดยทางอ้อม อีกระดับ หนึ่ง

แน่นอน คุณสามารถหลีกเลี่ยงการพึ่งพาดังกล่าวได้โดยการเพิ่มส่วนต่อประสาน :

• ผู้โทรจะขึ้นอยู่กับการประกาศ API นั้น
• อะแด็ปเตอร์จะต้องดำเนินการ (โปรดทราบว่าสิ่งนี้จะทำให้ไลบรารีการเยาะเย้ยง่ายขึ้นเมื่อทำการทดสอบ)

กรอบงาน

Frameworks ("quadriciels" ในภาษาฝรั่งเศสอย่างเป็นทางการ แต่ทุกคนพูดว่า "framework") นั้นแตกต่างกันเนื่องจากให้บริการประเภทต่างๆ: พวกเขาเสนอให้จัดการสิ่งต่างๆ ให้คุณ แทนที่จะปล่อยให้คุณคิดเองว่าจะทำอย่างไร

การส่งมอบการควบคุม

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

นั่นหมายความว่า:

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

สัญญา

แน่นอนว่าไม่มีสิ่งใดขัดขวางคุณในการเรียกใช้โค้ดของคุณเอง ไลบรารีของบุคคลที่สาม หรือแม้แต่ API เฟรมเวิร์กบางส่วน แต่คุณต้องรับความเสี่ยงเอง สิ่งนี้อาจใช้หรือไม่ได้ผลตามที่คุณคาดหวัง เฟรมเวิร์กมีกฎที่คุณควรปฏิบัติตาม และหากคุณฝ่าฝืน เฟรมเวิร์กจะไม่รับผิดชอบต่อความล้มเหลวใดๆ

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

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

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

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

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

ภายในเฟรมเวิร์ก อะแดปเตอร์คอมโพเนนต์จะเป็นเลเยอร์ที่ไม่จำเป็น

ไลบรารีเฟรมเวิร์ก

ห้องสมุดยังสามารถปฏิบัติตามกรอบ แทนที่จะให้ API พวกเขาจัดเตรียมการใช้งานส่วนประกอบสำหรับเฟรมเวิร์กที่กำหนด

เมื่อเฟรมเวิร์กเริ่มได้รับความนิยม ไลบรารีเฟรมเวิร์กจำนวนหนึ่งก็พร้อมใช้งาน ส่วนใหญ่จะเกี่ยวกับวิดเจ็ต เช่น ส่วนประกอบ ดีไซน์ Materialได้รับการพอร์ตจากAndroidไปยังWeb Components , Angular , React , Vueและแม้แต่เฟรมเวิร์กiOS

กรอบมาตรฐาน

ใครก็ตามสามารถจินตนาการถึงต้นทุนมหาศาลในการพอร์ตไลบรารีเดียวกัน (และเวอร์ชันต่อๆ ไป) ในแต่ละเฟรมเวิร์กเหล่านั้น

IBM ได้คิดค้นวิธีแก้ปัญหาเกี่ยวกับเรื่องนี้ : แทนที่จะย้ายระบบ Carbon Design Systemไปใช้กับเฟรมเวิร์กไฮเปอร์ในอดีต ปัจจุบัน และอนาคต พวกเขาลงทุนในพอร์ตบนเฟรมเวิร์กคอมโพเนนต์เว็บมาตรฐานซึ่งสามารถใช้ได้ในทุกบริบท

ดังนั้น ไม่เพียงแต่อนุญาตให้ใช้ส่วนประกอบจากเฟรมเวิร์กเท่านั้น:

แต่ยังสามารถใช้ส่วนประกอบเดียวกันจากแอปธรรมดาได้:

บทสรุป

กรอบและไลบรารีเป็นตัวเลือกของบุคคลที่สามที่แตกต่างกันมาก:

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