많은 if/else 제거

일반적으로 우리 의 정상 적 인 백 스테이지 관리 시스템 은 이른바 역할 이라는 개념 을 가지 고 서로 다른 관리자 의 권한 이 다 르 고 행사 할 수 있 는 조작 도 다르다.예 를 들 어:

시스템 관리자(  ROLE_ROOT_ADMIN:있다  A조작 권한

주문서 관리자(  ROLE_ORDER_ADMIN:있다  B조작 권한

일반 사용자(  ROLE_NORMAL:있다  C조작 권한

예 를 들 어 한 사용자 가 들 어 오 면 우 리 는 서로 다른 사용자 의 역할 에 따라 어떤 행동 을 하 는 지 판단 해 야 한다.이때 SAO 코드 가 나 타 났 다.

public class JudgeRole{
   
public String judge(String roleName) {
        String result = "";
        if (roleName.equals("ROLE_ROOT_ADMIN"){//시스템 관리자 에 게 A 권한 이 있 음
            result = "ROLE_ROOT_ADMIN: " + "has AAA permission";
        } else if (roleName.equals("ROLE_ORDER_ADMIN"){//주문 관리 자 는 B 권한 이 있 습 니 다.
            result = "ROLE_ORDER_ADMIN: " + "has BBB permission";
        } else if (roleName.equals("ROLE_NORMAL"){//일반 사용 자 는 C 권한 이 있 습 니 다.
            result = "ROLE_NORMAL: " + "has CCC permission";
        } else {
            result = "XXX";
        }
        return result;
    } }
이렇게 시스템 에 몇 십 개의 캐릭터 가 있 을 때 그 몇 십 개의if/else패 치 는 매우 시큼 하고 시원 하 다 고 할 수 있다.이렇게 되면 매우 우아 하지 않 고 다른 사람 이 읽 기 에 매우 힘들다.둘째,앞으로 좀 더 복잡 하거나 조건 을 더 붙 이려 면 확장 하기 어렵다.그리고 코드 가 바 뀌 면 예전 의 오래된 기능 을 다시 측정 해 야 하 는데 미 치지 않 겠 습 니까?
그래서 다음 글 을 보지 않 고 골 치 아 픈 if/else 문 구 를 어떻게 대처 할 것 인가?
물론switch/case로 쓰 면 우아 하지 않 을 까?정 답 은 털 차이 가 없다!
다음은 몇 가지 개선 방식 을 간단하게 말 하고 더 이상if/else세상 을 떠 나 지 마라.
 매 거 가 있 는데 왜 안 써? 
어떤 캐릭터 가 무슨 일 을 할 수 있 는 지,이것 은 분명 대응 관계 가 있 기 때문에 배 운 것 은 왜 사용 하지 않 습 니까?
 
먼저 공용 인터페이스RoleOperation를 정의 하고 서로 다른 캐릭터 가 할 수 있 는 동작 을 표시 합 니 다.

public interface RoleOperation{  String op(); // op }
 
그 다음 에 우 리 는 서로 다른 캐릭터 의 상황 을 모두 매 거 진 유형 에 맡 기 고 서로 다른 캐릭터 가 서로 다른 권한 을 가 진 매 거 진 유형RoleEnum을 정의 한다.

public enum RoleEnum implements RoleOperation{ // ( A )
    ROLE_ROOT_ADMIN {
        @Override
        public String op() {
            return "ROLE_ROOT_ADMIN:" + " has AAA permission";
        }
    },     // ( B )
    ROLE_ORDER_ADMIN {
        @Override
        public String op() {
            return "ROLE_ORDER_ADMIN:" + " has BBB permission";
        }
    },     // ( C )
    ROLE_NORMAL {
        @Override
        public String op() {
            return "ROLE_NORMAL:" + " has CCC permission";
        }
    }; }
 
그 다음 에 호출 이 매우 간단 해 졌 습 니 다.코드 한 줄 이면 됩 니 다.if/else도 먼지 가 흩 날 리 고 연기 가 꺼 졌 습 니 다.

public class JudgeRole{  public String judge( String roleName ) {  // ！ if/else ！  return RoleEnum.valueOf(roleName).op();  } }
 
그리고 이렇게 되면 앞으로 만약 에 제 가 조건 을 확대 하고 싶다 면 매 거 진 유형 에 코드 를 추가 하면 됩 니 다.예전 의 코드 를 고 치 는 것 이 아니 라 안정 적 이지 않 습 니까?
매 거 진 것 으로 없 애 는 것 외 에 공장 모델 도 실현 할 수 있다.
 
 공장 모드 가 있 는데 왜 안 써 요? 
서로 다른 지점 에서 서로 다른 일 을 하 는 것 은 공장 모델 을 사용 하 는 계 기 를 제공 하 는 것 이 분명 하 다.우 리 는 서로 다른 상황 을 단독으로 정의 한 다음 에 공장 류 에 가서 집합 하면 된다.
먼저,서로 다른 역할 에 대해 업무 유형 을 단독으로 정의 한다.

if/else // ( A ) public class RootAdminRole implements RoleOperation{ private String roleName; public RootAdminRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has AAA permission"; }

} // ( B ) public class OrderAdminRole implements RoleOperation{ private String roleName; public OrderAdminRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has BBB permission"; }

} // ( C ) public class NormalRole implements RoleOperation{ private String roleName; public NormalRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has CCC permission"; }
 
다음은 공장 류}를 하나 더 써 서 위의 서로 다른 역할 을 취 합 한다.RoleFactory public class RoleFactory{ staticMap roleOperationMap = newHashMap<>(); // static{ roleOperationMap.put( "ROLE_ROOT_ADMIN", new RootAdminRole("ROLE_ROOT_ADMIN") ); roleOperationMap.put( "ROLE_ORDER_ADMIN", new OrderAdminRole("ROLE_ORDER_ADMIN") ); roleOperationMap.put( "ROLE_NORMAL", new NormalRole("ROLE_NORMAL") );
  } public static RoleOperation getOp( String roleName ) { return roleOperationMap.get( roleName ); }
 
그 다음 에 위의 이 공장 을 통 해 업무 코드 호출 도 한 줄 의 코드 만 있 으 면}역시 제거 되 었 다.if/else public class JudgeRole{ public String judge( String roleName ) { // ！ if/else ！ return RoleFactory.getOp(roleName).op(); }
 
이렇게 되면 앞으로 조건 을 확장 하 는 것 도 쉬 워 집 니 다.새로운 코드 만 추가 하고 예전 의 업무 코드 를 움 직 이지 않 아 도 됩 니 다.'개폐 원칙'에 매우 부합 합 니 다.
자,우리 이어서 공장 모델 을 제외 하고 전략 모델 도 한번 해 보 자.
 
 전략 모드 가 있 는데 왜 안 써 요? 
전략 모델 과 공장 모델 을 쓰 면 사실 차이 도 크 지 않다!
상기 공장 모델 코드 를 바탕 으로 전략 모델 의 지도 사상 에 따라 우 리 는 이른바 전략 문맥 류 를 만 들 었 다.여기 서}라 고 명명 했다.RoleContext public class RoleContext{ // ， ， private RoleOperation operation; public RoleContext( RoleOperation operation ) { this.operation = operation; } public String execute() { return operation.op(); }
 
위 에 들 어 오 는 매개 변수}는 서로 다른'전략'을 나타 내 는 것 이 분명 하 다.우 리 는 업무 코드 에 서로 다른 역할 을 전달 하면 서로 다른 조작 결 과 를 얻 을 수 있다.

operation public class JudgeRole{ public String judge( RoleOperation roleOperation ) { RoleContext roleContext = new RoleContext( roleOperation ); return roleContext.execute(); }

} public static void main( String[] args ) { JudgeRole judgeRole = new JudgeRole(); String result1 = judgeRole.judge(new RootAdminRole("ROLE_ROOT_ADMIN")); System.out.println( result1 ); String result2 = judgeRole.judge(new OrderAdminRole("ROLE_ORDER_ADMIN")); System.out.println( result2 ); String result3 = judgeRole.judge(new NormalRole("ROLE_NORMAL")); System.out.println( result3 );