ความสำคัญของชื่อโดเมนย้อนกลับสำหรับโครงสร้างแพ็คเกจ Java คืออะไร

ทำไมเราถึงใช้ชื่อโดเมนย้อนกลับเช่น com.something หรือ org.something โครงสร้างสำหรับแพ็คเกจ Java? ฉันเข้าใจว่าสิ่งนี้นำมาซึ่งความพิเศษบางอย่าง แต่ทำไมเราถึงต้องการความพิเศษนี้


java packages
person Vaishak Suresh    schedule 19.03.2010    source แหล่งที่มา
comment
จริงๆ แล้ว มันสอดคล้องกับหลักการที่ว่า ซ้ายไปขวาจะย้ายจากเรื่องทั่วไปไปสู่เรื่องเฉพาะเจาะจง ลองนึกถึงพาธของไฟล์หรือระบบทศนิยมดิวอี้ ในทางกลับกัน คุณสามารถถามว่าทำไมชื่อโดเมนถึงละเมิดระเบียบนี้ (หรือเหตุใดเราจึงเขียนวันที่ในลักษณะที่ไม่เป็นมิตรกับการเรียงลำดับ)   -  person harpo    schedule 19.03.2010
comment
@ฮาร์โป: จริงด้วย ชื่อโดเมนและวันที่ควรเขียนกลับกันจะดีกว่า   -  person Leo Jweda    schedule 19.03.2010
comment
ไวยากรณ์ server.domain.tld เป็นวิธีการแสดงออกถึงสิ่งต่าง ๆ ที่เป็นภาษาอังกฤษ (ตัวแก้ไขก่อนวัตถุ - ลูกบอลสีแดง) ตัวอย่างเช่น ภาษาสเปนมีไวยากรณ์ตัวแก้ไขอ็อบเจ็กต์แบบลอจิคัลมากกว่า (bola roja)   -  person dlchambers    schedule 02.07.2021

คำตอบ (6)


arrow_upward
36
arrow_downward

ชื่อแพ็คเกจที่ไม่ซ้ำกันทั่วโลกหลีกเลี่ยงการตั้งชื่อการชนกันระหว่างไลบรารีจากแหล่งที่ต่างกัน แทนที่จะสร้างฐานข้อมูลกลางใหม่ของชื่อสากล จะใช้การลงทะเบียนชื่อโดเมน จาก JLS:

แบบแผนที่แนะนำสำหรับการสร้างชื่อแพ็คเกจที่ไม่ซ้ำใครเป็นเพียงวิธีหนึ่งในการนำแบบแผนการตั้งชื่อแพ็คเกจกลับคืนมา นอกเหนือจากการลงทะเบียนชื่อเฉพาะที่มีอยู่และเป็นที่รู้จักกันอย่างแพร่หลาย แทนที่จะต้องสร้างรีจิสทรีแยกต่างหากสำหรับชื่อแพ็คเกจ

person Laurence Gonsalves    schedule 19.03.2010
comment
DNS ไม่มีส่วนเกี่ยวข้องกับมันเลย (+1 อยู่แล้ว) - person Fredrik; 19.03.2010
comment
@Fredrik ไม่มีการค้นหา DNS จริง ๆ แต่การลงทะเบียนชื่อเฉพาะที่เป็นที่รู้จักอย่างกว้างขวางที่อ้างถึงใน JLS คือระบบชื่อโดเมน - person Laurence Gonsalves; 19.03.2010

arrow_upward
46
arrow_downward

เกี่ยวกับสาเหตุที่เรากลับรายการ: ลองนึกภาพคุณมีแพ็คเกจที่สำคัญสองแพ็คเกจ ได้แก่ แพ็คเกจการบัญชี และแพ็คเกจกราฟิก หากคุณระบุสิ่งเหล่านี้ตามลำดับ 'ตรง':

accounting.mycompany.org
graphics.mycompany.org

จากนั้นก็บอกเป็นนัยว่ามีแพ็คเกจ accounting หลัก ซึ่งส่วนย่อยมีไว้สำหรับ mycompany และส่วนย่อยของแพ็คเกจ นั้น เรียกว่าแพ็คเกจ org ที่คุณใช้จริง อย่างไรก็ตาม คุณต้องการสิ่งนี้:

org.mycompany.accounting
org.mycompany.graphics

สิ่งนี้สมเหตุสมผลมากขึ้น จากแพ็คเกจทั้งหมดจากองค์กร (org) คุณดูที่ mycompany โดยเฉพาะ และมีสองแพ็คเกจย่อยคือ accounting และ graphics

person Claudiu    schedule 19.03.2010
comment
+1. โปรดทราบว่า (น่าเสียดาย?) Java ไม่มีการรองรับแพ็คเกจย่อย แพ็คเกจย่อยไม่ได้อยู่ใกล้กับพาเรนต์ (เท่าที่เกี่ยวข้องกับการมองเห็น) มากกว่าแพ็คเกจที่ไม่เกี่ยวข้องกันโดยสิ้นเชิง แน่นอนว่ายังคงมีประโยชน์สำหรับวัตถุประสงค์ในการจัดระเบียบโค้ด - person Thilo; 19.03.2010
comment
มันบอกเป็นนัยว่า org เป็นแพ็คเกจที่เป็นรูปธรรมเพราะคุณไม่ได้ดึงตัวอย่างของคุณออกมาอย่างสมบูรณ์ แล้วถ้าส่วนแรกเป็นบรรจุภัณฑ์คอนกรีตล่ะ? มันจะเป็นไปไม่ได้เหรอ? -1 Strawman ประเทศที่อ่านจากขวาไปซ้ายจะไม่เห็นด้วยที่นี่ :P - person sinni800; 12.09.2013
comment
@ sinni800: -1 ความคิดเห็นของคุณ เมื่อคุณเขียนโค้ดใน Java มันจะเขียนจากซ้ายไปขวา นอกจากนี้ เมื่อคุณมี a.b.c.d หมายความว่าคุณเริ่มต้นด้วยคลาส a โดยซ้อนลงในฟิลด์ b ซ้อนกับ c ของฟิลด์นั้น จากนั้นซ้อนกับ d ของฟิลด์นั้น การจัดระเบียบแพ็คเกจแบบอะนาล็อกควรทำงานเหมือนกัน นอกจากนี้ในแพ็คเกจย่อยของแพ็คเกจ Python จริง ๆ แล้วทำตามที่ฉันเขียนไว้ที่นี่ ดังนั้นมันจึงเป็นไปไม่ได้แต่มันจะเป็นเรื่องปัญญาอ่อน - person Claudiu; 12.09.2013
comment
@Claudiu แต่มีบางส่วนของภาษา (สืบทอดมาจากไวยากรณ์สไตล์ C) โดยที่แม้ว่าจะมีการอ่านจากซ้ายไปขวา แต่ก็มีสไตล์จากขวาไปซ้าย (ในแง่ของคำ ไม่ใช่อักขระ สำหรับ ตัวอย่างคำจำกัดความของฟังก์ชัน Return type มาก่อน แม้ว่าในฐานะมนุษย์คุณจะไม่ใส่สิ่งนั้นไว้ก่อนก็ตาม) ฉันแค่พยายามบอกว่าไม่มีความจริงสากลที่แพ็คเกจย่อยต้องไปจากซ้ายไปขวา แต่ฉันไม่รู้เกี่ยวกับเรื่องงูหลาม - person sinni800; 12.09.2013
comment
@sinni800: อืม ใช่ ทุกอย่างมันเป็นเรื่องของการประชุม ด้านซ้าย->ขวาเป็นแบบทั่วไป->เฉพาะเจาะจงมากขึ้นนั้นค่อนข้างธรรมดาแม้ว่า ... คุณสามารถตั้งชื่อภาษาการเขียนโปรแกรมใด ๆ ที่มีแพ็คเกจและไม่ทำจากซ้ายไปขวาได้หรือไม่? - person Claudiu; 12.09.2013
comment
@Claudiu ฉันไม่สามารถขอโทษ มันเป็นเพียงความคิดและพยายามที่จะงัดความคิดแบบเดิม ๆ ออกไปเล็กน้อย แต่ตัวอย่างเช่น Golang ที่มีแพ็คเกจภายนอกจะใช้ชื่อโฮสต์/โปรเจ็กต์ github.com/youruser/yourproject เป็นต้น พวกเขาไม่ได้แยกตามส่วนของชื่อโฮสต์ แต่จะแยกตามชื่อโฮสต์จริงกับชื่อโครงการ Golang สอนฉันมากมายเกี่ยวกับสิ่งเหล่านี้ และมันเบี่ยงเบนไปจากไวยากรณ์ C ปกติ: var name string, func name(parameters) returnType... - person sinni800; 13.09.2013
comment
@ sinni800: ฉันใช้ Haskell ซึ่งมีการประกาศประเภทตามที่คุณพูด (foo :: Int -> Int หมายถึง foo มีประเภทฟังก์ชันที่รับ int และส่งกลับ int) ฉันเห็นว่ามันได้ผลไม่ทางใดก็ทางหนึ่ง แต่โอเค ลองพิจารณาสิ่งนี้ - สมมติว่าคุณมีแพ็คเกจตามลำดับที่คุณแนะนำใน Java ดังนั้น accounting.project เป็นส่วนย่อยทางบัญชีของ project และ reporting.project เป็นส่วนย่อยของการรายงานของ project ตอนนี้คุณมีคลาสในแต่ละ accounting.project.AccountManager และ reporting.project.ReportGenerator... ดูไม่ผิดเหรอ? เป็นการผสมผสานสองแบบแผนไว้ในที่เดียว - person Claudiu; 13.09.2013
comment
@ sinni800: หรือถ้าคุณมีคลาสย่อย account.project.AccountManager.FooBit กับ reporting.project.ReportGenerator.ReportingSubsystem ตอนนี้ครึ่งซ้ายของชื่อเป็นแบบเจาะจง -> ทั่วไป แต่ครึ่งขวาเป็นชื่อทั่วไป -> เฉพาะ ฉันเห็นว่ามันทำงานตามที่คุณพูดถ้าไวยากรณ์สำหรับการเข้าถึงฟิลด์นั้นทำงานโดยนำสิ่งต่าง ๆ ไว้ข้างหน้าทางด้านซ้าย แต่มันไม่ทำงานแบบนั้นใน Java - person Claudiu; 13.09.2013
comment
@Claudiu โอเค ถ้าเราพยายามที่จะเปลี่ยนมันสักเล็กน้อย... account.project::AccountManager (นี่ยังดูแย่มาก แต่ตอนนี้ความแตกต่างอยู่ที่นี่แล้ว) ... ทุกอย่างอาจมีวิธีแก้ปัญหา แต่สิ่งที่คุณ แนะนำไม่ได้จริงๆ ฉันไม่เคยอยากจะแนะนำอะไรแบบนั้นเลยบอกตามตรง - person sinni800; 13.09.2013
comment
ให้เราสนทนาต่อในการแชท - person Claudiu; 13.09.2013
comment
มันสมเหตุสมผลมากกว่า เว้นแต่คุณจะเคยใช้อินเทอร์เน็ตมาก่อน ในกรณีนี้ มันเป็นเรื่องอวดรู้โดยไม่จำเป็น - person Erik Aronesty; 06.09.2018

arrow_upward
4
arrow_downward

อย่างที่คุณพูด การกลับชื่อโดเมนเป็นชื่อแพ็คเกจพื้นฐานจะทำให้มั่นใจถึงความเป็นเอกลักษณ์ สมมติว่าสองบริษัทที่มี DN example.com และ example.org ต่างก็กำหนดคลาส Employee ในกรอบงานของตน ตอนนี้หากคุณใช้ทั้งสองเฟรมเวิร์ก คุณจะไม่สามารถระบุได้ว่า Employee คนไหนที่คุณต้องการใช้ในโค้ดของคุณ แต่หากถูกกำหนดไว้ในแพ็คเกจ com.example และ org.example ตามลำดับ คุณสามารถบอกคอมไพเลอร์/JVM โดยเฉพาะว่าคุณอยู่ในคลาสใด อ้างถึง. หากไม่ได้กำหนดแพ็คเกจเฉพาะ คุณจะได้รับข้อผิดพลาดในการคอมไพล์หรือข้อผิดพลาดรันไทม์ เช่น หากคุณใช้คลาสพนักงาน com แต่คลาสพนักงานขององค์กรถูกโหลดก่อนจาก classpath คุณจะได้รับข้อผิดพลาดรันไทม์ เนื่องจากคลาสพนักงานทั้งสองคลาสอาจมีโครงสร้างไม่เหมือนกัน

