반응형
커맨드 패턴이 무엇이며, 자바에서 어떻게 구현되는 지 알아본다.
커맨드(Command) 패턴
프로그래밍을 하다보면 사용자가 선택한(또는 입력한) 명령어에 따라 그에 알맞은 처리를 해야 할 때가 있다. 예를 들어, 워드프로세서를 생각해보자. 사용자들은 복사(copy), 잘라내기(cut), 붙여넣기(paste) 기능을 사용한다. 이 때 복사, 잘라내기, 붙여넣기 등은 모두 한번의 명령어에 해당한다. 사용자들은 메뉴나 툴바의 아이콘 또는 키보드 단축키를 사용함으로써 워드 프로세서에 이 명령들을 실행할 것을 요청하며, 워드 프로세서는 사용자가 전달한 명령어에 알맞은 기능을 실행한다. 그리고 대부분의 워드 프로세서는 사용자가 실행한 명령을 취소할 수 있는 '명령 취소(Undo)' 기능을 제공하고 있다. 이러한 취소 기능을 제공하기 위해서는 사용자가 실행한 명령어들을 순서대로 저장할 수 있어야 한다. 이처럼 명령어를 실행하고, 실행한 명령어를 저장하고, 실행한 명령을 취소하고, 재실행하고 또는 그러한 명령어를 처리할 때 사용되는 패턴이 바로 커맨드(Command) 패턴이다.
커맨드 패턴은 사용자가 요구하는 명령어를 객체에 캡슐화(encapsulation)하여 저장한다. 각각의 명령어에 해당하는 객체는 그 명령어에 해당하는 기능을 실행하며, 필요에 따라 '명령 취소' 기능을 제공한다. 명령어와 관련된 사항이 객체에 캡슐화되어 있기 때문에, 사용자들은 단순히 그 명령어 객체를 생성해서 사용하기만 하면 된다. 또한, 이러한 명령어 객체들은 모두 공동의 상위 클래스를 갖고 있다. 이 상위 클래스는 각 명령어 객체의 클래스가 구현해야 할 메소드를 정의하고 있다. 예를 들어, 워드 프로세서에서 사용되는 '복사', '잘라내기', '붙여넣기'에 해당하는 명령어 클래스를 각각 CopyCommand, CutCommand, PasteCommand 라고 하자. 그리고 이 세 클래스가 상속받는 추상 클래스를 AbstractCommand 라고 하자. 이 경우 전체적인 클래스 사이의 관계는 다음 그림과 같을 것이다.
AbstractCommand 클래스는 모든 명령어 클래스가 상속받아야 할 클래스로서 추상 메소드인 execute()와 undo()를 선언하고 있다. 메소드의 이름에서 알 수 있듯이 execute() 메소드는 명령어에 해당하는 기능을 실행하기 위해 호출되는 메소드이며, 따라서 execute() 메소드는 실제 기능을 구현하고 있다. 반면에 undo() 메소드는 '명령 취소'에 해당하는 기능을 제공한다. AbstractCommand 추상 클래스를 상속받는 클래스들은 그 클래스에 알맞도록 execute() 메소드와 undo() 메소드를 구현하면 된다. 예를 들어, CopyCommand 클래스의 execute() 메소드는 사용자가 설정한 블럭에 속한 글자들을 클립보드에 복사할 것이며, undo() 메소드는 클립보드에 저장되어 있는 글자들을 삭제할 것이다.
이제 남은 것은 각각의 명령어 객체를 저장하고 관리해주는 관리자 클래스인 CommandManager 클래스가 필요하다. 이 클래스는 실행되는 명령어를 차례대로 저장하고 있으며, 사용자가 '명령취소'를 요청할 경우 가장 최근에 저장된 명령어 객체의 undo() 메소드를 호출해주는 역할을 한다. 즉, 전체적인 클래스 사이의 관계는 다음과 같다.
여기서 Invoker는 워드프로세서의 경우 사용자가 메뉴를 선택하거나 툴바를 클릭했을 때 발생하는 이벤트를 처리해주는 이벤트 리스너(예를 들어, ActionListener나 ItemListener 등)가 되며, ConcreteCommand 클래스는 CopyCommand와 CutCommand와 같이 실제 명령을 실행(구현)하는 명령어 객체를 나타낸다. CommandManager는 AbstractCommand를 관리하는 클래스이다.
커맨드 패턴의 구현
이제 커맨드 패턴이 실제로 어떻게 구현되는 지 살펴보자. 가장 먼저 AbstractCommand 추상 클래스의 코드를 살펴보자.
위 코드를 살펴보면 CommandManager의 인스턴스를 static 필드로 갖고 있는 것을 알 수 있다. 이는 Invoker가 단순히 ConcreteCommand 클래스의 인스턴스를 생성만 하면 되도록 하기 위해서이다. 이에 대한 내용은 ConcreteCommand 클래스의 구현 방법을 알아볼 때 설명하기로 한다. 위 코드에서 execute()와 undo() 메소드는 모두 boolean을 리턴값으로 갖는다. execute() 메소드는 실제 명령이 올바르게 수행된 경우 true를 리턴하고, 그렇지 않은 경우 false를 리턴한다. 비슷하게 undo() 메소드는 '명령 취소'가 성공했을 경우 true를 리턴하고, 그렇지 않을 경우 false를 리턴한다.
이제 ConcreteCommand 클래스가 어떻게 구현되었는 지 살펴보자. 예를 들어, PasteCommand 클래스의 경우 다음과 같은 코드를 가질 것이다.
위 코드를 보면 PasteCommand 클래스는 AbstractCommand 클래스에 있는 두 추상 메소드인 execute()와 undo()를 구현한 것을 알 수 있다. 특이할 만한 점은 PasteCommand의 생성자이다. 생성자의 마지막 줄을 보면 CommandManager의 executeCommand() 메소드를 호출하는 것을 알 수 있다. 즉, 명령어 객체를 사용하는 객체들은 CommandManager에 대한 자세한 내용을 알 필요 없이 단순히 명령어 객체를 생성하기만 하면 된다. 예를 들어, '복사' 메뉴와 관련된 java.awt.MenuItem을 생각해보자. 이 MenuItem과 관련된 코드 부분은 다음과 같을 것이다.
위 코드는 전형적인 메뉴 생성 방법을 나타내고 있다. 위 코드에서 마지막 줄에 있는 PasteActionListener는 ActionListener를 implements한 클래스로서 다음과 같다.
이제 사용자들이 메뉴에서 "붙여넣기"를 클릭하면 PasteActionListener의 actionPerformed() 메소드가 호출되고, 이어서 PasteCommand 객체가 생성된다. 그러면 PasteCommand 클래스의 생성자에서 CommandManager의 executeCommand() 메소드를 호출하게 된다. 지금까지의 코드 만으로도 실제 사용자의 입력을 받는 MenuItem 객체와 실제 내부적으로 "붙여넣기"를 처리하는 PasteCommand 객체와 상관이 없다는 것을 알 수 있다. 이제 CommandManager 클래스를 살펴보자. CommandManager 클래스는 다음과 같다.
먼저 CommandManager 클래스가 가지고 있는 첫번째 필드인 history는 사용자가 입력한 명령어를 순서대로 저장하는 리스트이며, 두번째 필드 redoList 는 사용자가 '실행 취소'한 것을 저장하는 리스트이다. undo() 메소드와 redo() 메소드는 실제로 '명령 취소'와 '취소 명령 재실행'을 수행하고, addToHistory() 메소드는 최근에 수행한 명령어를 history에 수행한다.
이제, CommandManager 클래스의 메소드 중에서 실제로 다른 객체들이 사용하는 executeCommand() 메소드를 살펴보자. 이 메소드는 명령어 객체(즉, AbstractCommand를 상속받은 클래스)를 파라미터로 넘겨 받고 그 command를 실행한다. 여기서 command.execute() 메소드를 실행하는 부분을 살펴보자.
여기서 AbstractCommand의 execute() 메소드는 boolean을 리턴하며(기억이 안 난다면, 앞에 있는 AbstractCommand 클래스의 소스 코드를 살펴보라), 만약 true를 리턴하며 addToHistory() 메소드를 사용하여 history 필드에 추가하고, false를 리턴하면 명령어가 실패했음을 알린다.
CommandManager 클래스에서 아직까지 설명하지 않은 것이 있다면 Undo와 Redo이다. Undo와 Redo는 인터페이스이며, 그 정의는 단순히 다음과 같다.
즉, Undo와 Redo는 Serializable 인터페이스와 마찬가지로 단순히 이 두 인터페이스를 implements 한 클래스의 타입이 Redo와 Undo라는 것을 보여준다. '명령 취소'와 관련된 명령어 클래스는 UndoCommand 이며 다음과 같다.
RedoCommand 역시 UndoCommand와 비슷하다. 실제로 사용자가 '명령 취소'를 클릭하면 이를 처리하는 이벤트 리스너는 단순히 다음과 같은 코드를 실행하면 된다.
커맨드 패턴을 사용함으로써 사용자로부터 요청을 받는 객체(즉, 메뉴나 툴바)와 실제로 사용자가 필요로 하는 기능을 구현한 객체를 완전히 분리할 수 있게 되었다. 따라서 사용자로부터 요청을 받는 객체는 실제 내부 로직이 어떻게 되는 지 알 필요가 없으며, 내부 로직을 구현한 명령어 객체 역시 사용자로부터 어떻게 요청을 받는 지 알 필요가 없다. 즉, 이 두 객체 사이에 의존관계가 없는 것이다. 따라서 요청을 받는 객체를 변경할 필요 없이 손쉽게 새로운 명령어 객체를 추가할 수 있다.
또 다른 구현 방법
여기서 AbstractCommand가 추상 클래스로 선언된 것은 static final 필드로 CommandManager를 갖고 있기 때문이다. 실제로 명령어 객체를 순서대로 저장하고 명령어 객체의 실행을 취소하는 것 등의 작업이 필요하지 않다면 CommandManager가 필요 없을 것이다. 이런 경우 추상 클래스 대신 인터페이스를 사용하여 AbstractCommand를 대신할 수 있다. 만약 AbstracCommand 대신 사용할 인터페이스가 CommandIF 라고 한다면, CommandIF 인터페이스는 다음과 같이 정의될 것이다.
이제, 명령어 클래스들은 AbtractCommand를 상속받는 대신 CommandIF 인터페이스를 구현할 것이다. 예를 들어, PasteCommand 클래스의 경우 다음과 같이 바뀔 것이다.
이제, PasteCommand 클래스를 사용하는 PasteListener 클래스의 actionPerformed() 메소드는 다음과 같이 변경된다.
직접 execute() 메소드를 호출해주는 것을 알 수 있다.
CommandFactory를 이용하여 객체간의 관련성 감소시키기
앞에 있는 PasteActionLister 클래스는 AbstractCommand 클래스를 사용하는 경우나 CommandIF 인터페이스를 사용하는 경우 모두 actionPerformed() 메소드에서 반드시 PasteCommand 클래스를 사용하고 있다. 이제 CopyActionListener 클래스를 생각해보자. 이 클래스는 CopyCommand 클래스를 사용한다는 것을 제외하면 PasteActionListener 클래스와 완전히 동일하다. CutActionListener 역시 마찬가지이다. 그렇다면 어떻게 하면 될까? 가장 먼저 생각할 수 있는 것이 이러한 ActionListener를 다음과 같이 하나로 묶어주는 것이다.
물론, 이것만으로도 MenuItem과 실제 명령어 객체(CommandIF 인터페이스를 구현한 객체 또는 AbstractCommand 추상클래스를 상속받은 객체)와의 관련성을 없앤 채로 CommonActionListener를 사용하여 이 두 객체를 연결시킬 수 있다. 이를 좀더 객체지향적으로 접근한 것이 바로 CommandFactory 클래스이다. CommandFactory 클래스는 CommonActionListener 클래스의 actionPerformed() 메소드에서 if .. else .. 부분을 처리해주며 코드 형태는 다음과 같다.
실제로, CommandFactory 클래스는 팩토리(Factory) 패턴을 간단하게 구현한 것으로서 팩토리 패턴에 대한 자세한 내용은 패턴 관련 서적을 참조하기 바란다. 이제 CommandFactory 클래스를 사용하면 CommonActionListener는 다음과 같이 간단하게 바뀌게 된다.
CommonActionListener 클래스의 소스 코드가 간단해지긴 했지만, 왜 굳이 CommandFactory 클래스를 생성하는 지 의아해 할지도 모르겠다. 위만 보더라도 CommonActionListener에서 모든 걸 다 처리할 수 있기 때문이다. 하지만, 메뉴 뿐만 아니라 단축키를 통해서 사용자들에게 "복사", "잘라내기", "덧붙이기" 기능을 제공하길 원한다고 가정해보자. 이 경우, CommandFactory 객체를 사용하지 않는다면 키보드 이벤트를 처리하는 클래스는 다음과 같은 형태를 취할 것이다.
ShortCutListener 클래스가 CommonActionListener 클래스와 거의 비슷한 것을 알 수 있다. 즉, 코드가 중복되는 것이다. 이 경우 Command 클래스가 추가되면 ShortCutListener 클래스와 CommonActionListener가 모두 영향을 받게 된다. 또한, CopyCommand 클래스 대신 Copy2Command 클래스를 사용하는 경우에도, 이 두 Listener 클래스는 영향을 받게 된다. 반면에 CommandFactory 객체를 사용하게 되면, Command 클래스가 추가되거나 변경되거나 삭제된다고 해도 오직 CommandFactory 클래스만 영향을 받게 된다. 즉, 두 Listener 클래스는 오직 CommandIF 인터페이스와 CommandFactory 클래스만 알면 될 뿐, 실제 Command 객체들에 대한 자세한 내용을 알 필요가 없는 것이다. 다시 말해서, 객체간의 관련성이 감소하게 된다. (객체 지향적인 설계에서 객체 사이의 관련성을 줄이는 것은 매우 중요하다!)
결론
지금까지 커맨드 패턴의 구현에 대해서 알아보았다. 커맨드 패턴을 통해서 사용자들은 명령어를 입력받는 객체가 그 명령어의 실제 구현에 대해서 알 필요 없이 명령어 객체를 사용하기만 하면 되었다. 또한, 명령어를 입력받는 객체와 처리하는 명령어 객체 사이에서 커맨드 팩토리를 사용함으로써 객체 사이의 관련성을 최대한 줄일 수 있게 되었다. 실제로 커맨드 패턴의 핵심은 명령어를 처리하는 부분을 객체로 캡슐화 함으로써 실제 내부 구현을 다른 객체들로부터 분리하는 것에 있다.
관련링크:
커맨드(Command) 패턴
프로그래밍을 하다보면 사용자가 선택한(또는 입력한) 명령어에 따라 그에 알맞은 처리를 해야 할 때가 있다. 예를 들어, 워드프로세서를 생각해보자. 사용자들은 복사(copy), 잘라내기(cut), 붙여넣기(paste) 기능을 사용한다. 이 때 복사, 잘라내기, 붙여넣기 등은 모두 한번의 명령어에 해당한다. 사용자들은 메뉴나 툴바의 아이콘 또는 키보드 단축키를 사용함으로써 워드 프로세서에 이 명령들을 실행할 것을 요청하며, 워드 프로세서는 사용자가 전달한 명령어에 알맞은 기능을 실행한다. 그리고 대부분의 워드 프로세서는 사용자가 실행한 명령을 취소할 수 있는 '명령 취소(Undo)' 기능을 제공하고 있다. 이러한 취소 기능을 제공하기 위해서는 사용자가 실행한 명령어들을 순서대로 저장할 수 있어야 한다. 이처럼 명령어를 실행하고, 실행한 명령어를 저장하고, 실행한 명령을 취소하고, 재실행하고 또는 그러한 명령어를 처리할 때 사용되는 패턴이 바로 커맨드(Command) 패턴이다.
커맨드 패턴은 사용자가 요구하는 명령어를 객체에 캡슐화(encapsulation)하여 저장한다. 각각의 명령어에 해당하는 객체는 그 명령어에 해당하는 기능을 실행하며, 필요에 따라 '명령 취소' 기능을 제공한다. 명령어와 관련된 사항이 객체에 캡슐화되어 있기 때문에, 사용자들은 단순히 그 명령어 객체를 생성해서 사용하기만 하면 된다. 또한, 이러한 명령어 객체들은 모두 공동의 상위 클래스를 갖고 있다. 이 상위 클래스는 각 명령어 객체의 클래스가 구현해야 할 메소드를 정의하고 있다. 예를 들어, 워드 프로세서에서 사용되는 '복사', '잘라내기', '붙여넣기'에 해당하는 명령어 클래스를 각각 CopyCommand, CutCommand, PasteCommand 라고 하자. 그리고 이 세 클래스가 상속받는 추상 클래스를 AbstractCommand 라고 하자. 이 경우 전체적인 클래스 사이의 관계는 다음 그림과 같을 것이다.
AbstractCommand 클래스는 모든 명령어 클래스가 상속받아야 할 클래스로서 추상 메소드인 execute()와 undo()를 선언하고 있다. 메소드의 이름에서 알 수 있듯이 execute() 메소드는 명령어에 해당하는 기능을 실행하기 위해 호출되는 메소드이며, 따라서 execute() 메소드는 실제 기능을 구현하고 있다. 반면에 undo() 메소드는 '명령 취소'에 해당하는 기능을 제공한다. AbstractCommand 추상 클래스를 상속받는 클래스들은 그 클래스에 알맞도록 execute() 메소드와 undo() 메소드를 구현하면 된다. 예를 들어, CopyCommand 클래스의 execute() 메소드는 사용자가 설정한 블럭에 속한 글자들을 클립보드에 복사할 것이며, undo() 메소드는 클립보드에 저장되어 있는 글자들을 삭제할 것이다.
이제 남은 것은 각각의 명령어 객체를 저장하고 관리해주는 관리자 클래스인 CommandManager 클래스가 필요하다. 이 클래스는 실행되는 명령어를 차례대로 저장하고 있으며, 사용자가 '명령취소'를 요청할 경우 가장 최근에 저장된 명령어 객체의 undo() 메소드를 호출해주는 역할을 한다. 즉, 전체적인 클래스 사이의 관계는 다음과 같다.
여기서 Invoker는 워드프로세서의 경우 사용자가 메뉴를 선택하거나 툴바를 클릭했을 때 발생하는 이벤트를 처리해주는 이벤트 리스너(예를 들어, ActionListener나 ItemListener 등)가 되며, ConcreteCommand 클래스는 CopyCommand와 CutCommand와 같이 실제 명령을 실행(구현)하는 명령어 객체를 나타낸다. CommandManager는 AbstractCommand를 관리하는 클래스이다.
커맨드 패턴의 구현
이제 커맨드 패턴이 실제로 어떻게 구현되는 지 살펴보자. 가장 먼저 AbstractCommand 추상 클래스의 코드를 살펴보자.
public abstract class AbstractCommand {
public final static CommandManager manager = new CommandManager();
/**
* 이 객체가 캡슐화하고 있는 명령을 수행한다.
*/
public abstract boolean execute();
/**
* execute()를 통해서 수행된 작업을 취소한다.
*/
public abstract boolean undo();
}
public final static CommandManager manager = new CommandManager();
/**
* 이 객체가 캡슐화하고 있는 명령을 수행한다.
*/
public abstract boolean execute();
/**
* execute()를 통해서 수행된 작업을 취소한다.
*/
public abstract boolean undo();
}
위 코드를 살펴보면 CommandManager의 인스턴스를 static 필드로 갖고 있는 것을 알 수 있다. 이는 Invoker가 단순히 ConcreteCommand 클래스의 인스턴스를 생성만 하면 되도록 하기 위해서이다. 이에 대한 내용은 ConcreteCommand 클래스의 구현 방법을 알아볼 때 설명하기로 한다. 위 코드에서 execute()와 undo() 메소드는 모두 boolean을 리턴값으로 갖는다. execute() 메소드는 실제 명령이 올바르게 수행된 경우 true를 리턴하고, 그렇지 않은 경우 false를 리턴한다. 비슷하게 undo() 메소드는 '명령 취소'가 성공했을 경우 true를 리턴하고, 그렇지 않을 경우 false를 리턴한다.
이제 ConcreteCommand 클래스가 어떻게 구현되었는 지 살펴보자. 예를 들어, PasteCommand 클래스의 경우 다음과 같은 코드를 가질 것이다.
public class PasteCommand extends AbstractCommand {
....
public PasteCommand(Document document, int position) {
this.document = document;
this.position = position;
....
manager.executeCommand(this);
}
public boolean execute() {
try {
document.insertStringCommand(position, pasteString);
} catch(Exception ex) {
return false;
}
return true;
}
public boolean undo() {
try {
document.deleteStringCommand(position, pasteString.length() );
} catch(Exception ex) {
return false;
}
return true;
}
}
....
public PasteCommand(Document document, int position) {
this.document = document;
this.position = position;
....
manager.executeCommand(this);
}
public boolean execute() {
try {
document.insertStringCommand(position, pasteString);
} catch(Exception ex) {
return false;
}
return true;
}
public boolean undo() {
try {
document.deleteStringCommand(position, pasteString.length() );
} catch(Exception ex) {
return false;
}
return true;
}
}
위 코드를 보면 PasteCommand 클래스는 AbstractCommand 클래스에 있는 두 추상 메소드인 execute()와 undo()를 구현한 것을 알 수 있다. 특이할 만한 점은 PasteCommand의 생성자이다. 생성자의 마지막 줄을 보면 CommandManager의 executeCommand() 메소드를 호출하는 것을 알 수 있다. 즉, 명령어 객체를 사용하는 객체들은 CommandManager에 대한 자세한 내용을 알 필요 없이 단순히 명령어 객체를 생성하기만 하면 된다. 예를 들어, '복사' 메뉴와 관련된 java.awt.MenuItem을 생각해보자. 이 MenuItem과 관련된 코드 부분은 다음과 같을 것이다.
Menu menu = new Menu ("편집");
MenuItem pasteMenuItem = new MenuItem("붙여넣기");
menu.add(pasteMenuItem);
pasteMenuItem.addActionListener(new PasteActionListener());
MenuItem pasteMenuItem = new MenuItem("붙여넣기");
menu.add(pasteMenuItem);
pasteMenuItem.addActionListener(new PasteActionListener());
위 코드는 전형적인 메뉴 생성 방법을 나타내고 있다. 위 코드에서 마지막 줄에 있는 PasteActionListener는 ActionListener를 implements한 클래스로서 다음과 같다.
public class PasteActionListener implements ActionListener {
public void actionPerformed(ActionEvent e) {
// 현재 document와 position을 구한다.
.....
new PasteCommand(document, position); // 명령어 객체 생성
}
}
public void actionPerformed(ActionEvent e) {
// 현재 document와 position을 구한다.
.....
new PasteCommand(document, position); // 명령어 객체 생성
}
}
이제 사용자들이 메뉴에서 "붙여넣기"를 클릭하면 PasteActionListener의 actionPerformed() 메소드가 호출되고, 이어서 PasteCommand 객체가 생성된다. 그러면 PasteCommand 클래스의 생성자에서 CommandManager의 executeCommand() 메소드를 호출하게 된다. 지금까지의 코드 만으로도 실제 사용자의 입력을 받는 MenuItem 객체와 실제 내부적으로 "붙여넣기"를 처리하는 PasteCommand 객체와 상관이 없다는 것을 알 수 있다. 이제 CommandManager 클래스를 살펴보자. CommandManager 클래스는 다음과 같다.
class CommandManager {
private static final int MAX_HISTORY_LENGTH = 50;
private LinkedList history = new LinkedList();
private LinkedList redoList = new LinedList();
// 인자로 받은 AbstractCommand를 실행한다.
// 만약 command가 Undo나 Redo의 인스턴스일 경우에는
// 각각 '명령 취소'와 '취소 명령 재실행'을 수행한다.
public void executeCommand(AbstractCommand command) {
if (command instanceof Undo) {
undo();
return;
}
if (command instanceof Redo) {
redo();
return;
}
if (command.execute()) {
addToHistory(command);
} else { // execute()가 false를 리턴한 경우, 즉 명령어가 올바르게 실행되지 않은 경우
// 명령어가 실패했다는 것을 알린다.
}
}
// 바로 이전에 실행한 명령어를 취소한다.
private void undo() {
if (history.size() > 0 ) { // 사용자가 실행한 명령어가 있을 경우
AbstractCommand undoCommand = (AbstractCommand) history.removeFirst();
undoCommand.undo();
redoList.addFirst(undoCommand);
}
}
// 바로 이전에 취소한 명령어를 다시 실행한다.
private void redo() {
if (redoList.size() > 0) {
AbstractCommand redoCommand = (AbstractCommand) redoList.removeList();
redoCommand.execute();
history.addFirst(redoCommand);
}
}
// history에 사용자가 실행한 명령어를 저장한다.
private void addToHistory(AbstractCommand command) {
history.addFirst(command);
if (history.size() > MAX_HISTORY_LENGTH)
history.removeLast();
}
}
private static final int MAX_HISTORY_LENGTH = 50;
private LinkedList history = new LinkedList();
private LinkedList redoList = new LinedList();
// 인자로 받은 AbstractCommand를 실행한다.
// 만약 command가 Undo나 Redo의 인스턴스일 경우에는
// 각각 '명령 취소'와 '취소 명령 재실행'을 수행한다.
public void executeCommand(AbstractCommand command) {
if (command instanceof Undo) {
undo();
return;
}
if (command instanceof Redo) {
redo();
return;
}
if (command.execute()) {
addToHistory(command);
} else { // execute()가 false를 리턴한 경우, 즉 명령어가 올바르게 실행되지 않은 경우
// 명령어가 실패했다는 것을 알린다.
}
}
// 바로 이전에 실행한 명령어를 취소한다.
private void undo() {
if (history.size() > 0 ) { // 사용자가 실행한 명령어가 있을 경우
AbstractCommand undoCommand = (AbstractCommand) history.removeFirst();
undoCommand.undo();
redoList.addFirst(undoCommand);
}
}
// 바로 이전에 취소한 명령어를 다시 실행한다.
private void redo() {
if (redoList.size() > 0) {
AbstractCommand redoCommand = (AbstractCommand) redoList.removeList();
redoCommand.execute();
history.addFirst(redoCommand);
}
}
// history에 사용자가 실행한 명령어를 저장한다.
private void addToHistory(AbstractCommand command) {
history.addFirst(command);
if (history.size() > MAX_HISTORY_LENGTH)
history.removeLast();
}
}
먼저 CommandManager 클래스가 가지고 있는 첫번째 필드인 history는 사용자가 입력한 명령어를 순서대로 저장하는 리스트이며, 두번째 필드 redoList 는 사용자가 '실행 취소'한 것을 저장하는 리스트이다. undo() 메소드와 redo() 메소드는 실제로 '명령 취소'와 '취소 명령 재실행'을 수행하고, addToHistory() 메소드는 최근에 수행한 명령어를 history에 수행한다.
이제, CommandManager 클래스의 메소드 중에서 실제로 다른 객체들이 사용하는 executeCommand() 메소드를 살펴보자. 이 메소드는 명령어 객체(즉, AbstractCommand를 상속받은 클래스)를 파라미터로 넘겨 받고 그 command를 실행한다. 여기서 command.execute() 메소드를 실행하는 부분을 살펴보자.
if (command.execute()) {
addToHistory(command);
} else { // execute()가 false를 리턴한 경우, 즉 명령어가 올바르게 실행되지 않은 경우
// 명령어가 실패했다는 것을 알린다.
}
addToHistory(command);
} else { // execute()가 false를 리턴한 경우, 즉 명령어가 올바르게 실행되지 않은 경우
// 명령어가 실패했다는 것을 알린다.
}
여기서 AbstractCommand의 execute() 메소드는 boolean을 리턴하며(기억이 안 난다면, 앞에 있는 AbstractCommand 클래스의 소스 코드를 살펴보라), 만약 true를 리턴하며 addToHistory() 메소드를 사용하여 history 필드에 추가하고, false를 리턴하면 명령어가 실패했음을 알린다.
CommandManager 클래스에서 아직까지 설명하지 않은 것이 있다면 Undo와 Redo이다. Undo와 Redo는 인터페이스이며, 그 정의는 단순히 다음과 같다.
interface Undo {
}
interface Redo {
}
}
interface Redo {
}
즉, Undo와 Redo는 Serializable 인터페이스와 마찬가지로 단순히 이 두 인터페이스를 implements 한 클래스의 타입이 Redo와 Undo라는 것을 보여준다. '명령 취소'와 관련된 명령어 클래스는 UndoCommand 이며 다음과 같다.
class UndoCommand extends AbstractCommand implements Undo {
public UndoCommand() {
manager.execute(this);
}
public boolean execute() { return false; }
public boolean undo() { return false; }
}
public UndoCommand() {
manager.execute(this);
}
public boolean execute() { return false; }
public boolean undo() { return false; }
}
RedoCommand 역시 UndoCommand와 비슷하다. 실제로 사용자가 '명령 취소'를 클릭하면 이를 처리하는 이벤트 리스너는 단순히 다음과 같은 코드를 실행하면 된다.
new RedoCommand();
커맨드 패턴을 사용함으로써 사용자로부터 요청을 받는 객체(즉, 메뉴나 툴바)와 실제로 사용자가 필요로 하는 기능을 구현한 객체를 완전히 분리할 수 있게 되었다. 따라서 사용자로부터 요청을 받는 객체는 실제 내부 로직이 어떻게 되는 지 알 필요가 없으며, 내부 로직을 구현한 명령어 객체 역시 사용자로부터 어떻게 요청을 받는 지 알 필요가 없다. 즉, 이 두 객체 사이에 의존관계가 없는 것이다. 따라서 요청을 받는 객체를 변경할 필요 없이 손쉽게 새로운 명령어 객체를 추가할 수 있다.
또 다른 구현 방법
여기서 AbstractCommand가 추상 클래스로 선언된 것은 static final 필드로 CommandManager를 갖고 있기 때문이다. 실제로 명령어 객체를 순서대로 저장하고 명령어 객체의 실행을 취소하는 것 등의 작업이 필요하지 않다면 CommandManager가 필요 없을 것이다. 이런 경우 추상 클래스 대신 인터페이스를 사용하여 AbstractCommand를 대신할 수 있다. 만약 AbstracCommand 대신 사용할 인터페이스가 CommandIF 라고 한다면, CommandIF 인터페이스는 다음과 같이 정의될 것이다.
public interface CommandIF {
public boolean execute();
}
public boolean execute();
}
이제, 명령어 클래스들은 AbtractCommand를 상속받는 대신 CommandIF 인터페이스를 구현할 것이다. 예를 들어, PasteCommand 클래스의 경우 다음과 같이 바뀔 것이다.
public class PasteCommand implements CommandIF {
.....
public PasteCommand(Document document, int position) {
this.document = document;
this.postion = position;
// CommandManager와 관련된 부분이 없다!!
}
public boolean execute() {
.....
}
}
.....
public PasteCommand(Document document, int position) {
this.document = document;
this.postion = position;
// CommandManager와 관련된 부분이 없다!!
}
public boolean execute() {
.....
}
}
이제, PasteCommand 클래스를 사용하는 PasteListener 클래스의 actionPerformed() 메소드는 다음과 같이 변경된다.
public class PasteActionListener implements ActionListener {
public void actionPerformed(ActionEvent e) {
// 현재 document와 position을 구한다.
.....
CommandIF command = new PasteCommand(document, position); // 명령어 객체 생성
command.execute(); // 명령어 실행
}
}
public void actionPerformed(ActionEvent e) {
// 현재 document와 position을 구한다.
.....
CommandIF command = new PasteCommand(document, position); // 명령어 객체 생성
command.execute(); // 명령어 실행
}
}
직접 execute() 메소드를 호출해주는 것을 알 수 있다.
CommandFactory를 이용하여 객체간의 관련성 감소시키기
앞에 있는 PasteActionLister 클래스는 AbstractCommand 클래스를 사용하는 경우나 CommandIF 인터페이스를 사용하는 경우 모두 actionPerformed() 메소드에서 반드시 PasteCommand 클래스를 사용하고 있다. 이제 CopyActionListener 클래스를 생각해보자. 이 클래스는 CopyCommand 클래스를 사용한다는 것을 제외하면 PasteActionListener 클래스와 완전히 동일하다. CutActionListener 역시 마찬가지이다. 그렇다면 어떻게 하면 될까? 가장 먼저 생각할 수 있는 것이 이러한 ActionListener를 다음과 같이 하나로 묶어주는 것이다.
public class CommonActionListener implements ActionListener {
public void actionPerformed(ActionEvent e) {
MenuItem mi = (MenuItem)e.getSource();
CommandIF command = null;
if (mi.getLabel().equals("복사") ) {
command = new CopyCommand(...);
command.execute();
} else if (mi.getLabel().equals("붙여넣기") ) {
command = new PasteCommand(...);
command.execute();
} else if (mi.getLabel().equals("잘라내기") ) {
command = new CutCommand(...);
command.execute();
}
}
}
public void actionPerformed(ActionEvent e) {
MenuItem mi = (MenuItem)e.getSource();
CommandIF command = null;
if (mi.getLabel().equals("복사") ) {
command = new CopyCommand(...);
command.execute();
} else if (mi.getLabel().equals("붙여넣기") ) {
command = new PasteCommand(...);
command.execute();
} else if (mi.getLabel().equals("잘라내기") ) {
command = new CutCommand(...);
command.execute();
}
}
}
물론, 이것만으로도 MenuItem과 실제 명령어 객체(CommandIF 인터페이스를 구현한 객체 또는 AbstractCommand 추상클래스를 상속받은 객체)와의 관련성을 없앤 채로 CommonActionListener를 사용하여 이 두 객체를 연결시킬 수 있다. 이를 좀더 객체지향적으로 접근한 것이 바로 CommandFactory 클래스이다. CommandFactory 클래스는 CommonActionListener 클래스의 actionPerformed() 메소드에서 if .. else .. 부분을 처리해주며 코드 형태는 다음과 같다.
public class CommandFactory {
public CommandIF createCommand(String key) {
CommandIF command = null;
if (key.equals("복사") ) {
command = new CopyCommand(...);
} else if (key.equals("붙여넣기") ) {
command = new PasteCommand(...);
} else if (key.equals("잘라내기") ) {
command = new CutCommand(...);
}
return command;
}
}
public CommandIF createCommand(String key) {
CommandIF command = null;
if (key.equals("복사") ) {
command = new CopyCommand(...);
} else if (key.equals("붙여넣기") ) {
command = new PasteCommand(...);
} else if (key.equals("잘라내기") ) {
command = new CutCommand(...);
}
return command;
}
}
실제로, CommandFactory 클래스는 팩토리(Factory) 패턴을 간단하게 구현한 것으로서 팩토리 패턴에 대한 자세한 내용은 패턴 관련 서적을 참조하기 바란다. 이제 CommandFactory 클래스를 사용하면 CommonActionListener는 다음과 같이 간단하게 바뀌게 된다.
public class CommonActionListener implements ActionListener {
private CommandFactory factory = new CommandFactory();
public void actionPerformed(ActionEvent e) {
MenuItem mi = (MenuItem)e.getSource();
CommandIF command = factory.getCommand(mi.getLabel());
command.execute();
}
}
private CommandFactory factory = new CommandFactory();
public void actionPerformed(ActionEvent e) {
MenuItem mi = (MenuItem)e.getSource();
CommandIF command = factory.getCommand(mi.getLabel());
command.execute();
}
}
CommonActionListener 클래스의 소스 코드가 간단해지긴 했지만, 왜 굳이 CommandFactory 클래스를 생성하는 지 의아해 할지도 모르겠다. 위만 보더라도 CommonActionListener에서 모든 걸 다 처리할 수 있기 때문이다. 하지만, 메뉴 뿐만 아니라 단축키를 통해서 사용자들에게 "복사", "잘라내기", "덧붙이기" 기능을 제공하길 원한다고 가정해보자. 이 경우, CommandFactory 객체를 사용하지 않는다면 키보드 이벤트를 처리하는 클래스는 다음과 같은 형태를 취할 것이다.
public class ShortCutListener implements KeyListener {
public void keyReleased(KeyEvent e) {
int keyCode = e.getKeyCode();
int modifier = e.getModifiers();
CommandIF command = null;
if (keyCode == .. && modifier ... ) {
command = new CopyCommand(...);
} else if (...) {
command = new CopyCommand(...);
} else {
command = new CopyCommand(...);
}
command.execute();
}
....
}
public void keyReleased(KeyEvent e) {
int keyCode = e.getKeyCode();
int modifier = e.getModifiers();
CommandIF command = null;
if (keyCode == .. && modifier ... ) {
command = new CopyCommand(...);
} else if (...) {
command = new CopyCommand(...);
} else {
command = new CopyCommand(...);
}
command.execute();
}
....
}
ShortCutListener 클래스가 CommonActionListener 클래스와 거의 비슷한 것을 알 수 있다. 즉, 코드가 중복되는 것이다. 이 경우 Command 클래스가 추가되면 ShortCutListener 클래스와 CommonActionListener가 모두 영향을 받게 된다. 또한, CopyCommand 클래스 대신 Copy2Command 클래스를 사용하는 경우에도, 이 두 Listener 클래스는 영향을 받게 된다. 반면에 CommandFactory 객체를 사용하게 되면, Command 클래스가 추가되거나 변경되거나 삭제된다고 해도 오직 CommandFactory 클래스만 영향을 받게 된다. 즉, 두 Listener 클래스는 오직 CommandIF 인터페이스와 CommandFactory 클래스만 알면 될 뿐, 실제 Command 객체들에 대한 자세한 내용을 알 필요가 없는 것이다. 다시 말해서, 객체간의 관련성이 감소하게 된다. (객체 지향적인 설계에서 객체 사이의 관련성을 줄이는 것은 매우 중요하다!)
결론
지금까지 커맨드 패턴의 구현에 대해서 알아보았다. 커맨드 패턴을 통해서 사용자들은 명령어를 입력받는 객체가 그 명령어의 실제 구현에 대해서 알 필요 없이 명령어 객체를 사용하기만 하면 되었다. 또한, 명령어를 입력받는 객체와 처리하는 명령어 객체 사이에서 커맨드 팩토리를 사용함으로써 객체 사이의 관련성을 최대한 줄일 수 있게 되었다. 실제로 커맨드 패턴의 핵심은 명령어를 처리하는 부분을 객체로 캡슐화 함으로써 실제 내부 구현을 다른 객체들로부터 분리하는 것에 있다.
관련링크: