多くの異なるステータスを表す整数コードを返す関数を作り直す

私は、以下の短いサンプルを含めたいくつかのひどいコードを継承しました。

• この特定のアンチパターンに名前はありますか？

• これをリファクタリングするための推奨事項は何ですか？

  // 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) { 
  }
  

マジックナンバーが原因でコードが悪いだけでなく、エラー、警告、セッションを作成する権限、または3つを組み合わせた許可を意味する内部に隠れて、戻りコードのいくつかの意味が合体しているため、意思決定のための悪い入力。

私は次のリファクタリングをお勧めします：可能な結果を​​含む列挙型を返します（他の回答で提案されているように）が、拒否であるか、権利放棄であるかを示す属性を列挙型に追加します（これは最後に渡します）またはOK（パス）の場合：

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());           
        }
    }
}

各LoginResultの重大度を示すTest.javaの出力：

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

列挙値とその重大度の両方に基づいて、セッションの作成を続行するかどうかを決定できます。

編集：

@ T.Sarのコメントへの応答として、重大度の可能な値を（OK、WARNINGおよびERROR）ではなくPASS、WAIVERおよびDENIALに変更しました。そうすれば、DENIAL（以前はERROR）自体がエラーではなく、必ずしも例外のスローに変換されるべきではないことは明らかです。呼び出し元はオブジェクトを調べ、例外をスローするかどうかを決定しますが、DENIALはを呼び出した結果の有効な結果ステータスですprocessLogin(...)。

• 合格：セッションがまだない場合は、セッションを作成してください。
• 権利放棄：今回は先に進みますが、次回ユーザーは合格することができない場合があります
• 拒否：申し訳ありませんが、ユーザーはパスできず、セッションを作成しません

これはプリミティブオブセッションの例です。「単純な」タスクにプリミティブ型を使用すると、最終的にはそれほど単純ではなくなります。

これはbool、成功または失敗を示すためにを返し、次にint3番目の状態があったときにに変わり、最終的に文書化されていないエラー条件の完全なリストになったコードとして始まった可能性があります。

この問題の一般的なリファクタリングは、問題の値をより適切に表すことができる新しいクラス/構造体/列挙型/オブジェクト/何でも作成することです。この場合、enum結果条件を含む、またはbool成功または失敗のfor、エラーメッセージ、追加情報などを含む可能性のあるクラスに切り替えることを検討できます。

役立つかもしれないより多くのリファクタリングパターンについては、Industrial LogicのSmells to Refactorings Cheatsheetをご覧ください。

私はそれを「マジックナンバー」のケースと呼びます-特別であり、それ自体には明らかな意味がない数字です。

ここで適用するリファクタリングは、戻り値の型を列挙型に再構成することです。これは、ドメインの問題を型にカプセル化するためです。Java列挙型は注文して番号を付けることができるので、そこから発生するコンパイルエラーの処理は少しずつ可能です。そうでない場合でも、intにフォールバックするのではなく、直接処理することは難しくありません。

これは特に不愉快なコードです。アンチパターンは「マジックリターンコード」として知られています。ここでディスカッションを見つけることができます。

戻り値の多くはエラー状態を示します。フロー制御にエラー処理を使用するかどうかについては有効な議論がありますが、あなたの場合、成功（コード4）、成功だがパスワードを変更する必要がある（コード5）、「許可されていない」の3つのケースがあると思います。したがって、フロー制御に例外を使用する必要がない場合は、例外を使用してそれらの状態を示すことができます。

もう1つのアプローチは、設計をリファクタリングして、成功したログインの「プロファイル」属性と「セッション」属性、必要に応じて「must_change_password」属性、およびログの理由を示す一連の属性を含む「ユーザー」オブジェクトを返すことです。それがフローの場合、-inは失敗しました。