[GoF 디자인 패턴] 템플릿 메소드(Template method) 패턴, 방문자 (Visitor) 패턴

JMM·2025년 1월 15일

GoF 디자인 패턴 방문자 패턴 템플릿 메소드 패턴

GoF 디자인 패턴

목록 보기

11/11

1.1 템플릿 메소드 패턴 : 알고리듬 구조를 서브 클래스가 확장할 수 있도록 템플릿으로 제공하는 방법.

추상 클래스는 템플릿을 제공하고 하위 클래스는 구체적인 알고리듬을 제공한다.

Before

1. Client.java

public class Client {

    public static void main(String[] args) {
        FileProcessor fileProcessor = new FileProcessor("number.txt");
        int result = fileProcessor.process();
        System.out.println(result);
    }
}

2. FileProcessor.java

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class FileProcessor {

    private String path;

    public FileProcessor(String path) {
        this.path = path;
    }

    public int process() {
        try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
            int result = 0;
            String line;
            while ((line = reader.readLine()) != null) {
                result += Integer.parseInt(line); // 특정 연산
            }
            return result;
        } catch (IOException e) {
            throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
        }
    }
}

3. MultuplyFileProcessor.java

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class MultuplyFileProcessor {

    private String path;

    public MultuplyFileProcessor(String path) {
        this.path = path;
    }

    public int process() {
        try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
            int result = 1;
            String line;
            while ((line = reader.readLine()) != null) {
                result *= Integer.parseInt(line); // 특정 연산
            }
            return result;
        } catch (IOException e) {
            throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
        }
    }
}

Before 문제점

기본적으로 특정 연산 부분을 바꾸기 위해 새로운 FileProcessor를 생성해야 하는 번거로움과, 코드 중복 문제, 유지 보수가 어렵다!

1. 중복된 코드

파일 읽기, 버퍼 처리, 예외 처리 등은 동일한 코드가 반복된다.
단지 연산 부분만 다르므로, 코드 중복이 심각하다.

2. 유지보수 어려움

새로운 연산을 추가할 때마다 클래스를 새로 작성해야 하므로, 코드 관리가 어렵다.

After

1. Client.java

public class Client {

    public static void main(String[] args) {
        FileProcessor fileProcessor = new MultiplyFileProcessor("number.txt");
        int result = fileProcessor.process();
        System.out.println(result);

        fileProcessor = new PlusFileProcessor("number.txt");
        int sumResult = fileProcessor.process();
        System.out.println(sumResult);
    }
}

2. FileProcessor.java

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public abstract class FileProcessor {

    private String path;

    public FileProcessor(String path) {
        this.path = path;
    }

    public final int process() {
        try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
            int result = getInitialResult();
            String line;
            while ((line = reader.readLine()) != null) {
                result = calculate(result, Integer.parseInt(line));
            }
            return result;
        } catch (IOException e) {
            throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
        }
    }

    protected abstract int getInitialResult();

    protected abstract int calculate(int result, int number);
}

앞서 말했듯이 추상 클래스가 템플릿을 제공하고, 하위 클래스에서 구체적인 작업을 하면된다!

3. MultiplyFileProcessor.java

public class MultiplyFileProcessor extends FileProcessor {

    public MultiplyFileProcessor(String path) {
        super(path);
    }

    @Override
    protected int getInitialResult() {
        return 1;
    }

    @Override
    protected int calculate(int result, int number) {
        return result * number;
    }
}

4. PlusFileProcessor.java

public class PlusFileProcessor extends FileProcessor {

    public PlusFileProcessor(String path) {
        super(path);
    }

    @Override
    protected int getInitialResult() {
        return 0;
    }

    @Override
    protected int calculate(int result, int number) {
        return result + number;
    }
}

다이어그램

템플릿 메소드 패턴의 장점과 단점

장점

코드 재사용성
- 템플릿 코드를 재사용하고 중복 코드를 줄일 수 있다.
유연성
- 템플릿 코드를 변경하지 않고 상속을 받아서 구체적인 알고리듬만 변경할 수 있다.

단점

