มันจะดีกว่าที่จะใช้สตริงหรือ int เพื่ออ้างอิง enums นอกส่วน java ของระบบ?

เรากำลังคุยกันเรื่องงานของฉันเกี่ยวกับการใช้ enums ใน Java

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

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

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

มีวิธีปฏิบัติที่ดีที่สุดเกี่ยวกับการสนทนานี้ที่สามารถแนะนำฉันได้ไหม

แก้ไข: เมื่อใดก็ตามที่เป็นไปได้เราจะใช้ enum เองดังนั้นโค้ด Java ของเราจึงใช้ Enum โดย "อ้างอิงถึง enum" ฉันหมายถึง: การอ้างอิงค่าใน enum เมื่อแลกเปลี่ยนข้อมูลจาก JavaScript ไปยังเซิร์ฟเวอร์หรือจัดเก็บข้อมูลในฐานข้อมูล

java programming-practices enum

— JSBach
แหล่งที่มา

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

— Kilian Foth

ฉันได้แก้ไขคำถามและฉันหวังว่าชัดเจนตอนนี้: โดย "อ้างอิงถึง enum" ฉันหมายถึงการอ้างอิงค่าเมื่อแลกเปลี่ยนข้อมูลจาก JavaScript ไปยังเซิร์ฟเวอร์หรือวิธีอื่น ๆ หรือเก็บค่าในฐานข้อมูล

— JSBach

ในจาวาสคริปต์ API ฉันใช้สตริงอย่างแน่นอน ในฐานข้อมูลทั้งสองมีข้อดีของพวกเขา ฐานข้อมูลบางตัวมีการสนับสนุน enum

— CodesInChaos

คำตอบ:

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

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

เจ้านายของคุณบอกคุณว่าลูกค้ามีปัญหากับการใช้ซอฟต์แวร์ของคุณหลังจากการอัพเดตครั้งล่าสุด ตอนนี้เอนทิตี X ทำหน้าที่เหมือนพวกเขาได้รับการกำหนดค่า enum Y แม้ว่าพวกเขาจะได้รับมอบหมาย Z จริง ๆ คุณตรวจสอบที่เก็บและใช่มีคนเพิ่มค่า enum ใหม่และไม่ปฏิบัติตามแนวทางของคุณตามที่คุณขอ ตอนนี้คุณมีภาวะแทรกซ้อนที่เพิ่มเข้ามาในฐานข้อมูลมันถูกเขียน 4 เมื่อมันควรจะเป็น 3 ไม่รวมระเบียนที่ถูกแทรกก่อนการอัพเดทที่เป็นจริง4 ค่า enum เกี่ยวข้องกับ 4 อย่างไร ไม่ใช่เหรอ คุณจำไม่ได้ คุณต้องตรวจสอบโปรแกรมเพื่อตรวจสอบ พูดง่ายๆก็คือมันรก

หากฐานข้อมูลของคุณเขียนว่า "HEARTS", "DIAMONDS", "SPADES", "CLUBS" คุณเสียพื้นที่น้อยและได้รับมาก เป็นเรื่องจริงที่เรากำลังพูดถึงประสิทธิภาพเล็กน้อย แต่คุณไม่ควรเข้าถึงฐานข้อมูลที่มักจะสร้างความแตกต่าง สำหรับพื้นที่ให้เว้นไว้กับผู้ดูแลระบบ (ไม่ใช่. ปัญหาของคุณ)

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

— นีล
แหล่งที่มา

จุดที่ดี แต่คุณลืมเกี่ยวกับกรณีที่มีคนตัดสินใจที่จะเปลี่ยนชื่อของหนึ่งในหน่วยงาน enum ( HEARTSเป็นHeartหรือบางอย่างในตัวอย่างของคุณ) และทุกอย่างก็แตกอีกครั้ง

— Scott Whitlock

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

— Neil

@Neil - จริง แต่เรากำลังพยายามเล่นที่นี่ ฉันไม่คุ้นเคยกับ Java enums แต่ใน C # ฉันจะกำหนดค่าสำหรับ enums อย่างชัดเจนหากค่าจำเป็นต้องมีความหมายภายนอกโปรแกรม (เช่นในฐานข้อมูล) (เช่น Hearts = 1, Diamonds = 2 เป็นต้น) . เนื่องจากไม่ใช่วิธีเริ่มต้นในการใช้ enum จึงควรให้ตัวแก้ไขหยุดทำงานชั่วคราวในภายหลัง บวกกับความคิดเห็นที่สังเกตว่าสิ่งเหล่านี้มีการใช้งานที่สะดวก

— Scott Whitlock

@ScottWhitlock นั่นเป็นวิธีที่ดีกว่าในการหลีกเลี่ยงปัญหาดังกล่าว แม้ว่าสมมติว่าคุณทำเช่นนั้นคุณยังคงเห็น 1, 2, 3, 4 ในฐานข้อมูลหรือต่อเนื่องในบางไฟล์ ไม่เหมาะจากมุมมองการบำรุงรักษาที่คุณจะเชือดมัน

— Neil

ถ้าฉันอาจเพิ่มถ้า enum เป็นอนุกรมเป็นสตริงและมีคนเปลี่ยนชื่อของ enum ในระหว่าง deserialization ข้อผิดพลาดจะอยู่ในระหว่างการแยก หาก enum เป็น int และบางคนเปลี่ยนนิยามข้อผิดพลาดจะลดลงไปอีกในระหว่างการประมวลผลซึ่งจะยากต่อการวินิจฉัย CC @ScottWhitlock

— จบ Tjahjono

ฉันเห็นด้วยกับคำตอบของ Neil แต่เพียงเพิ่ม:

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

มันจะอยู่รอดทั้งการเพิ่ม / ลบ / การเรียงลำดับใหม่และการเปลี่ยนชื่อของตัวอย่าง enum แต่คุณจะต้องเขียนลอจิกอนุกรม / ดีซีเรียลไลเซชันสำหรับฟิลด์ enum แทนที่จะใช้ automagic ที่มีอยู่ในเครื่องมือจำนวนมาก (มันง่าย แต่มัน aditional งาน)

และคุณต้องรักษาค่าเหล่านั้นด้วยตนเอง (แต่เหมือนกันใน C style enums) และคุณสามารถเขียนการทดสอบเพื่อตรวจสอบว่า

— user470365
แหล่งที่มา

ใช่เราลงเส้นทางนี้ แต่เราใช้โหมดไฮเบอร์เนตและเราต้องเพิ่มรหัสพิเศษบางอย่างเพื่อให้สามารถแยกค่าไปยัง / จากฐานข้อมูลและดูเหมือนแปลก ๆ ดังนั้นเราจึงตัดสินใจใช้ความสัมพันธ์. STRING และ ไปกับชื่อ enum

— JSBach