Docstoc

07

Document Sample
07 Powered By Docstoc
					제 7장 설계패턴


 7.1   소개
 7.2   설계패턴의 유형
 7.3   생성패턴
 7.4   구조패턴
 7.5   행위패턴


                  1
7.1 소개

  전문가의 노하우를 모아놓은 것
     전문가의 경험이므로 적용하여 좋은 설계가 되도록 도와 줌
          코드를 더 견고하게 함
          재사용을 용이하게 함
  공통의 설계 목표를 만족시키는 클래스의 조합과 협력
   알고리즘
     여러 번의 시행착오를 거치면서 비슷한 역할의 클래스를 자주
     쓰게 됨
     이를 잘 모아 목록화 한 것




                          2
설계 목표

  재사용성, 융통성, 유지보수성
    융통성 있는 설계의 재사용
    코드를 일반화
    다른 클래스에 의존하는 것을 최소화
  강인성
    신뢰성 있는 설계의 재사용
    강인한 부품을 재사용
  충분함, 정확성
    모듈화 된 설계
    신뢰성 있는 부품을 재사용




                      3
반복되는 설계

                 KitchenViewer Interface

                        menu
   Wall
  cabinet        menu




  Counter
                                            display area
                                           display area

                                                           styles
                                                               styles

   Floor
  cabinet


            Modern             Classic 4     Antique             Arts & Crafts
사용 사례: 레이아웃 설계

 사용사례 : 레이아웃 설계
 액터 : 사용자
 이벤트 :
 1.   사용자가 ‘wall cabinet' 아이콘을 클릭
 2.   응용 프로그램이 워크 영역에 붙박이장을 보여줌
 3.   사용자가 붙박이장의 크기를 조정
 4.   붙박이장을 끌어 상단에 위치시키고 마우스를 릴리스
 5.   계속 붙박이장을 만들어 크기 조절하고 원하는 곳에 이동
 6.   ‘floor cabinet(바닥장)’을 선택하여 바닥장을 만들고 원하는 위치에 이동
 7.   ...




                             5
Antique Style의 선택




  Modern        Classic       Antique   Arts & Crafts
                          6
피해야 할 코딩 스타일

  렌더링
   Counter counter = new Counter();
   draw (counter);


  상판(Counter)의 타입이 런타임에도 바뀔 수 있음

  따라서 다음과 같은 스타일로 바꾸어야 함
   renderKitchen(myStyle);


  어플리케이션이 런타임에 객체의 패밀리로 구성될 때 여러 가지
  주어진 스타일에서 선택할 수 있도록 하여야 함


                                      7
설계 패턴을 적용하지 않은 코딩

 // Create the antique wall cabinets
 AntiqueWallCabinet antiqueWallCabinet1 = new AntiqueWallCabinet();
 AntiqueWallCabinet antiqueWallCabinet2 = new AntiqueWallCabinet();

 // Create the antique floor cabinets
 AntiqueFloorCabinet antiqueFloorCabinet1 = new AntiqueFloorCabinet();
 AntiqueFloorCabinet antiqueFloorCabinet2 = new AntiqueFloorCabinet();

 // Create the kitchen object, assuming the existence of add() methods
 Kitchen antiqueKitchen = new Kitchen();
 antiqueKitchen.add(antiqueWallCabinet1, ... );
 antiqueKitchen.add(antiqueWallCabinet2, ... );
 ...
 antiqueKitchen.add(antiqueFloorCabinet1, ... );
 antiqueKitchen.add(antiqueFloorCabinet2, ... );
 ...
 // Render antiqueKitchen
 ...


                                                  8
설계 패턴을 적용한 사례

  디자인 목표
    여러 가지 키친 스타일을 런타임에 생성할 수 있도록 융통성 있는
     설계가 되어야 함


  키친 스타일을 직접 생성하는 방법
    new AntiqueWallcabinet(); // 앤틱에만 적용


  스타일 파라미터로 위임하는 코드
    myStyle.getWallCabinet(); // 런타임에 스타일이 선택




                                9
7.2 디자인 패턴의 유형

  Gamma, et al.
  생성 패턴
     유연한 방법으로 객체의 집합을 생성하는 패턴
     객체를 생성하고 참조하는 과정을 추상화하여 시스템이 객체의 생성
      과 조합 등에 구애받지 않고 개발될 수 있도록 도와주는 패턴. 특정
      객체가 생성되고 변경되어도 전체 시스템의 변화는 최소화되도록
      만들어 주어 시스템의 확장이나 유지보수 시 최소비용이 들게 함.
  구조 패턴
     uniform interface를 위하여 관계 있는 객체의 모임을 표현하는 패턴
     복잡한 구조를 이루는 클래스들을 어떻게 하면 개발하기도 쉽고 보기
      에도 좋은 형태로 만들어 줄 것인가에 대한 답을 제시해 주는 패턴
     구조패턴을 이용해서 시스템을 구축하면 새로운 기능을 가진 복합
      개체를 효과적으로 작성 가능

                           10
디자인 패턴의 유형

  행위 패턴
      객체들 간의 행위나 알고리즘 등과 관련된 패턴
      응용분야에 따라 행위가 다른 객체로 옮겨가거나 알고리즘이 대체
       되는 경우가 존재하는데 이때 많은 도움을 받을 수 있는 패턴




                       11
행위 패턴의 예




      obstacles



                               to drydock 



        berth          berth
                  12
디자인 목표

 배가 항구에 들어오고 나가는 데 필요한 시간과 유지보수를 위해
  항구를 비워 놓아야 하는 기간 추정 문제




                          
                    Harbor application
 Ship과 Tugboat의 의존성을 피하도록
   두 클래스를 같이 1
              사용하는 어플리케이션이 많을 것임
         Ship                                 Tugboat


           Customs application: reuse Ship alone

                 Ship           Longshoreman

                               13
중재자 패턴의 도입

 연관된 행위와 객체 자체를 분리하기 위하여
   중간에 중재하는 클래스(mediator)를 도입



                                       Ship
      LeavingPort
     estimateTime()

                                        Tugboat


                 항구문제에 적용된 중재자 패턴 개념


                             14
7.3 생성패턴 : 팩토리 패턴

  목적
    객체생성을 위한 인터페이스를 정의하는데 있다.
    어떤 클래스의 인스턴스를 생성할지에 대한 결정이 서브클래스에서
     이루어지도록 인스턴스 생성의 책임을 미룸
  생성자만으로는 개별 객체 생성이 적합하지 않은 경우에 사용
  결과
    다양한 형태의 객체를 반환하는 융통성을 갖게 됨
    특정 객체를 사용하는 일반 객체들이 객체의 변화에 독립적으로 행동
     할 수 있도록 만들어 줌. 팩토리 객체가 상황에 맞게 동적으로 적합한
     객체를 반환(형변환, 다형성 활용)
    시스템 유지보수 시 일반 객체들의 변경 최소화




                       15
팩토리 패턴의 개념(정적 모형)


   Client                                 RequiredClass

                             «create object»


                     MyClass
    createObjectOfRequiredClass(): RequiredClass

 Factory design pattern


                             16
팩토리 패턴의 개념(동적 모형)


:Client                                   :MyClass               :RequiredClass


          createObjectOfRequiredClass()
                                                     RequiredClass()




                                             17
팩토리 패턴의 간단한 예제


Client
                        Automobile                        Application
               createAutomobile(): Automobile              of Factory
                                                               design
                                                              pattern

              Hyundai                       Kia
         createAutomobile()          createAutomobile()
                   class Hyundai extends Automobile
 «create object»   {
                      . . .
                                                      «create object»
                      Automobile createAutomobile()
                      {
                          return new Hyundai();
                      }              18
                      ...
                   }
싱글톤 패턴

 목적
   어떤 클래스 S의 인스턴스를 하나만 만들고 싶을 때(어플리케이션
    전체에 하나만 필요한 경우) 사용


 패턴의 핵심
   S의 생성자를 private으로 만들고, S안에 private 정적 속성을 정의한다.
    이를 접근하는 public 정적 메소드를 제공한다.
   싱글톤 클래스를 이용해서 객체를 생성하는 것이 아니라 싱글톤 클래스
    가 가진 메소드를 이용해 객체를 얻음
   싱글톤은 오직 한 개의 객체만 존재하게 하려는 목적이 있어, 더 이상
    만들려고 하는 생성자의 호출을 안전하게 막아야 한다.




                          19
싱글톤 패턴

 클래스 다이어그램
 Client


                                Singleton Design Pattern

              MyClass                singletonOfMyClass
  getSingletonOfMyClass(): MyClass
                                          «static»
               1


                           20
