if - else 가 너무 깊 게 박 혀 있다 고요?초보 자 들 이 다 파악 할 수 있 는 디자인 모델 을 알려 줄 게!

저자 l 남 산사자
출처 l Hollis (ID: hollischuang)
나 도 디자인 안 해도 돼.
많은 사람들 이 자신 이 쓴 것 이 업무 코드 라 고 생각 하고 논리 적 으로 쓴 다음 에 공용 방법 을 추출 하여 재 활용 하면 된다. 디자인 모델 은 전혀 사용 할 필요 도 없고 배 울 필요 도 없다.
처음 엔 나 도 그렇게 생각 했 어. 내 가 만 날 때 까지...
밤 을 들다
우 리 는 먼저 일반적인 하단 차단 인 터 페 이 스 를 보 았 다.
기본 논리, 매개 변수 안전 차단, 횟수 차단, 규칙 차단 을 모두 통과 합 니 다. 다음 주문 을 허용 하고 임의의 실 패 를 반환 하 며 대응 하 는 실패 원인 을 되 돌려 줍 니 다.
다 중 끼 워 넣 기 if 쓰기
우리 정상 다 층 끼 워 넣 기 if 의 쓰기

/**
 * @author saier
 * @date 2020/3/31 18:03
 */
public class Order {
    public Message interrupt1(){
        return null;
    }
    public Message interrupt2(){
        return null;
    }
    public Message interrupt3(){
        return null;
    }
    public Message interrupt4(){
        return null;
    }
    public Message interrupt5(){
        return null;
    }

    public static void main(String[] args) {
        Order order= new Order();
        if(order.interrupt1().getResult() == 1){
            if(order.interrupt2().getResult() == 1){
                if(order.interrupt3().getResult() == 1){
                    if(order.interrupt4().getResult() == 1){
                        if(order.interrupt5().getResult() == 1){
                            System.out.println("success");
                        }
                    }
                }
            }
        }

    }
}

@Data
class Message {
    private int result;
    private String msg;
}

이상 처리 논리
혹은 이상 을 이용 하여 논 리 를 한다 면 코드 는 좀 간단 할 것 이다.

/**
 * @author saier
 * @date 2020/3/31 18:03
 */
public class Order2 {
    public void interrupt1(){

    }
    public void interrupt2(){

    }
    public void interrupt3(){
        //  
        throw new RuntimeException();
    }
    public void interrupt4(){
        //  
        throw new RuntimeException();
    }
    public void interrupt5(){
        //  
        throw new RuntimeException();
    }

    public static void main(String[] args) {
        Order2 order2= new Order2();
        try{
            order2.interrupt1();
            order2.interrupt2();
            order2.interrupt3();
            order2.interrupt4();
            order2.interrupt5();
            System.out.println("success");
        }catch (RuntimeException e){
            System.out.println("fail");
        }

    }
}

처음부터 나 는 이상 을 이용 해 논 리 를 했다.그러나 후속 논리 가 갈수 록 복잡 해 지면 서 문제 가 생 길 수도 있다.예 를 들 어 이상 은 이상 정보 만 되 돌려 줄 수 있 고 더 많은 필드 정 보 를 되 돌려 줄 수 없습니다.
뒤에 도 이상 하 게 논리 적 으로 아 리 규범 에 서 는 금지 되 어 있다 는 점 을 주목 했다.
아 리 코드 규범: [강제] 이상 은 절차 통제, 조건 통제 에 사용 하지 마 세 요.설명: 이상 설계 의 취 지 는 프로그램 운행 중의 각종 의외 의 상황 을 해결 하 는 것 이 고 이상 한 처리 효율 은 조건 판단 방식 보다 훨씬 낮다.
더 중요 한 것 은 코드 의 가 독성 이 너무 떨 어 지고 수시로 한 방법의 이상 을 던 지 며 코드 자체 의 이상 도 고려 해 야 한 다 는 것 이다.
더 좋 은 방법 이 없어 서 디자인 모델 을 고려 할 수 밖 에 없다.
어떻게 고치 면 코드 의 가 독성 이 높 고 확장 성 이 좋 습 니까?
동료의 주 의 를 받 아 갑자기 디자인 모델 이 생각 났 다!
우리 가 원 하 는 목적

