ห้องสมุดซอฟต์แวร์ขนาดเล็กของฉันควรหลีกเลี่ยงการใช้ห้องสมุดอื่นหรือไม่?


13

ฉันเพิ่งเปิดตัว Java Library ขนาดเล็กที่มีคลาสและเมธอดไม่กี่ตัว ตั้งแต่ฉันสร้างโครงการด้วย Maven ฉันจึงใช้ห้องสมุดบุคคลที่สามหลายแห่งเพื่อบรรลุเป้าหมายโดยเฉพาะ:

  • commons-lang3 (สำหรับบางสิ่ง Java ทั่วไป)
  • slf4j-api (สำหรับการบันทึก)
  • คอมมอนส์ - io (สำหรับไฟล์เล็ก ๆ น้อย ๆ - ฉันอ่านไฟล์หนึ่งครั้ง)

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


1
คำถามที่เป็นรูปธรรมของคำถามของคุณดูเหมือนจะตอบได้: โครงการและ libs ที่เป็นรูปธรรมของคุณ ปัญหาคือคุณสะกดมันพร้อมกับส่วนทั่วไป "ควร ... เล็ก ... หลีกเลี่ยง" ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญเฉพาะด้าน แต่คำถามนี้มีแนวโน้มที่จะเรียกร้องการอภิปรายการโต้แย้งการหยั่งเสียงหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงได้ให้ดูคำถามที่พบบ่อยสำหรับคำแนะนำ
ริ้น

1
@gnat คำขอโทษของฉัน ในฐานะผู้ใช้งาน Stack Overflow ปกติฉันมีแนวโน้มที่จะคิดว่าคำถามอัตนัยเล็กน้อยเป็นที่ยอมรับในโปรแกรมเมอร์ มีไซต์ Stack Exchange ที่ปัญหาดังกล่าวตกลงหรือไม่ ในระหว่างนี้ฉันจะลบความไม่ชัดเจนออกจากคำถามของฉัน
ดันแคนโจนส์

2
@gnat คำถามนี้ใช้ได้แม้ในรูปแบบดั้งเดิม
โธมัสโอเวนส์

@ThomasOwens ด้วยความเคารพฉันไม่คิดอย่างนั้น สำหรับเวอร์ชั่นดั้งเดิมฉันพบคำตอบสองคำพร้อมคำแนะนำที่ตรงข้ามกันทั้งสองอย่างสมเหตุสมผล: เกมการลงคะแนนต้อนรับ
gnat

1
@gnat แค่สองคน? ไม่เป็นไร. ปล่อยให้พวกเขาโพสต์และลงคะแนนใน คำตอบที่อาจถูกต้องสองข้อที่มีเหตุผลและเหตุผลที่ตรงกันข้ามไม่ทำให้คำถามไม่ดี ทั้ง 3 หรือ 4 หรือ 5 ก็เป็นคำถามที่มีรูปแบบที่ดีซึ่งนักพัฒนาห้องสมุดปัญหาต้องจัดการและจากนั้นภาระก็จะได้รับคำตอบว่าเป็นคำตอบที่ดี
โธมัสโอเวนส์

คำตอบ:


8

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

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

นี่คือรายละเอียดเกี่ยวกับคำถามที่พบบ่อย SLF4j

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

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


ขอบคุณสำหรับการตอบกลับฉันคิดว่าเราเห็นด้วยอย่างกว้าง ๆ เกี่ยวกับวิธีการที่ฉันควรทำ เพียงเพื่อแก้ไขหนึ่งบิต - วิธีที่หนึ่งควรรวม slf4j ในโครงการห้องสมุดคือการรวมslf4j-apiและไม่มีสิ่งประดิษฐ์อื่น ๆ ที่เกี่ยวข้องให้ไว้หรืออย่างอื่น ดูslf4j.org/manual.html#projectDep
ดันแคนโจนส์

ฉันจำการฝึกสมองที่สร้างความเสียหาย (zillions ของexcludesirc) ฉันต้องทำเมื่อโมดูลเฉพาะในการอ้างอิงของฉันไม่สามารถ "เห็นด้วย" ในรุ่น slf4j จากคำตอบของคุณดูเหมือนว่านักออกแบบโมดูลจะเปิดเผยว่าprovidedจะไม่มีปัญหาเช่นนั้นใช่ไหม
ริ้น

2
@gnat โดยปกติแล้วจะสามารถแก้ไขได้ (อย่างน้อยใน Maven) โดยประกาศรุ่นที่ต้องการหนึ่งรายการใน POM ของคุณ Maven ใช้เวอร์ชัน "ใกล้เคียงที่สุด" ที่กำหนดไว้สำหรับสิ่งประดิษฐ์และ POM ทันทีจะเทียบกับการพึ่งพาสกรรมกริยา อาจเป็นไปได้ว่านี่เป็นการเปลี่ยนแปลงพฤติกรรมระหว่างการปล่อย Maven 2.x
Duncan Jones

1
+1 สำหรับการระบุ slf4j เป็นprovided- ไม่สร้างความรำคาญมาก
Gary Rowe

@ ดันแคนโจนส์ขอบคุณฉันอาจพลาดไปแล้ว รุ่น maven ของฉันคือ 2.2 หรือ 2.3 ไม่สามารถจำได้ว่าอันไหน (แม้ว่าฉันแน่ใจว่าจำได้ว่าmvn dependency:analyzeเป็นการนำรุ่นอึจนกว่าจะแยก :)
gnat

1

เลขที่

"Bloat" เป็นตำนาน ไม่ว่าจะมีรหัสเท่าใดในไลบรารีของคุณหากบางรหัสนั้นไม่เคยใช้จะไม่ได้รับการทำเพจเอาต์ - มันจะไม่มีผลกระทบใด ๆกับประสิทธิภาพหรือการใช้หน่วยความจำ

ในทางกลับกันถ้าคุณต้องการฟังก์ชั่นพิเศษที่คุณมีสองทางเลือก คุณสามารถเขียนด้วยตนเองและใช้เวลาและความพยายามในการแก้ปัญหาที่ผู้อื่นเคยแก้ไขมาก่อนหรือคุณสามารถเลือกใช้วิธีแก้ปัญหาที่มีอยู่แล้ว (และผ่านการทดสอบ / ดีบั๊ก / ฯลฯ )

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.