싱글톤 만들기

 1.   MyClass 클래스 안에 MyClass 타입의 private 정적 변수를 선언한다.
      private static MyClass singletonOfMyClass = new MyClass();

 2.   MyClass의 생성자를 private으로 만든다.
      private MyClass() { /* …. constructor code …. */ };

 3.    멤버를 접근하는 정적 public 메소드를 정의한다.
      public static MyClass getSingletonOfMyClass()
      {
         return singletonOfMyClass;
      }




                                       21
예제 7.1: 실험 결과

  연구실의 실험 결과 평가 어플리케이션
     정확히 하나의 Experiment 객체만이 실시간에 존재함을 보장하여야 함
     어플리케이션에서 Experiment를 접근할 때 다음과 같이 표시




                       Experiment
                theExperiment: Experiment
                                               theExperiment
 Client                  analyze()                «static»
              getTheExperiment(): Experiment
                     reportResults()

                         1

                                22
구현된 코드

 클라이언트 코드                                     class Experiment
                                               {
class Client                                      private static final Experiment theExperiment = new
                                                   Experiment();
{                                                 String result = "Experiment result not yet
  public Client() {                                assigned"; // result of the experiment
    super();
  }                                              private static int numTimesReferenced = 0;
  public static void main( String[] args ) {     private Experiment() {
                Experiment experiment =             super();
    Experiment.getTheExperiment();               }
    experiment.analyze();
    experiment.reportResults();                  public synchronized void analyze() {
                                                 theExperiment.result =
  }
                                                      "... The analysis shows that the experiment
}                                                  was a resounding success. ....";
                                                 }




                                                   23
구현된 코드

 public static Experiment getTheExperiment() {
       ++numTimesReferenced;
       System.out.println
         ("Noting that the Experiment singleton referenced " +
          numTimesReferenced + " times so far");

         return theExperiment;
     }

     public void reportResults() {
       System.out.println(result);
     }
 }




                                                  24
프로토타입 패턴

 목적
   런타임에 그 타입이 결정되는 거의 동일한 객체의 집합을 만들려고 할 때
    적용
   생성하고자 하는 객체의 프로토타입 객체를 제공한 뒤 프로토타입 객체의
    복사본을 만들어 활용(인스턴스로부터 새로운 인스턴스 생성)


 가정
   프로토타입이 될 인스턴스를 이미 알고 있어야 함
   새로운 인스턴스가 필요할 때 언제든지 이를 클론화


 인스턴스를 만드는 방법
   new Something()
   MyPart anotherMyPart = MyPartPrototype.clone();

                                   25
프로토타입 아이디어

      Client

    Ensemble            myPartPrototype          1
                                                         MyPart
 createEnsemble()                                     clone(): MyPart



   // To create a MyPart instance:
   MyPart p = myPartPrototype.clone();



                                         MyPartStyleA             MyPartStyleB
                                            clone()                     clone()
Prototype Design Pattern                    26
    Client
프로토타입 클래스 모델                                      .....
                                                  // To create a Part1 object:
                                                  Part1 p1 = part1Prototype.clone();
  Ensemble                                        ….
createEnsemble()
                        part1Prototype                               part2Prototype
                       1                                             1
                   Part1                                         Part2
                   clone()                                       clone()




Part1StyleA Part1StyleB Part1StyleC                Part2StyleA Part2StyleB
   clone()         clone()            clone()          clone()             clone()


                             Part1StyleB returnObject = new Part1StyleB();
                                             27
                             ….
추상 팩토리 패턴

  객체의 그룹을 생성하거나 의존적인 관계를 가지고 있는 객체들을 생성할
   때 객체들의 생성을 추상화 해주는 패턴

  목적
    객체생성을 추상화 하여 이를 사용하는 모듈과 독립적으로 인터페이
     스를 정의하는 데 있다.
    인스턴스를 생성하기 위한 프레임워크와 실제로 인스턴스를 생성하는
     클래스를 분리하여 생각
    객체의 그룹을 추상화
  결과
    팩토리 메소드를 가진 클래스에서 객체 패밀리를 생성
    사용될 객체의 그룹이 동적으로 달라질 때 효과적


   구체적인 클래스를 명시하지 않고 연관되는 객체 패밀리를
   생성하는 인터페이스를 제공

                      28
