스트래티지 패턴

이연희·2022년 7월 14일

Design_Pattern

목록 보기

2/11

Chap5 Strategy Pattern

Robot이라는 추상 클래스의 자식 클래스로 Atom과 TaekwonV 클래스가 있다고 가정하자. Atom과 TaewonV 둘 다 attack(), move() 기능이 있는 로봇의 한 종류이다.

public abstract class Robot {
    private String name;
    ...
    public abstract void attack();
    public abstract void move();
}

public class TaekwonV extends Robot{
    public TaekwonV(String name) {
        super(name);
    }

    @Override
    public void attack() {
        System.out.println("I have Missile and can attack with it");
    }

    @Override
    public void move() {
        System.out.println("I can only walk");
    }
}

public class Atom extends Robot{
    public Atom(String name) {
        super(name);
    }

    @Override
    public void attack() {
        System.out.println("I have strong punch and can attack with it");
    }

    @Override
    public void move() {
        System.out.println("I can fly");
    }
}

문제점

기존 로봇의 attack 또는 move 방법을 수정하려면 각 구현 객체의 메서드를 수정해야 한다. 새로운 기능으로 변경하기 위해 기존 코드의 내용을 수정해야 하므로 이런 방식은 OCP(Open-closed principle)에 위배된다. 또한 메서드간 코드의 중복이 있을 수 있어 새로운 방식으로 수정하려면 모든 중복된 코드를 일관성있게 변경해야 하는 문제가 있다. 로봇의 종류가 많아질수록 중복 코드를 일관성 있게 유지하는 일은 매우 어렵다.

해결책

로봇 설계에서 문제를 해결하려면 무엇이 변화되었는지 찾아 캡슐화해야 한다. 문제를 발생시키는 요인은 로봇의 이동방식(move)과 공격방식(attack)의 변화이다. 즉 새로운 방식의 이동, 공격 기능이 계속 추가될 수 있으므로 별다른 코드 변경없이 변화 부분을 쉽게 변경할 수 있어야 한다.

이동 기능을 캡슐화하는 MovingStrategy와 공격 기능을 캡슐화하는 AttackStrategy 인터페이스를 제작한다. 인터페이스로 인해 새로운 기능의 추가가 기존 코드에 영향을 미치치 못하게 하므로 OCP를 만족하는 설계가 된다.

interface MovingStrategy{
	public void move();
}
public class FlyinStrategy implements MovingStrategy{
	public void move(){...}
}
public class WalkingStrategy implements MovingStrategy{
	public void move(){...}
}

interface AttackStrategy{
	public void attack();
}
public class MissileStrategy implements AttackStrategy{
	public void attack(){...}
}
public class PunchStrategy implements AttackStrategy{
	public void attack(){...}
}