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

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

และด้วยเครื่องมือ IDE และอัตราส่วนการอ่าน - เขียนของการเขียนโค้ดฉันจะมีความสุขมากขึ้นในการสร้าง Enum พิเศษโดยอัตโนมัติมากกว่าการส่งผ่านค่าสตริง

พวกเขานำประโยชน์อะไรมาให้เราในฐานะโปรแกรมเมอร์ จานหม้อไอน้ำน้อยลงหรือไม่

ไม่รู้สึกว่าภาษากำลังใช้งานคุณสมบัตินี้ แม้ว่าอาจจะมีกรณีการใช้งานที่ฉันมองเห็น

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

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

ข้อได้เปรียบที่สำคัญ: อะไรทำให้ข้อเสนอเปลี่ยนไปในทางที่ดี?

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

ผลประโยชน์ที่สำคัญ: เหตุใดแพลตฟอร์มจึงดีกว่าหากมีการนำข้อเสนอมาใช้

ประสิทธิภาพที่ดีขึ้นอาจเป็นไปได้สำหรับรหัสการแจกจ่ายตามสตริง

ความผิดพลาดที่สำคัญ: มีค่าใช้จ่ายเสมอ

เพิ่มการใช้งานและทดสอบความซับซ้อนสำหรับคอมไพเลอร์

ทางเลือก: ประโยชน์และข้อได้เปรียบสามารถเกิดขึ้นได้โดยไม่ต้องเปลี่ยนภาษาหรือไม่?

ไม่มี การทดสอบ if-then-else สำหรับความเท่าเทียมกันของสตริงอาจมีราคาแพงและแนะนำ enum สำหรับค่าคงที่แบบเปลี่ยนได้หนึ่งค่าต่อสตริงที่น่าสนใจจะเพิ่มประเภทอื่นให้กับโปรแกรมโดยไม่มีสาเหตุที่ดี ...

นอกเหนือจากการทำให้โค้ดอ่านง่ายขึ้นแล้วยังมีการเพิ่มประสิทธิภาพที่เป็นไปได้เมื่อเทียบกับif/else ifการเปรียบเทียบ การเปลี่ยนแปลงนั้นคุ้มค่าหรือไม่นั้นขึ้นอยู่กับว่าคุณจะทำการเปรียบเทียบกี่ครั้ง สวิทช์สตริงจะถูกปล่อยออกมาเป็นสองคำแนะนำในการสลับแยก ตัวแรกทำงานกับรหัสแฮชดังนั้นจึงมีแนวโน้มที่จะเป็นไปได้lookupswitchในที่สุดทำให้เกิดO(log n)ความซับซ้อน ที่สองนั้นสมบูรณ์แบบอยู่เสมอO(1) tableswitchดังนั้นความซับซ้อนที่รวมกันจึงยังคงO(log n)อยู่ if/else ifคำแถลงเชิงเส้นตรงเชิงเส้นเดียวจะให้O(n)ความซับซ้อนที่แย่กว่าเล็กน้อย

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

สวิตช์สำหรับสตริงสามารถใช้เมื่อenumค่าของคุณมาจากภายนอกเช่นเก็บไว้ในฐานข้อมูล

อีกสิ่งที่น่าสังเกตใน JDK 7 switchคือมันมีความสมบูรณ์มากกว่าการif-elseสร้าง

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

ความง่าย

การสนับสนุน String ใน Switch มีประโยชน์สำหรับการประมวลผลข้อมูลโดยไม่ต้องแปลงเป็น enum หรือif-elseตรรกะ บางครั้งการเปิดใช้งาน String จะง่ายกว่า

จากข้อเสนอคุณสมบัติที่ JDK 7 (Project Coin) รายชื่อผู้รับจดหมาย ( @gnat answer )

การแนะนำ enum สำหรับค่าคงที่แบบสลับได้หนึ่งค่าต่อสตริงที่น่าสนใจจะเพิ่มประเภทอื่นให้กับโปรแกรมโดยไม่มีสาเหตุที่ดี ...

รุ่น If-Else

นี่สั้น แต่หลายif'sเล่มอ่านยาก และนี่คือช้า

if (color.equals("red")) {
    System.out.println("Color is Red");
} else if (color.equals("green")) {
    System.out.println("Color is Green");
} else {
    System.out.println("Color not found");
}

