한 걸음 한 걸음 디자인 모델 - 대리 모델

15721 단어 디자인 모드
프 록 시 모드 는 우리 가 프로 그래 밍 에서 자주 사용 하 는 디자인 모델 로 다른 대상 에 게 프 록 시 를 제공 하여 이 대상 에 대한 접근 을 제어 하 는 것 이 목적 이다.
1. 생활 실례
매년 설 이 다가 올 때 면 표를 빼 앗 는 것 은 매우 힘 든 임무 이다.인터넷 기술 과 인터넷 티켓 팅 이 아직 특별히 성숙 하지 않 았 을 때, 모두 매표소 에서 줄 을 서서 표를 사 야 한다.많은 학교 에 다 니 는 학생 들 이 매 표 하 자마자 줄 을 서서 표를 기다 릴 시간 이 없어 대신 줄 을 서 는 황소 가 나 타 났 다. 이들 은 매번 학생 들 의 25% 를 더 받 고 대신 줄 을 서서 표를 샀 다.
우리 대리 모델 의 개념 을 다시 생각해 보면 위의 예 에서 전형 적 인 대리 모델 이 존재 한다.대리 모드 의 목적 은 다른 대상 (학생) 에 게 대리 (황소) 를 제공 하여 이 대상 (기차표) 에 대한 방문 을 통제 하 는 것 이다.
아래 에서 우 리 는 위의 이 생활 실례 를 코드 로 바 꿀 것 이다.
2. 라 이 프 인 스 턴 스 코드
  • 우선 우 리 는 기차표 류 를 구축한다. 
    • package com.wxueyuan.DesignPettern.StaticProxy;

/**
 * Author: Jesmin
 * Description:       
 *
 */
public class Ticket {
    private double price;

    public Ticket(double price) {
        this.price = price;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }

}
  • 황소 와 학생 들 이 모두 표를 사 야 하기 때문에 우 리 는 Operation 인 터 페 이 스 를 추상 화하 여 공공 방법 인 buyTicket 을 제공 하여 표를 사 는 조작
    • 을 나타 낸다.
    package com.wxueyuan.DesignPettern.StaticProxy;

/**
 * Author: Jesmin
 * Description:             ，       Operation  ，        buyTicket
 *                      
 *
 */
public interface Operation {
    void buyTicket(Ticket t);
}
  • 황소 실체 류 Scalper 구축 
    • package com.wxueyuan.DesignPettern.StaticProxy;


/**
 * Author: Jesmin
 * Description: “  ”   ，         ，       4 ，   ，    ，    ，        
 *
 */
public class Scalper implements Operation{

    private Student  realConsumer;

    public Scalper(Student s) {
        realConsumer = s;
    }

    @Override
    public void buyTicket(Ticket t) {
        // TODO Auto-generated method stub
        System.out.println("         ");
        System.out.println("      ");
        realConsumer.buyTicket(t);
        System.out.println("        ");
    }

}
  • 학생 실체 학생 설립 
    • package com.wxueyuan.DesignPettern.StaticProxy;

public class TicketConsumer implements Operation{

    @Override
    public void Student(Ticket t) {
        // TODO Auto-generated method stub
        System.out.println("       ,   "+t.getPrice());
    }

}
  • 마지막 테스트 
    • package com.wxueyuan.DesignPettern.StaticProxy;

public class Test {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        //       ticket  
        Ticket t = new Ticket(200);
        //        
        Scalper scalper = new Scalper(new Student());
        //           
        scalper.buyTicket(t);
    }
}

    집행 결 과 는 황소 가 표를 사 는 사람의 돈 을 받 고 황 소 는 밤새 줄 을 서서 표를 사 는 사람 에 게 표 한 장 을 샀 으 며, 표 값 은 200.0 황소 가 학생 들 에 게 표를 건 네 주 었 다.
    위의 코드 를 분석 해 보면 황소 실체 류 에서 구 매 자의 사례 를 얻 었 기 때문에 그 는 그의 구 매 조작 에서 구 매 자의 구 매 조작 과 추가 적 인 조작 을 수행 할 수 있다.
    다음은 대리 모델 에서 어떤 역할 이 있 는 지 분석 해 보 겠 습 니 다.
  • 추상 적 인 역할: 보통 대리 대상 과 실제 대상 이 같은 행위 에 따라 추상 화 된 인터페이스 이다. 대리 대상 과 실제 대상 이 모두 이 인 터 페 이 스 를 실현 하기 때문에 대리 대상 은 모든 실제 대상 호출 방법 에서 교체 할 수 있다.
  • 대리 역할: 대리 대상 내부 에 실제 대상 의 인용 이 포함 되 어 있 기 때문에 실제 대상 의 조작 을 수행 할 수 있다.대리 대상 은 실제 대상 작업 을 수행 할 때 다른 조작 을 추가 할 수 있 으 며 실제 대상 의 조작 을 봉인 하 는 것 과 같다.
  • 의뢰 역할: 대리 대상 이 대표 하 는 목표 대상 을 정의 했다.대리 역할 이 대표 하 는 위탁 대상 은 우리 가 최종 적 으로 인용 해 야 할 대상 이다.

    • 3. 프 록 시 모드 의 장단 점
  • 장점: 방법 소스 코드 를 수정 하지 않 은 상태 에서 방법 을 부가 적 으로 조작 할 수 있다.프 록 시 모드 를 통 해 핵심 업무 코드 와 비 핵심 업무 코드 를 결합 할 수 있 습 니 다.
  • 단점: 1. 대리 류 와 의뢰 류 가 같은 인 터 페 이 스 를 실현 하기 때문에 인터페이스 에 하나의 방법 이 추가 되면 모든 실현 류 가 이 방법 을 실현 해 야 하 는 것 을 제외 하고 모든 대리 류 도 이 방법 을 실현 하여 코드 유지 의 복잡 도 를 증가 해 야 한다.2. 대리 대상 은 한 가지 유형의 대상 에 만 서 비 스 를 제공 합 니 다. 우리 위의 황소 류 의 경우 학생 류 의 대리 (대리 류 에서 의뢰 류 의 인용 이 필요 하기 때 문) 로 만 할 수 있 습 니 다. 만약 에 우리 의 업무 상황 이 갑자기 변화 하면 선생님 류 도 황 소 를 통 해 표를 사 야 합 니 다. 그러면 우 리 는 다른 대리 류 인 TeacherScalper 를 다시 만들어 야 합 니 다.그리고 Teacher 류 의 인용 을 가지 고 선생님 이 표를 사 는 것 을 도 왔 다.따라서 대량의 실제 클래스 가 대리 되 어야 하 는 상황 에서 이런 대리 모델 은 적합 하지 않 고 대량의 불필요 한 코드 가 있 을 수 있다.
  • 선생님 황소 대리 
    • package com.wxueyuan.DesignPettern.StaticProxy;


/**
 * Author: Jesmin
 * Description:        ，         ，       4 ，   ，    ，    ，        
 *
 */
public class TeacherScalper implements Operation{

    private Teacher realConsumer ;

    public TeacherScalper(Teacher t) {
        realConsumer = t;
    }

    @Override
    public void buyTicket(Ticket t) {
        // TODO Auto-generated method stub
        System.out.println("         ");
        System.out.println("      ");
        realConsumer.buyTicket(t);
        System.out.println("         ");
    }

}
  • 선생님 실체 류 
    • package com.wxueyuan.DesignPettern.StaticProxy;

public class Teacher implements Operation{
    @Override
    public void buyTicket(Ticket t) {
        // TODO Auto-generated method stub
        System.out.println("       ,   "+t.getPrice());
    }
}
  • 테스트 클래스 
    • package com.wxueyuan.DesignPettern.StaticProxy;

public class Test {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        //       ticket  
        Ticket t = new Ticket(200);
        //        
        Scalper scalper = new Scalper(new Student());
        //           
        scalper.buyTicket(t);

        //       ticket  
        Ticket adultTicket = new Ticket(300);
        //        
        TeacherScalper ts = new TeacherScalper(new Teacher());
        //           
        ts.buyTicket(adultTicket);
    }

}

    이러한 대리 모델 로 인해 대리 역할 과 위탁 역할 의 공 통 된 행위 인 터 페 이 스 를 미리 추상 화 했 고 대리 역할 은 컴 파일 할 때 위탁 류 와 의 위탁 관 계 를 확 정 했 기 때문에 이런 대리 모델 도 정태 대리 라 고 불 린 다.
    여러 개의 위탁 유형 이 있 을 때 여러 개의 대리 류 가 필요 한 상황 을 고려 하면 우 리 는 당연히 더 좋 은 방법 이 있 는 지, 하나의 대리 류 를 통 해 모든 대리 기능 을 완성 할 수 있 는 지 생각 할 것 이다.답 은 있 습 니 다. 그것 이 바로 동적 대리 입 니 다.
    4. 동적 에이전트
    정적 에이전트 에서 하나의 대 리 는 하나의 유형 만 대리 할 수 있 고 컴 파일 기간 에 대리 대상 이 확정 되 었 습 니 다.한편, 동적 대 리 는 실 행 될 때 반사 체 제 를 통 해 동적 대 리 를 실현 하고 각종 유형의 대상 을 대리 할 수 있다.
    다음 에 우 리 는 위의 선생님, 학생 들 이 기차 표를 사 는 것 을 예 로 들 어 동태 대 리 를 이용 하여 이 예 를 완성 한다. 다음 예 에서 사용 한 Ticket 실체 류, Teacher 실체 류, Student 실체 류 와 Operation 추상 인 터 페 이 스 는 모두 정태 대리 중의 것 과 같 기 때문에 더 이상 언급 하지 않 는 다.
  • 우선 Invocation Handler 인 터 페 이 스 를 실현 해 야 합 니 다. 
    • package com.wxueyuan.DesignPettern.DynamicProxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class TicketOperationInvocationHandler implements InvocationHandler {

    //            Handler 
    private Object target; 

    public TicketOperationInvocationHandler(Object target) {
        this.target = target;
    }

    //            
    public Object getProxy() {
        return Proxy.newProxyInstance(Thread.currentThread()  
                .getContextClassLoader(), target.getClass().getInterfaces(),  
                this);  
    }

    //            
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // TODO Auto-generated method stub
        System.out.println("         ");
        System.out.println("      ");
        Object ret = method.invoke(target, args);
        System.out.println("         ");
        return ret;
    }

}
  • 다음은 우리 의 대 리 를 테스트 해 보 겠 습 니 다. 
    • package com.wxueyuan.DesignPettern.DynamicProxy;