리스코프 치환 원칙 위반 가능성
- 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체할 수 없을 가능성도 존재한다.
- ex) (부모 - calculate, 자식 갑자기 -1 반환) <- 부모 클래스를 final로 막으면 된다!
복잡성 증가
- 알고리듬 구조가 복잡할 수록 템플릿을 유지하기 어려워진다.

1.2 템플릿 콜백 패턴: 콜백으로 상속 대신 위임을 사용하는 템플릿 패턴.

상속 대신 익명 내부 클래스 또는 람다 표현식을 활용할 수 있다.

템플릿 콜백 패턴 적용 코드

1. Operator.java

public interface Operator {

    abstract int getResult(int result, int number);
}

2. FileProcessor

public class FileProcessor {

    private String path;
    public FileProcessor(String path) {
        this.path = path;
    }

    public final int process(Operator operator) {
        try(BufferedReader reader = new BufferedReader(new FileReader(path))) {
            int result = 0;
            String line = null;
            while((line = reader.readLine()) != null) {
                result = operator.getResult(result, Integer.parseInt(line));
            }
            return result;
        } catch (IOException e) {
            throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
        }
    }


}

3. Client.java

public class Client {

    public static void main(String[] args) {
        FileProcessor fileProcessor = new FileProcessor("number.txt");
        int result = fileProcessor.process((sum, number) -> sum += number);
        System.out.println(result);
    }
}

콜백 패턴 동작 방식:

공통 로직 제공 (템플릿):
- FileProcessor 클래스의 process 메서드는 파일을 읽고, 각 숫자에 대해 동일한 프로세스를 처리하는 공통 구조를 제공한다.
특정 로직 위임 (콜백):
- Operator 인터페이스가 구현하는 getResult 메서드를 통해, 연산의 세부적인 구현은 호출 시 전달된 람다나 구현체에 위임된다.
람다를 활용한 간결한 구현:
- Client에서 process 메서드 호출 시 (sum, number) -> sum += number라는 람다를 전달해 합계를 구하는 연산을 정의한다. 이로써 복잡한 상속 구조 없이 원하는 연산을 간단히 구현할 수 있다.

템플릿 콜백 패턴의 장단점

장점

상속 대신 위임
- 구체적인 구현을 익명 클래스나 람다로 전달하여 유연성과 가독성을 향상시킨다.
- 다중 상속 문제를 피할 수 있다.
간결성
- 코드를 짧게 작성할 수 있으며, 익명 클래스나 람다로 특정 동작을 간단히 정의할 수 있다.

단점

익숙하지 않은 개발자에게 어려움
- 람다 표현식에 익숙하지 않은 경우, 이해하기 어려울 수 있다.
알고리즘 구조 표현의 제한
- 템플릿 메소드 패턴처럼 전체 구조를 명확히 나타내기 어렵고, 로직이 함수로만 분리되기 때문에 추적하기 까다로울 수 있다.

템플릿 패턴, 실무에서는?

1. 자바의 HttpServlet

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class MyHelloServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
        resp.getWriter().write("Hello, GET!");
    }

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException {
        resp.getWriter().write("Hello, POST!");
    }
}

설명: HttpServlet은 템플릿 메소드 패턴을 기반으로, HTTP 요청 메소드(doGet, doPost)의 공통적인 흐름을 제공하고, 세부 구현은 서브클래스에서 정의한다.

2. 스프링 프레임워크에서의 활용

스프링은 템플릿 메소드 패턴과 템플릿 콜백 패턴을 활용하여 다양한 API를 제공한다.

JdbcTemplate

import org.springframework.jdbc.core.JdbcTemplate;

public class TemplateInSpring {

    public static void main(String[] args) {
        JdbcTemplate jdbcTemplate = new JdbcTemplate();
        jdbcTemplate.execute("INSERT INTO users (name) VALUES ('John')");
    }
}

RestTemplate

import org.springframework.http.*;
import org.springframework.web.client.RestTemplate;

import java.util.Arrays;

public class RestTemplateExample {

    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();

        HttpHeaders headers = new HttpHeaders();
        headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
        headers.set("X-COM-PERSIST", "NO");

        HttpEntity<String> entity = new HttpEntity<>(headers);

        ResponseEntity<String> response = restTemplate.exchange(
                "http://localhost:8080/users",
                HttpMethod.GET,
                entity,
                String.class
        );