*                            abstractFactory                1   AbstractFactory
        Ensemble                                                getAPart1Object()
    setAbstractFactory()                                        getAPart2Object()
       doAFunction()
                              Part1                 Part2


                           Part1StyleA         Part2StyleA


      Part1 getAPart1Object()                                   StyleAFactory
                                         «create»               getAPart1Object()
      { return new Part1StyleA();
      }                                                         getAPart2Object()



                                               29                    Client
7.4 구조 패턴

  더 큰 구조를 형성하기 위하여 클래스와 객체를 어떻게 합성하는가?
  상속 기법 이용
    인터페이스, 구현을 합성
  독립적으로 개발될 클래스 라이브러리의 합성
  구조 패턴
    새로운 기능을 구현하기 위하여 객체를 구성하는 방식
    런타임에 객체 구조를 변경
    유연성, 확장성




                     30
컴포지트 패턴

  목적
    객체의 트리를 나타내는데 사용
  패턴 요약
    기본 클래스와 이를 포함하는 컨테이너 클래스를 재귀적인 형태로
     표현
    객체들의 집합을 다룰 때 유용
    e.g. 폴더 안의 파일




                        31
컴포지트 패턴의 개념

객체
      non-leaf node


                                                     leaf node



                                           1..n
클래스                       Component
                                         “non-leaf 노드는 하나
         “모든 객체는                          이상의 components”
         component 객체”



                         NonLeafNode32
사례: 그래픽 도구




                                  Group에 개체 추가
                                    및 삭제 연산




    leaf or terminal nodes


                             33
컴포지트 패턴의 구현
                                                                             가지고 있는 모든
                                                                              Figure 객체에
 class Figure {                                                              draw 함수 호출
                                       class Group : public Figure {
 public:
                                       public:
    virtual void draw() =0;
                                          virtual void draw() {
    virtual void move() =0;
                                            Figure *f;
    virtual void add(Figure *) {}
                                            for( int i=0; (f=getChild(i)) !=NULL ; ++i )
    virtual void remove(Figure *) {}
                                                f->draw();
    Figure *getChild(int) {}
                                          }
 };
                                          virtual void move() {
                                             …
 class Rectangle : public Figure {
                                          }
 public:
    virtual void draw() { … }
                                            // Children Handling Routine
    virtual void move() { … }
                                            virtual void add(Figure *) { … }
 };
                                            virtual void remove(Figure *) { … }
 class Line : public Figure {
                                            Figure *getChild(int) { … }
 public:
                                            …
    virtual void draw() { … }
                                       };
    virtual void move() { … }
 };                                                   내부 Figure 객체 관리(추가,
 class Circle : public Figure {
                                                      삭제, 검색)는 이를 위한
 public:
    virtual void draw() { … }                         자료구조가 필요
    virtual void move() { … }                 34
 };
데코레이터 패턴

  목적
    런 타임에 객체의 기능을 추가하기 위하여 사용
  패턴 요약
    패키지의 기능을 제공할 수 있는 유일 수단인 인터페이스를 정의
  주의
    클래스들을 패키지로 구성할 필요는 없음. 하나 이상의 클래스들이
     퍼사드(façade)를 위하여 사용될 수도 있음




                      35
사례: GUI 설계

                                                                   Some applications would
   aBorderDecorator                                                benefit from using objects to
                                                                   model evey aspect of their
                                                                   functionality,
                                                                   …
   aScrollDecorator                                                …
                                Some applications would ben
                               efit from using objects to
                             model evey aspect of their

      aTextView       …
                          …
                           functionality,




   상속을 이용하면 융통성이 없어짐
   해결책
      화면 구성 클래스와 추가기능(decorator)들을 분리하고, 하나의
       화면 구성 클래스에 여러 개의 기능들을 연결되도록 구성




                                                              36
데코레이터 패턴의 구조



기본 화면구성
  클래스




                           앞에 연결되어있는
                         객체의 Draw() 호출 후에
                          자신의 추가기능 수행




    추가기능
  클래스들(decorator)

                    37
