Command pattern?

모든 글은 유튜브 얄팍한 코딩사전에 출처를 두고있습니다.

이번에는 Command(명령) 패턴에 대해 공부해보자.

Command?

Command 패턴은 간단하게 정의하자면 아래와 같다.

여러 객체에 명령을 내릴 때 객체에 대한 의존성을 낮추는 것!

어떻게 보면 Strategy 패턴과 굉장히 유사하다고도 생각할 수 있다.
Strategy 패턴이 동일한 작업에 대해 다양한 전략으로 해당 작업을 수행할 때,
해당 작업을 수행하는 사람과 다양한 전략 간의 의존성을 낮추었었다.

유사하게 Command 패턴은 동일한 작업이 아닌 여러 작업에 대한 것이다.
여러 작업에 대해서 각 작업들과 명령자 간의 의존성을 낮추는 것이다!

사용하는 이유?

예를 들어 구글의 OKgoogle에 명령을 내린다고 한 번 생각해보자.

아래의 사진과 같이 OKgoogle 클래스의 talk() 함수가 있다.
사용자가 OKgoogle에게 말을 걸 수 있는 함수이다.

이 때 위와 같이 가전 기기의 동작을 talk() 함수에서 직접 접근해야 한다면 어떨까?
우선 가전 기기가 추가될 때마다 우리는 talk() 함수를 변경해주어야 한다.
또한 저런식으로 자꾸 붙이다 보면 OKgoogle 클래스가 굉장히 복잡해질 것이다.
OCP 원칙이 위반되었으며, 유지 보수를 하기 굉장히 힘들어질 것이 눈에 보인다..

그렇다면 어떻게? interface를 이용해서 의존성을 떨어트리자!

구현

위와 같이 Command interface를 선언하여 의존성을 떨어트릴 수 있다.
execute 함수를 하나 만들어 놓고, 각종 명령 클래스들을 만든다.
해당 명령 클래스들은 Strategy 패턴과 동일하게 부품의 역할을 한다.
execute 함수를 override 해서 실제 기기의 동작을 실행하도록 한다.

위와 같이 구현을 하게 되면, 더 이상 talk() 함수는 커질 필요가 없다!

위와 같이 OKgoogle 클래스를 구현할 수 있다.
이제 해당 클래스는 더 이상 변경될 걱정이 없다!

장단점

기본적으로 Command 패턴은 아래와 같은 장점이 있다.

• 작업 수행 객체와 요청 객체가 분리된다.
  • 이는 곧 SRP를 준수하기에 용이해진다.
• 작업 수행 객체만 변경하며, 실제 요청 객체에 대한 수정은 없다.
  • 이는 곧 OCP를 준수하기에 용이하다.

단점으로는 아래와 같은 특징이 있다.

• 명령의 종류가 늘어날 수록 코드가 점점 복잡해진다.
  • 설계 구조가 복잡해져, 이해하기 어려워진다.