การแชร์คลาสหรืออินเทอร์เฟซระหว่างโครงการต่าง ๆ


17

ฉันกำลังมองหาคำตอบใน SO หรือที่นี่ แต่ไม่มีผลลัพธ์ใด ๆ นั่นคือเหตุผลที่ฉันจะถามคุณ

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

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

คุณจะแนะนำโซลูชันอื่นใดอีก ปัญหาดังกล่าวได้รับการแก้ไขอย่างไรในแอพมืออาชีพ


1
คุณควรควบคุมเวอร์ชันว่าคุณแบ่งปันอะไรหรือไม่ คุณกำลังบอกว่าคุณไม่ได้ใช้การควบคุมเวอร์ชันสำหรับลูกค้าและโครงการเซิร์ฟเวอร์หรือไม่? ถ้าเป็นเช่นนั้นแก้ไขได้ทันที
Sebastian Redl

คำตอบ:


15

สร้างโครงการพิเศษหนึ่งโครงการซึ่งกำหนดสิ่งทั่วไปทั้งหมดไว้

นี่เป็นขั้นตอนแรกในการแบ่งปันชิ้นส่วนที่นำมาใช้ซ้ำได้และเป็นส่วนที่ง่าย ส่วนที่ท้าทายมากขึ้นคือการตัดสินใจว่าโครงการสองโครงการที่ใช้ไลบรารีที่แบ่งใช้นั้นมีวงจรการปล่อยอิสระ (หรือไม่) และถ้าเป็นไปได้ว่า "โครงการ A" ใช้เวอร์ชัน 1.0 ของ lib ที่แชร์ของคุณในขณะที่โครงการ B ใช้ รุ่น 2.0 ในเวลาเดียวกัน

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

อย่างไรก็ตามหากคุณต้องการป้องกันสถานการณ์นั้นคุณควรจัดการ "project A", "project B" และ lib ของคุณเป็นโครงการทั่วไปด้วยการพัฒนาร่วมสร้างและปล่อยกระบวนการ สิ่งนี้จะอนุญาตให้เปลี่ยนอินเทอร์เฟซทั่วไปของไลบรารีที่แชร์มากขึ้นและบ่อยกว่าในสถานการณ์แรก และคุณไม่ต้องการอะไรเช่น Maven หรือหมายเลขรุ่นในชื่อไฟล์ไลบรารี แต่ข้อดีคือ A และ B ไม่สามารถพัฒนาได้อย่างอิสระอีกต่อไป


13

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

libmyproject-shared-1.0.jar

มันไม่ได้ป้องกันปัญหาเกี่ยวกับเวอร์ชัน แต่ควรช่วยได้ ฉันไม่เคยใช้ Maven แต่ฉันเข้าใจว่ามันสามารถช่วยได้ในสถานการณ์นี้


2

สร้างโครงการพิเศษหนึ่งโครงการซึ่งกำหนดสิ่งทั่วไปทั้งหมดไว้

นั่นเป็นวิธีที่. Net คาดหวังให้คุณทำ

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

ระวังสำหรับการทำให้เป็นอันดับ:

  • วิธีเดียวที่ฉันสามารถทำให้เป็นวัตถุวัตถุ / deserialise โดยตรงระหว่างสองโปรแกรม (เป็นที่ยอมรับกันเมื่อไม่นานมานี้โดยใช้ Framework 2.0) คือการติดตั้งชุดประกอบ "ที่ใช้ร่วมกัน" ลงใน Global Assembly Cache บนเครื่องไคลเอนต์และเซิร์ฟเวอร์ หากการชุมนุมเป็น "ท้องถิ่น" สำหรับแต่ละโครงการกรอบงานจะเห็นพวกเขาเป็นประเภทที่ไม่ต่อเนื่องและปฏิเสธที่จะ [เรียง] ต่อเนื่องกันเป็นหนึ่ง
  • และ [de] วัตถุที่ทำให้เป็นอนุกรมซึ่งอินเทอร์เฟซเป็นบิตของ "ความท้าทาย" ประเภทที่ไม่ใช่อินเทอร์เฟซดั้งเดิมดูเหมือนจะไม่ "ทำให้เป็น" ผ่าน "การเรียงลำดับ" ดังนั้นผู้รับจึงไม่ทราบประเภทที่เป็นรูปธรรมที่จะ "สร้าง" จากสตรีมขาเข้า

1

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

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