어댑터 패턴

  기존에 존재하는 클래스를 직접 변경하지 않고도 원하는 형태의 인터페이
   스를 가지게 만드는데 효과적으로 사용할 수 있는 패턴
  목적
    어플리케이션의 기능을 외부에서 필요한 형태로 수정하여 사용하기
     위함
  패턴 요약
    원하는 인터페이스를 추상 클래스로 정의
    이를 상속하는 어댑터 클래스를 만들고 이를 요구하는 기능을 가진
     클래스(adaptee)와 메시지를 교환하게 함
  적용 분야
    기존에 존재하는 클래스를 재사용하고 싶지만, 원하는 인터페이스와
     맞지 않을 때
    미리 정해져 있지 않은 클래스들과 상호작용할 수 있는 재사용 가능 클
     래스를 만들려는 경우


                      38
어댑터 패턴

    구조
        Class adapter: 상속을 이용




        Object adapter: 위임을 이용




                                  39
퍼싸드 패턴

  대표 인터페이스를 이용하여 다른 여러 객체를 사용할 수 있도록 만드는
   패턴
  목적
    클래스 패키지에 인터페이스를 제공하기 위하여 사용


  패턴 요약
    패키지의 기능을 제공할 수 있는 유일 수단인 인터페이스를 정의


  주의
    클래스들을 패키지로 구성할 필요는 없음. 하나 이상의 클래스들이
     퍼싸드를 위하여 사용될 수도 있음



                      40
퍼싸드 패턴의 구조



          1       Façade               A
                                  «not exposed»
                  «exposed»
 Client                           myAMethod()
              cMethodOfFacade()
                                       B
                                  «not exposed»
                       2
                                  myAMethod()
                   C
              «not exposed»            D
              myCMethod()         «not exposed»
                                  myAMethod()
                       E
                 «not exposed»
                 myAMethod()
                         41
                사례: 은행 시스템
                            Customer                       Account
  AccountException
                       getCustomerName()                getAccountNum()
                        getNumAccounts()                  deposit( int )
  CustomerException     getPersonalNote()                 getBalance()
                         getAccount( int )

framework
                                                 1..n
                      BankCustomer                        BankAccount
                                                          IntroMessage
                                                                 «facade»
                                    BankCustomers
 Client               doDeposit( int amt, Customer cust, Account acc )
  main()               getBankAccount( Customer cust, int accNum )
                           getBankCustomer( String custName )
bankCustomers                      introduceApplication()
                                      42
프록시 패턴

  원하는 작업을 대신해서 처리하도록 만드는 패턴
  목적
    시간이 많이 소요되는 불필요한 복잡한 객체를 생성하는 시간을 간단
     한 객체로 줄임
    시스템의 처리과정을 효율적으로 만들기 위해 처리를 분산(A작업이 시
     간이나 자원 많이 소요, 별로 중요하지 않은 작업이면 A작업을 별도의
     처리 모듈이 작업하도록 만들고 B작업 처리)
  패턴 요약
    특정 객체에 대한 접근을 조절하기 위하여 대리자(프록시)를 세움
    필요할 때만 비싼 대가의 기능을 접근하도록 프록시를 사이에 둠
  사용 사례
    로딩하는데 시간이 많이 소모되는 큰 그림과 같은 객체를 사용하고자
     할때
    네트워크 작업에서 네트워크 사용이 증가해 로딩이 느린 객체
    사용자에게 권한이 제한된 객체의 접근을 허용하게 할 때
                      43
프록시 패턴

 구조




  객체 다이어그램

         aClient
         subject   aProxy
                   subject    aRealSubject


                         44
프록시 패턴 사례

  이미지 대신 심볼을 간단히 디스플레이




                   45
7.5 행위 패턴

  행위 패턴
    반복적으로 일어나는 객체들의 상호작용을 패턴화 해 놓은 것
    객체들 간의 알고리즘이나 역할 분담에 관련된 것


  패턴
      옵서버 패턴
      중재자 패턴
      책임 체인 패턴
      커맨드 패턴
      비지터 패턴




                      46
옵서버 패턴

 목적
   한 객체에 의하여 영향 받는 객체들을 정리하는 데 사용


 옵서버(observer)
   특정 데이터나 객체를 감시하고 있다가, 변화가 발생(상태 변화나 메소
    드 실행 시)했을 때 시스템에 이를 알리고 연관된 객체들이 적절한 작업
    을 동일한 인터페이스를 이용하여 실행하도록 만들어 줌


 패턴 요약
   단일 객체가 영향 받는 객체 집합에 대하여 같은 이름의 메소드를 호출
    하여 구현
   관찰 대상 객체가 관찰하는 객체가 몇 개인지 어떤 클래스인지 모름



                      47