        System.out.println(response.getBody());
    }
}

Spring Security

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .anyRequest().permitAll();
    }
}

2. 비지터 패턴 : 기존 코드를 변경하지 않고 새로운 기능을 추가하는 방법.

비지터 패턴은 객체 구조에 대해 작동하는 연산을 객체의 클래스를 수정하지 않고 추가할 수 있는 방법을 제공한다. 이는 더블 디스패치를 활용하여, 실행 시점에 실제 객체와 그에 대한 동작을 결정한다.

Before

1. Client.java

public class Client {

    public static void main(String[] args) {
        Shape rectangle = new Rectangle();
        Device device = new Phone();
        rectangle.printTo(device);
    }
}

2. Shape.java

public interface Shape {
    void printTo(Device device);
}

3. Rectangle.java

public class Rectangle implements Shape {

    @Override
    public void printTo(Device device) {
        if (device instanceof Phone) {
            System.out.println("Print Rectangle to Phone");
        } else if (device instanceof Watch) {
            System.out.println("Print Rectangle to Watch");
        }
    }
}

4. Device.java

public interface Device {
}

5. Phone.java

public class Phone implements Device {
}

6. Watch.java

public class Watch implements Device{
}

Before 문제점

확장성 문제:
- 새로운 Device 타입이 추가될 때마다 모든 Shape 클래스의 printTo 메서드를 수정해야 한다.
의존성 문제:
- Rectangle 클래스가 Device의 구체적인 구현(Phone, Watch)을 직접 참조하여 결합도가 높아진다.
중복 코드 증가:
- 각 Shape에서 유사한 조건문을 반복적으로 작성해야 한다.

After

After 개선 사항

확장성 향상:
- 새로운 Device를 추가할 때, 기존 Shape 클래스는 변경하지 않고, Device 인터페이스의 메서드를 구현하기만 하면 됨.
의존성 감소:
- Shape 클래스는 더 이상 구체적인 Device 구현을 참조하지 않고, Device 인터페이스만 참조함으로써 결합도가 낮아짐.
중복 코드 제거:
- if-else 로직을 제거하고, Shape가 Device의 메서드 호출을 통해 직접 자신의 타입을 전달하도록 개선됨.
더블 디스패치 구현:
- Shape의 accept 메서드가 호출되면, Device의 print 메서드가 실행되어 객체와 동작의 조합을 런타임에 결정함.

1. Client.java

public class Client {

    public static void main(String[] args) {
        Shape rectangle = new Rectangle();
        Device device = new Pad();
        rectangle.accept(device);
    }
}

2. Shape.java

public interface Shape {
    void accept(Device device);
}

Shape의 역할 (Element):

자신이 어떤 도형인지 표현하며, Device가 자신을 처리하도록 요청만 함.
구체적인 출력 동작은 전혀 알지 않음.
예: Rectangle 클래스는 Device에게 "나를 출력해줘"라는 메시지를 전달 (accept 메서드).

3. Rectangle.java

public class Rectangle implements Shape {

    @Override
    public void accept(Device device) {
        device.print(this);
    }
}

4. Device.java

public interface Device {
    void print(Circle circle);

    void print(Rectangle rectangle);

    void print(Triangle triangle);
}

Device의 역할 (Visitor):

각 Shape를 처리하는 구체적인 로직을 담당.
예: Pad 클래스는 Rectangle, Circle, Triangle 각각에 대해 처리 방식을 정의.

5. Pad.java

public class Pad implements Device {

    @Override
    public void print(Circle circle) {
        System.out.println("Print Circle to Pad");
    }

    @Override
    public void print(Rectangle rectangle) {
        System.out.println("Print Rectangle to Pad");
    }

    @Override
    public void print(Triangle triangle) {
        System.out.println("Print Triangle to Pad");
    }
}

6. 추가적인 Shape 클래스 (예: Circle.java, Triangle.java)

public class Circle implements Shape {

    @Override
    public void accept(Device device) {
        device.print(this);
    }
}

public class Triangle implements Shape {

    @Override
    public void accept(Device device) {
        device.print(this);
    }
}

비지터 패턴으로 인한 변화

