ทำใหม่ฟังก์ชั่นกลับรหัสจำนวนเต็มที่แสดงถึงสถานะที่แตกต่างกัน

ฉันได้รับรหัสอันยิ่งใหญ่ที่ฉันได้รวมตัวอย่างสั้น ๆ ของด้านล่าง

• มีชื่อสำหรับรูปแบบการต่อต้านนี้โดยเฉพาะหรือไม่?

• มีคำแนะนำอะไรบ้างสำหรับการปรับโครงสร้างนี้

  // 0=Need to log in / present username and password
  // 2=Already logged in
  // 3=Inactive User found
  // 4=Valid User found-establish their session
  // 5=Valid User found with password change needed-establish their session
  // 6=Invalid User based on app login
  // 7=Invalid User based on network login
  // 8=User is from an non-approved remote address
  // 9=User account is locked
  // 10=Next failed login, the user account will be locked
  
  public int processLogin(HttpServletRequest request, HttpServletResponse response, 
                          int pwChangeDays, ServletContext ServContext) { 
  }
  

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

ฉันอยากจะแนะนำ refactoring ต่อไปนี้: คืนค่า enum ด้วยผลลัพธ์ที่เป็นไปได้ (ตามที่แนะนำในคำตอบอื่น ๆ ) แต่เพิ่มคุณสมบัติ enum ที่ระบุว่าเป็นการปฏิเสธการสละสิทธิ์ (ฉันจะให้คุณผ่านครั้งสุดท้ายนี้) หรือ ถ้ามันตกลง (PASS):

public LoginResult processLogin(HttpServletRequest request, HttpServletResponse response, 
                            int pwChangeDays, ServletContext ServContext) { 
    }

==> LoginResult.java <==

public enum LoginResult {
    NOT_LOGGED_IN(Severity.DENIAL),
    ALREADY_LOGGED_IN(Severity.PASS),
    INACTIVE_USER(Severity.DENIAL),
    VALID_USER(Severity.PASS),
    NEEDS_PASSWORD_CHANGE(Severity.WAIVER),
    INVALID_APP_USER(Severity.DENIAL),
    INVALID_NETWORK_USER(Severity.DENIAL),
    NON_APPROVED_ADDRESS(Severity.DENIAL),
    ACCOUNT_LOCKED(Severity.DENIAL),
    ACCOUNT_WILL_BE_LOCKED(Severity.WAIVER);

    private Severity severity;

    private LoginResult(Severity severity) {
        this.severity = severity;
    }

    public Severity getSeverity() {
        return this.severity;
    }
}

==> Severity.java <==

public enum Severity {
    PASS,
    WAIVER,
    DENIAL;
}

==> Test.java <==

public class Test {

    public static void main(String[] args) {
        for (LoginResult r: LoginResult.values()){
            System.out.println(r + " " +r.getSeverity());           
        }
    }
}

เอาต์พุตสำหรับ Test.java แสดงความรุนแรงของแต่ละ LoginResult:

NOT_LOGGED_IN : DENIAL
ALREADY_LOGGED_IN : PASS
INACTIVE_USER : DENIAL
VALID_USER : PASS
NEEDS_PASSWORD_CHANGE : WAIVER
INVALID_APP_USER : DENIAL
INVALID_NETWORK_USER : DENIAL
NON_APPROVED_ADDRESS : DENIAL
ACCOUNT_LOCKED : DENIAL
ACCOUNT_WILL_BE_LOCKED : WAIVER

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

แก้ไข:

เพื่อเป็นการตอบสนองต่อความคิดเห็นของ @ T.Sar ฉันได้เปลี่ยนค่าที่เป็นไปได้ของความรุนแรงเป็น PASS, WAIVER และ DENIAL แทน (ตกลง, คำเตือนและข้อผิดพลาด) วิธีนี้เป็นที่ชัดเจนว่า DENIAL (ข้อผิดพลาดก่อนหน้านี้) ไม่ใช่ข้อผิดพลาดต่อ se และไม่จำเป็นต้องแปลเป็นการโยนข้อยกเว้น โทรตรวจสอบวัตถุและตัดสินใจหรือไม่ที่จะโยนยกเว้น processLogin(...)แต่ปฏิเสธสถานะผลที่ถูกต้องที่เกิดจากการโทร

• ผ่าน:ไปข้างหน้าสร้างเซสชันหากยังไม่มี
• การสละสิทธิ์:ไปข้างหน้าในครั้งนี้ แต่ผู้ใช้ครั้งต่อไปคุณอาจไม่ได้รับอนุญาตให้ผ่าน
• ปฏิเสธ:ขออภัยผู้ใช้ไม่สามารถผ่านได้อย่าสร้างเซสชัน

นี่คือตัวอย่างของการครอบงำแบบดั้งเดิม - การใช้ประเภทดั้งเดิมสำหรับงาน "ง่าย" ซึ่งในที่สุดก็ไม่ง่ายนัก

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

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

สำหรับข้อมูลเพิ่มเติม refactoring รูปแบบที่อาจเป็นประโยชน์มีลักษณะที่อุตสาหกรรมลอจิกของกลิ่นจะ refactorings Cheatsheet

ฉันจะเรียกว่ากรณีของ "หมายเลขวิเศษ" - หมายเลขที่พิเศษและไม่มีความหมายที่ชัดเจนด้วยตัวเอง

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

นี่เป็นรหัสที่ไม่พึงประสงค์เป็นพิเศษ antipattern เรียกว่า "รหัสคืนเวทมนตร์" คุณสามารถค้นหาความคิดเห็นที่นี่

ค่าส่งคืนจำนวนมากระบุว่าสถานะข้อผิดพลาด มีการถกเถียงกันอย่างถูกต้องว่าจะใช้การจัดการข้อผิดพลาดสำหรับการควบคุมการไหล แต่ในกรณีของคุณฉันคิดว่ามี 3 กรณี: ความสำเร็จ (รหัส 4) ความสำเร็จ แต่ต้องเปลี่ยนรหัสผ่าน (รหัส 5) และ "ไม่อนุญาต" ดังนั้นหากคุณไม่สนใจการใช้ข้อยกเว้นสำหรับการควบคุมสายงานคุณสามารถใช้ข้อยกเว้นเพื่อระบุสถานะเหล่านั้นได้

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