ชื่อแพ็คเกจควรเป็นแบบเอกพจน์หรือพหูพจน์

227

บ่อยครั้งที่ในไลบรารีโดยเฉพาะแพ็คเกจประกอบด้วยคลาสที่ถูกจัดระเบียบรอบ ๆ แนวคิดเดียว ตัวอย่าง: XML, SQL, การใช้งานการตั้งค่า, DB ผมคิดว่าเราทุกคนรู้สึกรักธรรมชาติที่แพคเกจเหล่านี้ถูกต้องในเอกพจน์

com.myproject xml .
โครงการส่วนเสริมทั้งหมด SQL .Connection
com.myproject ผู้ใช้ .User
com.myproject ผู้ใช้. UserFactory

อย่างไรก็ตามถ้าฉันมีแพ็คเกจที่มีชุดของการใช้งานประเภทเดียว - เช่นงาน, กฎ, ตัวจัดการ, แบบจำลอง ฯลฯซึ่งเป็นที่นิยมมากกว่า?

com.myproject ภารกิจ. TakeOutGarbageTask
com.myproject ภารกิจ. DoTheDishesTask
com.myproject งาน.เพ้นท์เฮาส์เฮาส์

หรือ

com.myproject ภารกิจ. TakeOutGarbageTask
com.myproject ภารกิจ. DoTheDishesTask
com.myproject task .PaintTheHouseTask

object-oriented naming packages

— นิโคล
แหล่งที่มา

เอกพจน์เช่นเดียวกับชื่อตารางฐานข้อมูลควรเป็นเอกพจน์ แต่ด้วยเหตุผลที่แตกต่างกัน ดูไลบรารีมาตรฐานที่เป็นที่นิยมเช่น Java หรือ Python

@Jarrod Roberson: โปรดโพสต์คำตอบของคุณเป็นคำตอบเพื่อให้เราสามารถโหวตได้อย่างถูกต้อง

— S.Lott

@Jarrod จะต้องมีตัวอย่างเนื่องจากในไลบรารีมาตรฐานคลาสส่วนใหญ่จะอยู่ในหมวดหมู่แรกที่ฉันแสดง

— นิโคล

@Renesis ลองดูคำตอบที่อัปเดตของฉัน

— Matthew Rodatus

@ Matthews - ฉันชอบมัน คุณได้แสดงสิ่งที่ฉันสงสัย แต่ไม่แน่ใจว่าจะประมวลผลอย่างไร

— นิโคล

คำตอบ:

293

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

คลาสคล้ายกับความสัมพันธ์ของฐานข้อมูล ความสัมพันธ์ของฐานข้อมูลควรถูกตั้งชื่อในเอกพจน์เนื่องจากบันทึกนั้นถือเป็นอินสแตนซ์ของความสัมพันธ์ ฟังก์ชั่นของความสัมพันธ์คือการเขียนบันทึกที่ซับซ้อนจากข้อมูลอย่างง่าย

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

ยกตัวอย่างเช่นชนิดควรตั้งชื่อTaskCollectionแทนมันเป็นคอลเลกชันที่มีกรณีของTasksCollection Taskแพ็คเกจที่มีชื่อcom.myproject.taskไม่ได้หมายความว่าแต่ละคลาสที่บรรจุไว้เป็นอินสแตนซ์ของงาน อาจจะมีTaskHandlerที่TaskFactoryอื่น ๆ แพคเกจที่มีชื่อว่าcom.myproject.tasksอย่างไรจะมีประเภทที่แตกต่างกันที่มีงานทั้งหมด: TakeOutGarbageTask, DoTheDishesTaskฯลฯ

— Matthew Rodatus
แหล่งที่มา

สำหรับคำถามที่คล้ายกันดูenglish.stackexchange.com/q/25713 หมวดหมู่จะคล้ายคลึงกับเอกพจน์และประเภทจะคล้ายคลึงกับพหูพจน์

— Matthew Rodatus

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

— SkyDan

คำตอบที่ดี แต่ฉันไม่เห็นด้วยกับตรรกะความสัมพันธ์ของฐานข้อมูล ความสัมพันธ์ใน ERD นั้นเป็นเอกพจน์เนื่องจากแสดงความสัมพันธ์ระหว่างเอนทิตี ตารางเป็นการดำเนินการทางกายภาพของความสัมพันธ์และพวกเขามีหลายแถวและควรเป็นพหูพจน์ IMO คำตอบของ "สิ่งที่อยู่ในตารางนี้?" คือ "ผู้ใช้" ไม่ใช่ "ผู้ใช้" ได้รับดูเหมือนว่าการตั้งชื่อเอกพจน์นั้นมีอยู่ทั่วไปในโลกธุรกิจ (C #, Java) มากกว่าในชุมชนเช่น Ruby, Python, Javascript และ PHP

— ryeguy

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

— Vicky Chijwani

@VickyChijwani @SkyDan ตั้งแต่ JavaBeans java.beans™เป็นเครื่องหมายการค้าที่พวกเขาอาจจะอยากให้ชื่อตามที่เป็นในการอ้างถึงเทคโนโลยีตัวเองและด้วยเหตุนี้พวกเขาใช้

— Hejazi

สิ่งนี้อาจขึ้นอยู่กับภาษาเฉพาะ ใน. NET (C #) แน่นอนที่สุดควรเป็นพหูพจน์หากการชนกันของชื่อเนมสเปซชนิดนั้นมีแนวโน้มที่จะเกิดขึ้น ( type name expected but namespace foundข้อผิดพลาด) ฉันได้รับการจัดการกับสิ่งนี้มันไม่น่าพอใจและผลลัพธ์ในชื่อประเภทที่มีคุณสมบัติเกินกำหนดทั่วรหัส ตัวอย่าง

— ห้องเล็ก
แหล่งที่มา