Before: Shape가 Device를 알고, 구체적인 동작을 스스로 정의.
After:
- Shape는 자신의 존재를 알리는 역할만.
- Device가 Shape를 처리하는 모든 동작을 정의.
- 새로운 Device를 추가할 때도 기존 Shape는 수정하지 않음.

도형(Shape):
- accept(Device device)를 통해 디바이스를 호출하고, 처리 권한을 위임한다.
디바이스(Device):
- print(Shape shape) 메서드를 통해 구체적인 출력 형식을 정의한다.

다이어그램

비지터 패턴의 장단점

장점

확장성 향상:
- 새로운 동작(비지터)을 추가할 때 기존의 클래스 구조를 수정할 필요가 없다.
기능 집중화:
- 새로운 기능(비지터)들을 한곳에 모아 유지보수성을 높일 수 있다.

단점

복잡성 증가:
- 모든 새로운 Shape 클래스가 Device 인터페이스의 모든 메서드를 처리해야 한다.
새로운 Element 추가 어려움:
- 새로운 Shape 클래스가 추가되면, 기존 Device 구현체를 모두 수정해야 한다.

실무에서의 비지터 패턴

1. 자바 API에서 활용

1. 자바 API에서 비지터 패턴 활용

FileVisitor와 SimpleFileVisitor는 자바 NIO 파일 시스템에서 파일 트리 탐색을 처리하기 위해 비지터 패턴을 사용한다.

`FileVisitor` 예제: 특정 파일 검색

import java.io.IOException;
import java.nio.file.FileVisitResult;
import java.nio.file.FileVisitor;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributes;

public class SearchFileVisitor implements FileVisitor<Path> {

    private String fileToSearch;
    private Path startingDirectory;

    public SearchFileVisitor(String fileToSearch, Path startingDirectory) {
        this.fileToSearch = fileToSearch;
        this.startingDirectory = startingDirectory;
    }

    // 디렉토리 방문 전 처리
    @Override
    public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) {
        System.out.println("Visiting directory: " + dir);
        return FileVisitResult.CONTINUE; // 다음으로 계속
    }

    // 파일 방문 시 처리
    @Override
    public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
        if (fileToSearch.equals(file.getFileName().toString())) {
            System.out.println("Found file: " + file);
            return FileVisitResult.TERMINATE; // 탐색 종료
        }
        return FileVisitResult.CONTINUE;
    }

    // 파일 방문 실패 시 처리
    @Override
    public FileVisitResult visitFileFailed(Path file, IOException exc) {
        exc.printStackTrace();
        return FileVisitResult.CONTINUE;
    }

    // 디렉토리 방문 후 처리
    @Override
    public FileVisitResult postVisitDirectory(Path dir, IOException exc) {
        System.out.println("Finished visiting directory: " + dir);
        return FileVisitResult.CONTINUE;
    }
}

사용 코드

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class VisitorInJava {

    public static void main(String[] args) throws IOException {
        Path startingDirectory = Path.of("/path/to/start"); // 탐색 시작 경로
        SearchFileVisitor searchFileVisitor = new SearchFileVisitor("targetFile.txt", startingDirectory);
        Files.walkFileTree(startingDirectory, searchFileVisitor);
    }
}

주요 특징 및 설명

FileVisitor의 역할:
- 탐색 중 각 파일 또는 디렉토리를 방문할 때 호출된다.
- 디렉토리 방문 전(preVisitDirectory), 파일 방문 시(visitFile), 방문 실패 시(visitFileFailed), 디렉토리 방문 후(postVisitDirectory)의 단계로 나뉜다.
- 비지터 패턴을 통해 탐색 로직과 파일 처리를 명확히 분리한다.
확장 가능성:
- 새로운 작업(예: 파일 삭제, 크기 계산 등)을 추가하려면 기존 코드(walkFileTree)를 수정하지 않고, 새로운 FileVisitor 구현체를 작성하면 된다.
실무에서 활용:
- 로그 수집기, 파일 검색 도구, 디렉토리 크기 계산 등 다양한 파일 시스템 작업에 활용된다.

2. 스프링 프레임워크에서 비지터 패턴 활용

BeanDefinitionVisitor는 스프링의 빈 정의를 탐색하고, 필요한 변경 작업을 수행할 수 있도록 설계된 클래스이다.