코드 가 이렇게 많 지 않 습 니 다 if else 내장, 가 독성 이 높 습 니 다

새로운 차단 논리 가 추가 되면 간단 하고 편리 하 며 원래 의 논리 에 영향 을 주지 않 고 확장 성 이 좋다

차단 논리 순 서 를 편리 하 게 바 꿀 수 있 고 저 결합

책임 체인 모드
이런 장면 에서 책임 체인 모델 에 매우 적합 하 다.(어떤 장면 에서 어떤 디자인 모델 을 사용 하 는 지 평소에 쌓 고 각종 디자인 모델 의 기본 적 인 사용 을 알 아야 한다)
책임 체인 은 말 그대로 관련 업무 책임 을 처리 하 는 집행 체인 이다. 집행 체인 에 여러 개의 노드 가 있 고 모든 노드 가 요구 업 무 를 처리 할 기회 (조건 일치) 가 있다. 만약 에 특정한 노드 가 처리 되면 실제 업무 수요 에 따라 다음 노드 에 계속 처리 하거나 처리 할 수 있다.
우선 필터 의 추상 클래스 를 만 듭 니 다.

public abstract class AbstractFilter {

    private AbstractFilter nextFilter;

    /**
     *          
     */
    public void setNextFilter(AbstractFilter nextFilter){
        this.nextFilter = nextFilter;
    }


    public AbstractFilter getLastFilter(){
        if(this.nextFilter != null){
            return this.nextFilter.getLastFilter();
        }else{
            return this;
        }
    }

    public void filter(FilterRequest filterRequest, Response response){
        doFilter(filterRequest,response);
        if(response.isFilterNext() && nextFilter != null){
            nextFilter.filter(filterRequest,response);
        }
    }

    /**
     *       
     */
    public abstract void doFilter(FilterRequest filterRequest, Response response);

    /**
     *          
     */
    public void exec(FilterRequest filterRequest, Response response){
    }
}

필터 구현 클래스

@Component
@Order(5)
public class CheckParamFilter1 extends AbstractFilter {
    @Override
    public void doFilter(FilterRequest filterRequest, Response response) {

    }
}

@Component
@Order(10)
public class CheckParamFilter2 extends AbstractFilter {
    @Override
    public void doFilter(FilterRequest filterRequest, Response response) {

    }
}

Order 주 해 를 사용 하여 필터 의 순 서 를 확인 하고 나중에 spring 에 주입 할 때 큰 효과 가 있 습 니 다.

//  spring       
@Autowired
List abstractFilterList;

private AbstractFilter firstFilter;

//spring       
@PostConstruct
public void initializeChainFilter(){
    //              ，  Order  ，       
    for(int i = 0;i

디자인 모델 을 사용 하 는 장점
책임 체인 모드 를 사용 하면 어떤 좋 은 점 이 있 는 지 보 세 요!

차단 논 리 를 새로 추 가 했 습 니 다. 하나의 AbstractFilter 류 만 더 실현 하면 됩 니 다

차단 순 서 를 수정 하려 면 Order 주해 의 크기 만 수정 해 야 합 니 다. 작 을 수록 우선 순위 가 높 습 니 다

코드 가 뚜렷 하고 모든 처리 논리 가 실현 류 에 가 라 앉 았 다

디자인 모드 사용 의 단점
낮은 결합, 높 은 확장 을 이 루 었 습 니 다.안 좋 은 점도 가 져 왔어요.

논리 가 더욱 복잡 하고 체인 등 데이터 구 조 를 사 용 했 기 때문에 단일 사례 의 문제 에 주의해 야 하 며 중복 사용 해 서 는 안 된다

.

종류 가 급증 하고 차단기 하나 에 한 종류

마지막 으로 매듭 지어 주세요.
어느 곳 에서 든 디자인 모델 을 사용 하기에 적합 한 것 은 아니다. 만약 에 논리 가 간단 하 다 면 디자인 모델 을 억지로 사용 하면 구조 적 으로 복잡 할 뿐 모두 가 사람들의 업무 장면 에 따라 사용 할 수 있다.

    ：     100   ，       8   ，     ？
             —Vue    
      6  @Transactional       
       ，          。
            
   ，