คุณใช้กลยุทธ์ใดในการตั้งชื่อแพ็กเกจในโปรเจ็กต์ Java และเพราะเหตุใด [ปิด]

ฉันคิดถึงเรื่องนี้เมื่อไม่นานมานี้และเมื่อไม่นานมานี้ปรากฏขึ้นอีกครั้งเมื่อร้านของฉันกำลังทำเว็บแอป Java ตัวแรก

ในบทนำฉันเห็นกลยุทธ์การตั้งชื่อแพ็กเกจหลัก 2 แบบ (เพื่อความชัดเจนฉันไม่ได้หมายถึงส่วน 'domain.company.project' ทั้งหมดของสิ่งนี้ฉันกำลังพูดถึงรูปแบบแพ็คเกจที่อยู่ด้านล่าง) อย่างไรก็ตามหลักการตั้งชื่อแพ็คเกจที่ฉันเห็นมีดังนี้:

1. ฟังก์ชั่น: ตั้งชื่อแพ็กเกจของคุณตามฟังก์ชันสถาปัตยกรรมแทนที่จะเป็นเอกลักษณ์ตามโดเมนธุรกิจ คำอื่นสำหรับสิ่งนี้อาจเป็นการตั้งชื่อตาม "เลเยอร์" ดังนั้นคุณจะมีแพ็คเกจ * .ui และแพ็คเกจ * .domain และแพ็คเกจ * .orm หีบห่อของคุณเป็นชิ้นส่วนแนวนอนแทนที่จะเป็นแนวตั้ง

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

2. ตรรกะ: การตั้งชื่อแพ็กเกจของคุณตามข้อมูลประจำตัวของโดเมนธุรกิจและใส่ทุกคลาสที่เกี่ยวข้องกับฟังก์ชันการทำงานตามแนวตั้งลงในแพ็กเกจนั้น

   ฉันไม่เคยเห็นหรือได้ยินเรื่องนี้อย่างที่ฉันพูดถึงมาก่อน แต่มันสมเหตุสมผลสำหรับฉัน

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

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

   3. ดูเหมือนว่าสิ่งนี้จะช่วยให้คุณสามารถใช้ประโยชน์จากตัวปรับการเข้าถึงของ Java ได้ดีขึ้นมาก สิ่งนี้ช่วยให้คุณกำหนดอินเทอร์เฟซในระบบย่อยได้อย่างหมดจดมากขึ้นแทนที่จะเป็นเลเยอร์ของระบบ ดังนั้นหากคุณมีระบบย่อยคำสั่งซื้อที่คุณต้องการคงอยู่อย่างโปร่งใสในทางทฤษฎีคุณสามารถอย่าให้สิ่งอื่นรู้ว่ามันคงอยู่ได้โดยไม่ต้องสร้างอินเทอร์เฟซสาธารณะให้กับคลาสการคงอยู่ในเลเยอร์ dao และบรรจุคลาส dao ไว้ใน มีเฉพาะคลาสที่เกี่ยวข้องเท่านั้น เห็นได้ชัดว่าหากคุณต้องการเปิดเผยฟังก์ชันนี้คุณสามารถจัดเตรียมอินเทอร์เฟซสำหรับมันหรือทำให้เป็นสาธารณะ ดูเหมือนว่าคุณจะสูญเสียสิ่งนี้ไปมากโดยการแบ่งส่วนแนวตั้งของคุณลักษณะของระบบของคุณในหลายแพ็คเกจ

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

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

สำหรับการออกแบบบรรจุภัณฑ์ขั้นแรกฉันจะแบ่งตามเลเยอร์จากนั้นตามฟังก์ชันอื่น ๆ

มีกฎเพิ่มเติมบางประการ:

1. เลเยอร์จะเรียงซ้อนกันจากทั่วไปส่วนใหญ่ (ด้านล่าง) ไปจนถึงเฉพาะส่วนใหญ่ (ด้านบน)
2. แต่ละเลเยอร์มีอินเทอร์เฟซสาธารณะ (นามธรรม)
3. เลเยอร์สามารถขึ้นอยู่กับอินเทอร์เฟซสาธารณะของเลเยอร์อื่นเท่านั้น (การห่อหุ้ม)
4. เลเยอร์สามารถขึ้นอยู่กับเลเยอร์ทั่วไปเท่านั้น (การอ้างอิงจากบนลงล่าง)
5. เลเยอร์ควรขึ้นอยู่กับเลเยอร์ด้านล่างโดยตรง

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