รุ่น Enum

จำเป็นต้องกำหนด Enums นี่เป็นสิ่งที่ดี แต่บางครั้งก็ไม่จำเป็น

enum Color {RED, GREEN}

ประมวลผลตามปกติ

try {
    switch (Color.valueOf(color)) {
        case RED:
            System.out.println("Color is Red");
            break;
        case GREEN:
            System.out.println("Color is Green");
            break;
    }
} catch (IllegalArgumentException e) {
    System.out.println("Color not found");
}

JDK 7 - เงื่อนไขในเวอร์ชันงบสวิตช์

เราสามารถดำเนินการได้โดยไม่ต้องแปลงและกำหนดประเภทเพิ่มเติม

switch (color) {
    case "red":
        System.out.println("Color is Red");
        break;
    case "green":
        System.out.println("Color is Green");
        break;
    default:
        System.out.println("Color not found");
}

การปรับปรุงส่วนใหญ่ในภาษาใด ๆ คือการทำให้โค้ดอ่านง่ายขึ้น ฉันชอบรหัสที่อ่านได้มากกว่าแฟนซีทุกวัน

คุณอาจไม่เชื่อสิ่งนี้ แต่ลอง:

public enum JettStaff {
  ADRIAN("Adrian German") {
    public String toString() {
      return name + " (dgerman@indiana.edu)";
    }
  },
  ARJIT("Arjit Sengupta") {
    public String toString() {
      return name + " (asengupt@indiana.edu)";
    }
  },

  // and on for the rest...

  private String name;

  public JettStaff(String n) { this.name = n; }
}

JettStaff x = JettStaff.SUZANNE;
System.out.println(x);

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

  if (something.equals("foo")) {
    // foo processing
  } else 
  if (something.equals("bar")) {
   // bar processing
  }

คุณยังสามารถใช้ enums ในกรณีนี้โดยเพียงแค่พยายามรับค่าเหล่านั้นตามชื่อและ / หรือโดยการกำหนด String-> Enum ประจำ แต่บางครั้งก็เป็นไปไม่ได้หรือไม่จริง (เช่นเมื่อคุณต้องสร้าง enums มากเกินไป)

TLDR : คุณควรใช้ Enums อย่างแน่นอนเมื่อคุณทำงานกับโค้ด Java อย่างหมดจด แต่ไม่สามารถทำกับวัตถุภายนอกได้เสมอไป ฉันหวังว่าคำอธิบายของฉันจะสมเหตุสมผล

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

หากคุณมีค่าฮาร์โค้ดที่คุณใช้คำสั่ง if-elseif การใช้ค่าดั้งเดิมคงที่สำหรับพวกเขานั้นดีกว่าก่อนหน้า Java 1.5 เพียงเพราะมันนำความปลอดภัยมาให้

ตกลงจะมีสถานการณ์ที่คุณจะได้รับค่าสตริง (จากคำขอ HTTP, ไฟล์ ฯลฯ ) และแปลงเป็นค่าดั้งเดิมคือความเจ็บปวด แต่Enumตอนนี้ทำงานได้ดี เพราะเมื่อคุณต้องการเปลี่ยนค่าที่คุณเก็บไว้ใน Enum เพียงแค่เปลี่ยนเมื่อคุณประกาศ ไม่จำเป็นต้องเปลี่ยนอะไรในรหัสของคุณ (แน่นอนคุณต้องเปลี่ยนค่าที่เก็บไว้ที่อื่น)

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

ถ้าคุณรู้ว่าข้อมูลที่มาในและว่ามันอาจจะเป็นของ 5 Enumรัฐแล้วใช้ อย่างไรก็ตามหากสถานะที่เป็นไปได้อาจมากกว่า 9000 และคุณต้องการเพียง 42 เท่านั้นการใช้สวิตช์จะดีกว่าเพราะคุณไม่ต้องการพิมพ์สถานะเหล่านั้นทั้งหมด

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

แต่ทำไมพวกเขาถึงแนะนำมันตอนนี้ มันเป็นเพียงการเปลี่ยนแปลงที่อนุญาตให้ใช้โค้ดที่สะอาดกว่า

ใน 1.5 พวกเขายังอนุญาตให้คุณสร้างเนื้อหาที่กำหนดเองสำหรับ Enums อีกด้วย