Skip to content

{ Tag Archives } Design Pattern

The Iterator Pattern (in ABAP)

Iterator를 사용해서 구현과는 분리하여 하나 하나 요소들을 셀 수 있다. 아래 소스를 보면 loop를 돌 때 Iterator의 메소드만 이용하고 있으며 Aggregate 클래스가 어떤 식으로 구현되어 있는가 – 배열이든, 벡터든, Internal Table이든 – 는 상관없다. 즉 나중에 Aggregate의 요소 관리 방식을 얼마든지 바꿀 수 있다는 이야기. 이를 위해 아래와 같은 것들이 필요하다. Iterator 인터페이스. Aggregate 인터페이스. [...]

Also tagged , ,

The Factory Method Pattern (in ABAP)

Factory의 요점은 다음과 같다. ‘Product를 만드는 것’과 ‘등록’의 구현은 하위 클래스에서 수행한다. (new를 사용해서) 실제의 인스턴스를 생성하는 대신에 인스턴스 생성을 위한 메소드를 호출함으로서(create_product) 구체적인 클래스명에 의한 속박에서 벗어나고 있다. Framework 쪽: ZCL_FACTORY class ZCL_FACTORY definition public abstract create public . public section. *”* public components of class ZCL_FACTORY *”* do not include other source files [...]

Also tagged , ,

The Template Method Pattern

상위 class의 templateMethod는 같은 class내에 정의된 method1 ~ method3를 이용한 알고리즘을 가지고 있다. 예를 들어 method1 ~ method3가 각각 open(), print(), close() 라면 templateMethod 내부는 다음과 같을 수 있다. (아래 display()가 templateMethod다) 실질적인 각 구현은 concrete class에서 담당하므로 파일을 열어서 쓰는 작업을 할 것인지 소켓을 열 것인지 하는 실제 처리내용은 어떤 concrete class를 쓰느냐에 달려있다. [...]

Also tagged ,

The Adapter Pattern (in ABAP)

(HFDP에서) Duck의 object가 부족해서 Turkey의 object를 이용하려고 한다… 라는 이상한 상황을 가정하고 있다. 보통 기존 모듈이 새로운 모듈을 이용하려고 하나 서로 interface가 맞지 않을때 – 구체적으로, 한 클라이언트가 다른 object의 method를 이용하고 싶지만 기존 보유한 method를 바꾸고 싶진 않다(또는 바꿀 수 없다) 할 때… 같은 있음직한 상황을 예로 든다만. 어쨌건 이 경우 Duck은 client, Turkey는 [...]

Also tagged , , ,