• เลเยอร์การนำเสนอ: สร้าง UI ที่จะแสดงในระดับไคลเอนต์
• แอปพลิเคชันเลเยอร์: มีตรรกะที่เฉพาะเจาะจงสำหรับแอปพลิเคชันโดยมีสถานะ
• ชั้นบริการ: จัดกลุ่มฟังก์ชันตามโดเมนไร้สัญชาติ
• เลเยอร์การรวม: ให้การเข้าถึงระดับแบ็กเอนด์ (db, jms, อีเมล, ... )

สำหรับรูปแบบแพ็คเกจที่เป็นผลลัพธ์กฎเพิ่มเติมมีดังนี้:

• รากของทุกชื่อแพ็กเกจคือ <prefix.company>.<appname>.<layer>
• อินเทอร์เฟซของเลเยอร์ถูกแบ่งออกตามฟังก์ชันการทำงาน: <root>.<logic>
• การใช้งานแบบส่วนตัวของเลเยอร์นั้นขึ้นต้นด้วยส่วนตัว: <root>.private

นี่คือตัวอย่างเค้าโครง

เลเยอร์การนำเสนอแบ่งตามเทคโนโลยีมุมมองและเลือกตาม (กลุ่ม) แอปพลิเคชัน

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

ชั้นแอปพลิเคชันแบ่งออกเป็นกรณีการใช้งาน

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

ชั้นบริการแบ่งออกเป็นโดเมนธุรกิจซึ่งได้รับอิทธิพลจากลอจิกของโดเมนในระดับแบ็กเอนด์

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

เลเยอร์การรวมแบ่งออกเป็น 'เทคโนโลยี' และเข้าถึงวัตถุ

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...

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

ทำไมฉันถึงคิดว่าแนวทางแนวตั้งไม่ค่อยดีนัก?

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

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

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

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

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

โดยปกติจะมีการแบ่งทั้งสองระดับในปัจจุบัน จากด้านบนมีหน่วยการปรับใช้ สิ่งเหล่านี้มีชื่อว่า 'ตามเหตุผล' (ในแง่ของคุณคิดว่าคุณสมบัติ Eclipse) ภายในหน่วยการปรับใช้คุณมีส่วนการทำงานของแพ็กเกจ (คิดว่าปลั๊กอิน Eclipse)

ยกตัวอย่างเช่นคุณลักษณะcom.featureและมันประกอบด้วยcom.feature.client, com.feature.coreและcom.feature.uiปลั๊กอิน ภายในปลั๊กอินฉันมีการแบ่งแพ็คเกจอื่น ๆ น้อยมากแม้ว่าจะไม่ใช่เรื่องผิดปกติก็ตาม

ปรับปรุง: Btw มีพูดคุยที่ดีโดย Juergen Hoeller เกี่ยวกับองค์กรของรหัสที่ InfoQ: http://www.infoq.com/presentations/code-organization-large-projects Juergen เป็นหนึ่งในสถาปนิกของ Spring และรู้เรื่องนี้มาก

โปรเจ็กต์ java ส่วนใหญ่ที่ฉันเคยทำงานกับการแบ่งส่วนแพ็กเกจจาวาก่อนจากนั้นจึงมีเหตุผล

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

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

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

โดยส่วนตัวแล้วฉันชอบการจัดกลุ่มคลาสอย่างมีเหตุผลจากนั้นภายในนั้นจะมีแพ็กเกจย่อยสำหรับการมีส่วนร่วมในแต่ละฟังก์ชัน

เป้าหมายของบรรจุภัณฑ์

แพคเกจเป็นเรื่องของการจัดกลุ่มสิ่งต่างๆเข้าด้วยกัน - แนวคิดคือชั้นเรียนที่เกี่ยวข้องกันอยู่ใกล้กัน หากพวกเขาอาศัยอยู่ในแพ็คเกจเดียวกันพวกเขาสามารถใช้ประโยชน์จากแพ็คเกจส่วนตัวเพื่อ จำกัด การมองเห็นได้ ปัญหาคือการรวมมุมมองและความเพียรของคุณทั้งหมดไว้ในแพ็คเกจเดียวอาจนำไปสู่การรวมชั้นเรียนจำนวนมากไว้ในแพ็คเกจเดียว สิ่งที่สมเหตุสมผลต่อไปที่ต้องทำคือสร้างมุมมองการคงอยู่แพ็คเกจย่อย util และคลาส refactor ตามนั้น น่าเสียดายที่การกำหนดขอบเขตส่วนตัวที่ได้รับการป้องกันและแพ็กเกจไม่สนับสนุนแนวคิดของแพ็กเกจปัจจุบันและแพ็กเกจย่อยเนื่องจากจะช่วยในการบังคับใช้กฎการมองเห็นดังกล่าว

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