import com.wxueyuan.DesignPettern.StaticProxy.Operation;
import com.wxueyuan.DesignPettern.StaticProxy.Student;
import com.wxueyuan.DesignPettern.StaticProxy.Teacher;
import com.wxueyuan.DesignPettern.StaticProxy.Ticket;

public class Test {

    public static void main(String[] args) {
        // TODO Auto-generated method stub

        //       ticket  
        Ticket studentTicket = new Ticket(200);
        //       ticket  
        Ticket adultTicket = new Ticket(300);

        //            
        Operation studentProxy = (Operation) new TicketOperationInvocationHandler(new Student()).getProxy();
        studentProxy.buyTicket(studentTicket);

        System.out.println("---------------------------");

        //            
        Operation teacherProxy = (Operation) new TicketOperationInvocationHandler(new Teacher()).getProxy();
        teacherProxy.buyTicket(adultTicket);
    }

}

    실행 결 과 는:
    황 소 는 표를 사 는 사람의 돈 을 받 고 황 소 는 밤새 줄 을 서서 학생 들 에 게 표를 한 장 샀 으 며, 표 값 은 200.0 황소 로 표를 사 는 사람 에 게 건 네 주 었 다.
    황 소 는 표를 사 는 사람의 돈 을 받 고 황 소 는 밤새 줄 을 서서 선생님 에 게 표를 한 장 샀 는데, 표 값 은 300.0 황소 가 표를 사 는 사람 에 게 건 네 주 었 다.
    이제 동적 에이전트 의 장점 을 분석 해 보 자. 1. 정적 에이전트 에 비해 우 리 는 대리 가 필요 한 모든 의뢰 류 에 대응 하 는 대리 류 (상례 의 TeacherScalper 와 Scalper) 를 만 들 필요 가 없다. 우 리 는 추상 적 인 인터페이스 로 대리 인 스 턴 스 를 생 성하 여 서로 다른 의뢰 류 를 대체 하여 임 무 를 완성 할 수 있다.2. 동적 에이전트 의 또 다른 장점 은 공공 인터페이스 에서 설명 한 모든 방법 을 하나의 집중 적 인 방법 으로 옮 겨 처리 하 는 것 이다 (invocke () 방법). 즉, 우 리 는 invoke 방법 에서 모든 인터페이스 에서 의 방법 에 똑 같은 추가 작업 을 추가 할 수 있다. 예 를 들 어 방법 이 실행 되 기 전에 현재 시간 을 기록 하고 방법 이 실 행 된 후에 현재 시간 을 기록 하 는 것 과 같다.차이 로 모든 방법의 실제 실행 시간 을 얻 는 등 이것 이 바로 AOP (절단면 프로 그래 밍) 의 기본 원리 이다.
    여기 서 블 로 거들 은 여러분 에 게 대리 디자인 모델 과 정태 대리 와 동태 대리 간 의 장단 점 을 소개 합 니 다. 어떤 학생 들 은 동태 대리 의 사용 과 원리 에 대해 곤 혹 스 러 울 수 있 습 니 다. 블 로 거들 의 또 다른 글 인 에 관심 을 가 져 주 십시오.
    이 절 블 로그 의 원본 코드 는 모두 여기에 놓 여 있 습 니 다. 다운로드 해 주시 기 바 랍 니 다.
    자바 디자인 모델 - 디자인 모델 의 6 대 원칙
    두 갈래 나무 - 체인 테이블 구조

    좋은 웹페이지 즐겨찾기

    개발자 우수 사이트 수집

    개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
    best100-homepage