예제: `BeanDefinitionVisitor`의 역할

import org.springframework.beans.factory.config.BeanDefinitionVisitor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;

public class CustomBeanVisitor {

    public void visitBeans(ConfigurableListableBeanFactory beanFactory) {
        BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(value -> {
            // 특정 값을 마스킹
            if (value instanceof String && ((String) value).contains("password")) {
                return "******"; // 비밀번호 마스킹 처리
            }
            return value;
        });

        for (String beanName : beanFactory.getBeanDefinitionNames()) {
            visitor.visitBeanDefinition(beanFactory.getBeanDefinition(beanName));
        }
    }
}

주요 특징 및 설명

BeanDefinitionVisitor의 역할:
- 스프링 컨테이너에서 등록된 빈 정의를 순회하면서 값을 수정하거나 검사할 수 있도록 한다.
활용 사례:
- 민감 정보(예: 비밀번호, API 키)를 마스킹하거나, 특정 조건에 따라 빈 정의를 수정하는 데 사용된다.
확장 가능성:
- 새로운 작업을 추가하려면, BeanDefinitionVisitor에 전달할 커스텀 로직을 정의하면 된다.

출처 : 코딩으로 학습하는 GoF의 디자인 패턴

JMM

이전 포스트

[GoF 디자인 패턴] 템플릿 메소드(Template method) 패턴, 방문자 (Visitor) 패턴

GoF 디자인 패턴

1.1 템플릿 메소드 패턴 : 알고리듬 구조를 서브 클래스가 확장할 수 있도록 템플릿으로 제공하는 방법.

추상 클래스는 템플릿을 제공하고 하위 클래스는 구체적인 알고리듬을 제공한다.

Before

1. Client.java

2. FileProcessor.java

3. MultuplyFileProcessor.java

Before 문제점

기본적으로 특정 연산 부분을 바꾸기 위해 새로운 FileProcessor를 생성해야 하는 번거로움과, 코드 중복 문제, 유지 보수가 어렵다!

1. 중복된 코드

2. 유지보수 어려움

After

1. Client.java

2. FileProcessor.java

3. MultiplyFileProcessor.java

4. PlusFileProcessor.java

다이어그램

템플릿 메소드 패턴의 장점과 단점

장점

단점

1.2 템플릿 콜백 패턴: 콜백으로 상속 대신 위임을 사용하는 템플릿 패턴.

상속 대신 익명 내부 클래스 또는 람다 표현식을 활용할 수 있다.

템플릿 콜백 패턴 적용 코드

1. Operator.java

2. FileProcessor

3. Client.java

콜백 패턴 동작 방식:

템플릿 콜백 패턴의 장단점

장점

단점

템플릿 패턴, 실무에서는?

1. 자바의 HttpServlet

2. 스프링 프레임워크에서의 활용

2. 비지터 패턴 : 기존 코드를 변경하지 않고 새로운 기능을 추가하는 방법.

Before

1. Client.java

2. Shape.java

3. Rectangle.java

4. Device.java

5. Phone.java

6. Watch.java

Before 문제점

After

After 개선 사항

1. Client.java

2. Shape.java

Shape의 역할 (Element):

3. Rectangle.java

4. Device.java

Device의 역할 (Visitor):

5. Pad.java

6. 추가적인 Shape 클래스 (예: Circle.java, Triangle.java)

비지터 패턴으로 인한 변화

다이어그램

비지터 패턴의 장단점

장점

단점

실무에서의 비지터 패턴

1. 자바 API에서 활용

1. 자바 API에서 비지터 패턴 활용

FileVisitor 예제: 특정 파일 검색

사용 코드

주요 특징 및 설명

2. 스프링 프레임워크에서 비지터 패턴 활용

예제: BeanDefinitionVisitor의 역할

주요 특징 및 설명

[GoF 디자인 패턴] 상태(State) 패턴, 전략 (Strategy) 패턴

0개의 댓글

[GoF 디자인 패턴] 템플릿 메소드(Template method) 패턴, 방문자 (Visitor) 패턴

`FileVisitor` 예제: 특정 파일 검색

예제: `BeanDefinitionVisitor`의 역할