ตัวอย่างโครงสร้างบรรจุภัณฑ์เชิงตรรกะของฉัน

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

ข้อดี

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

ข้อดีอื่น ๆ ของ Logical v Functional

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

ทำไมฟังก์ชั่น?

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

ผู้พัฒนาเปลี่ยนแปลงระบบ

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

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

วิธีการเริ่มต้นนี้ใช้ได้ดีเนื่องจากตัวอย่างที่สร้างขึ้นมักจะทำหน้าที่ในการ: 1) กำหนดแผนผังสถาปัตยกรรมของเฟรมเวิร์กที่กำลังนำเสนอในแนวความคิด 2) ทำด้วยวัตถุประสงค์เชิงตรรกะเดียว (เช่นเพิ่ม / ลบ / อัปเดต / ลบสัตว์เลี้ยงจากคลินิก) . ปัญหาคือผู้อ่านหลายคนใช้สิ่งนี้เป็นมาตรฐานที่ไม่มีขอบเขต

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

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

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

ในทางกลับกันเมื่อสร้างแอปพลิเคชันทางธุรกิจฉันจะบรรจุตามคุณลักษณะ ฉันไม่มีปัญหาในการวาง Widget, WidgetService และ WidgetController ทั้งหมดในแพ็คเกจ " com.myorg.widget. " เดียวกันจากนั้นใช้ประโยชน์จากการมองเห็นเริ่มต้น (และมีคำสั่งนำเข้าน้อยลงรวมถึงการอ้างอิงระหว่างแพ็คเกจ)

อย่างไรก็ตามมีการข้ามกรณี ถ้า WidgetService ของฉันถูกใช้โดยโลจิคัลโดเมน (ฟีเจอร์) จำนวนมากฉันอาจสร้างแพ็กเกจ" com.myorg.common.service " นอกจากนี้ยังมีโอกาสที่ดีที่ฉันจะสร้างชั้นเรียนโดยตั้งใจที่จะใช้งานได้ซ้ำในฟีเจอร์ต่างๆและจบลงด้วยแพ็คเกจเช่น " com.myorg.common.ui.helpers " และ " com.myorg.common.util " ฉันอาจลงเอยด้วยการย้ายคลาส "ทั่วไป" ในภายหลังทั้งหมดนี้ในโปรเจ็กต์แยกต่างหากและรวมไว้ในแอปพลิเคชันทางธุรกิจของฉันเป็นการพึ่งพา myorg-commons.jar

ขึ้นอยู่กับความละเอียดของกระบวนการเชิงตรรกะของคุณหรือไม่?

หากเป็นแบบสแตนด์อโลนคุณมักจะมีโปรเจ็กต์ใหม่สำหรับพวกเขาในการควบคุมแหล่งที่มาแทนที่จะเป็นแพ็คเกจใหม่

โครงการที่ฉันกำลังทำอยู่ในขณะนี้ผิดพลาดในการแยกตรรกะมีแพ็คเกจสำหรับด้าน jython แพ็คเกจสำหรับเอ็นจินกฎแพ็คเกจสำหรับ foo บาร์ binglewozzle ฯลฯ ฉันกำลังมองหาการมีตัวแยกวิเคราะห์ XML เฉพาะ / ผู้เขียนสำหรับแต่ละโมดูลภายในแพ็คเกจนั้นแทนที่จะมีแพ็คเกจ XML (ซึ่งฉันได้ทำไปก่อนหน้านี้) แม้ว่าจะยังคงมีแพ็คเกจ XML หลักที่ตรรกะที่ใช้ร่วมกันไป เหตุผลประการหนึ่งคือมันอาจขยายได้ (ปลั๊กอิน) ดังนั้นแต่ละปลั๊กอินจะต้องกำหนดโค้ด XML (หรือฐานข้อมูล ฯลฯ ) ด้วยดังนั้นการรวมศูนย์จะทำให้เกิดปัญหาในภายหลัง

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

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