옵서버 패턴


     클래스 다이어그램




                  48
옵서버 패턴

 1. 클라이언트가 Observer들에게 상태 변화의 통지를 요청
    Client 객체가 Source 객체의 notify() 메소드를 호출
 2. notify() 메소드는 집합 관계에 있는 각각의 Observer 객체 안의
    update() 메소드를 호출
 3. update() 메소드는 Source의 옵서버로 연결된
    ConcreteObserver들마다 호출
    update() 메소드 안에서는 Source 객체 상태를 받아서 그래프를
     그린다든지 또는 변경된 상태를 이용하여 다른 작업을 함




                           49
중재자 패턴


  시스템을 이루고 있는 객체들 사이의 밀접한 연관관계를 효율적
   으로 처리해 주는 패턴

  객체 내부의 변화나 특정 작업의 실행이 다른 객체들에 영향을
   미치게 될 때, 중재자 객체가 이들 객체의 중간에서 서로 간의
   변화나 메시지를 중개(또는 조정)해 주어 시스템이 원활하게 작동
   하도록 만들어 주는 패턴




                    50
중재자 패턴

  목적
    관련되는 객체 사이의 레퍼런스를 피하는 데 사용
  패턴 요약
    중간 행위를 찾아 별도의 클래스에 두게 함
    다른 객체의 존재를 모르는 상태에서도 메시지를 주고 받을 수 있음




                       Lamp               CoinBox
  Lamp      CoinBox

                               Mediator

  Mixer      BillBox
                       Mixer               BillBox
                        51
중재자 패턴 사례

  GUI 다이얼로그 박스 구현




                     52
중재자 패턴

    일반적인 중재자 패턴의 구조




      Mediator
         Colleague 객체들과 의사소통에 필요한 인터페이스를 정의
      ConcreteMediator
         Colleague 객체들을 조정하여 협동작업을 구현
      Colleague classes
         각 Colleague 객체들은 Mediator 객체를 알고 있고
           Mediator 객체를 통해서만 상호작용을 수행
                        53
중재자 패턴

 순차 다이어그램




             54
책임 체인 패턴

  목적
    사용자가 원하는 작업을 어떤 객체에게 시킬지 모를 때
    그 작업을 다룰만한 객체들의 집합에 던져버림


  구현
    작업을 수행하는 객체를 체인처럼 엮어 놓았다가 외부의 요청이 있으
     면 차례로 넘김




                      55
책임 체인 패턴

  클래스 다이어그램




               56
고객 정보 입력




           57
책임 체인 패턴 사례

   책임 체인
                      container
: CompanyName

                                        container
                       :Company
      handleClick()

                                                                      container
                                        :CustomerProfessional
                        handleClick()

                                                                    :CustomerInfo
                                                    handleClick()


                                           58
커맨드 패턴

 목적
   객체 그룹에서 처리를 담당할 객체를 직접 지정한 후 그 객체를 처리
    박스에 요청하여 처리
   서비스를 처리할 때 융통성을 높이려고 사용(undo)


 구현
   커맨드 클래스 안에 명령을 캡슐화 하여 넣음
   간접적인 호출을 이용하여
      유연성을 높임
      명령을 취소할 때 커맨드 히스토리 작성




                      59
커맨드 패턴

  구조




         60
GUI 프로그램의 사례

 클래스 모형




               61
GUI 프로그램의 사례

  순차 다이어그램




               62
비지터 패턴

  클래스에 속한 모든 객체들에 수행되는 오퍼레이션을 표현할 때
   사용
  여러 종류의 노드 클래스 사이에 오퍼레이션이 분산되어 복잡한
   시스템을 구성
  새로운 오퍼레이션을 추가하려면 모든 클래스에 코드를 추가하고
   컴파일을 다시 하여야 함
  해결책
    각 클래스로부터 관련된 오퍼레이션을 Visitor라고 불리는 분리된 객체
     로 떼어내어 패키지화 하면 효율적




                        63
비지터 패턴

    컴파일러가 사용하는 AST의 각 노드 구성




    각 노드에 오퍼레이션이 분산됨
       새로운 오퍼레이션을 추가할 때 문제가 됨


                       64
비지터 패턴




         65

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:7
posted:5/5/2011
language:Korean
pages:65