person saugata    schedule 19.03.2010

arrow_upward
3
arrow_downward

การโหลดคลาสต้องมีเอกลักษณ์เฉพาะตัว

ซึ่งช่วยได้โดยการหลีกเลี่ยงการชนกันของชื่อ หากมีคลาสที่มีชื่อแพ็กเกจและชื่อคลาสเหมือนกัน การชนกันจะเกิดขึ้นขณะพยายามโหลดคลาส

โดยทั่วไปจะเกิดขึ้นหากมีไลบรารีหลายรายการ (jar) ที่มีคลาสที่มีชื่อเหมือนกัน
< br> โปรดดูสิ่งนี้ด้วย

person Padmarag    schedule 19.03.2010
comment
คุณกำลังพูดถึงการโหลดประเภทใด? และการตั้งชื่อที่ไม่ซ้ำกันป้องกันการชนกันที่อาจเกิดขึ้นได้อย่างไร ฉันคิดว่าข้อขัดแย้งใด ๆ ที่เกิดขึ้นระหว่างการโหลดจะเกิดขึ้นหากชื่อคลาสเหมือนกัน - person Vaishak Suresh; 19.03.2010
comment
@Vaishak: สมมติฐานนั้นเป็นเท็จ ชื่อเฉพาะที่ระบุคลาสคือแพ็คเกจ + ชื่อคลาส หากคุณอยู่ในแพ็คเกจเดียวกันหรือหากคุณนำเข้าแพ็คเกจหรือชื่อคลาสที่มีคุณสมบัติครบถ้วนโดยเฉพาะ คุณสามารถใช้ชื่อได้เท่านั้น เช่นเดียวกับการโทรออก โดยปกติคุณไม่จำเป็นต้องระบุรหัสพื้นที่หากคุณอยู่ในรหัสเดียวกันอยู่แล้ว แต่หมายเลขโทรศัพท์ทั้งหมดที่คุณแจกจะยังมีรหัสพื้นที่อยู่ - person Fredrik; 19.03.2010
comment
@Fredrik สมมติฐานของฉันสอดคล้องกับคำอธิบายของคุณ :) นั่นคือเหตุผลที่ฉันบอกว่าข้อขัดแย้งเกิดขึ้นหากชื่อคลาส ยัง เหมือนกัน แต่ตอนนี้คำถามของฉันได้รับคำตอบแล้ว ขอบคุณ! - person Vaishak Suresh; 19.03.2010

arrow_upward
0
arrow_downward

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

นอกจากนี้ยังใช้เมื่อมีการสร้างโค้ดโดยเป็นส่วนหนึ่งของโปรเจ็กต์ต่างๆ ในองค์กร

person Stephen C    schedule 19.03.2010

arrow_upward
0
arrow_downward

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

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

person Kim L    schedule 19.03.2010