หรือบางทีฉันกำลังสั่นไหว

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

สำหรับฉันสิ่งนี้ง่ายกว่ามากในการดูแลรักษาและแสดงภาพในระบบการตั้งชื่อแนวตั้งแทนที่จะเป็นแนวนอน หาก component1.display มีการอ้างอิงถึง component2.dataaccess จะเป็นการส่งเสียงเตือนมากกว่าถ้า display.component1 มีการอ้างอิงถึง dataaccess ส่วนประกอบ 2.

แน่นอนว่าส่วนประกอบที่ทั้งสองใช้ร่วมกันจะอยู่ในแพ็คเกจของตัวเอง

ฉันติดตามและเสนอองค์กรเชิงตรรกะ ("ตามคุณลักษณะ") โดยสิ้นเชิง! แพ็กเกจควรเป็นไปตามแนวคิดของ "โมดูล" อย่างใกล้ชิดที่สุด องค์กรที่ทำงานได้อาจกระจายโมดูลไปทั่วโครงการส่งผลให้มีการห่อหุ้มน้อยลงและมีแนวโน้มที่จะเปลี่ยนแปลงรายละเอียดการดำเนินการ

ลองใช้ปลั๊กอิน Eclipse ตัวอย่างเช่นการใส่มุมมองหรือการกระทำทั้งหมดในแพ็คเกจเดียวจะไม่เป็นระเบียบ ส่วนประกอบแต่ละส่วนของฟีเจอร์ควรไปที่แพ็กเกจของฟีเจอร์หรือหากมีจำนวนมากลงในแพ็กเกจย่อย (featureA.handlers, featureA.preferences เป็นต้น)

แน่นอนว่าปัญหาอยู่ที่ระบบแพ็กเกจแบบลำดับชั้น (ซึ่งในกลุ่มอื่น ๆ มี Java) ซึ่งทำให้การจัดการข้อกังวลในมุมฉากเป็นไปไม่ได้หรืออย่างน้อยก็ยากมาก - แม้ว่าจะเกิดขึ้นทุกที่ก็ตาม!

ฉันจะไปตั้งชื่อตามหน้าที่เป็นการส่วนตัว เหตุผลสั้น ๆ : หลีกเลี่ยงการทำซ้ำรหัสหรือฝันร้ายจากการพึ่งพา

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

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

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

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

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

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

4. ในโครงการเชิงพาณิชย์ขนาดใหญ่เทคโนโลยีที่เปลี่ยนแปลงเกิดขึ้นบ่อยกว่าที่คุณเชื่อ ตัวอย่างเช่นฉันต้องเปลี่ยนตัวแยกวิเคราะห์ XML ไปแล้ว 3 ครั้งเทคโนโลยีการแคช 2 ครั้งและซอฟต์แวร์ geolocalisation 2 ครั้ง สิ่งที่ดีที่ฉันได้ซ่อนรายละเอียดทั้งหมดไว้ในแพ็คเกจเฉพาะ ...

เป็นการทดลองที่น่าสนใจที่จะไม่ใช้แพ็คเกจเลย (ยกเว้นแพ็กเกจรูท)

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

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

จากมุมมองที่ใช้งานได้จริงโครงสร้างการมองเห็นของ java ช่วยให้คลาสในแพ็คเกจเดียวกันสามารถเข้าถึงเมธอดและคุณสมบัติที่มีprotectedและdefaultการมองเห็นได้เช่นเดียวกับpublicคน การใช้วิธีการที่ไม่ใช่สาธารณะจากชั้นรหัสที่แตกต่างกันโดยสิ้นเชิงจะทำให้เกิดกลิ่นเหม็นอย่างแน่นอน ดังนั้นฉันมักจะใส่คลาสจากเลเยอร์เดียวกันลงในแพ็คเกจเดียวกัน

ฉันไม่ได้ใช้วิธีการป้องกันหรือวิธีการเริ่มต้นที่อื่นบ่อยนักยกเว้นในการทดสอบหน่วยสำหรับชั้นเรียน - แต่เมื่อฉันทำเช่นนี้มักจะมาจากชั้นเรียนในชั้นเดียวกันเสมอ

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

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