3. 템플릿 메소드 패턴 VS 전략패턴

코딩을 하다 보면 주먹구구식으로 코드를 칠 때가 많았습니다. 예로 if-else문과 try/catch문 이 있습니다. 코드가 비슷한 부분이 있다면 Copy & Paste로 작성을 하기도 하고 여러 변수를 써가며 메모리를 낭비하기도 했습니다. 하지만 코드의 양이 증가함에 따라 복잡해지고, 오류도 많아지고 실수할 가능성도 높아졌죠. 이러한 문제를 지양하기 위해 SOLID 원칙 중 하나인 OCP 원칙을 적용한 템플릿 메소드 패턴과 전략 패턴에 대해 알아보려고 합니다.

 

▷ if - else문의 문제점

• 메소드의 변경, 확장이 될수록 코드의 복잡성 증가
• 복잡해질수록 오류 발생 원인 파악의 어려움
• 실수할 가능성 증가

→ 유지보수의 어려움이 있다.

 

SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전

OCP(Open Closed Principle) 원칙

• 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 대해서 개방되어야 하지만 변경에 대해서는 폐쇄되어야 한다

컴퓨터 프로그래밍에서 SOLID란 객체 지향 프로그래밍 및 설계의 다섯 가지의 기본 원칙으로, 유지보수와 확장이 쉬운 시스템을 만들고자 할 때 적용하는 원칙들입니다. 그 중에서 템플릿 메소드 패턴과 전략패턴과 연관이 있는 OCP 원칙은

Open Closed Principle의 약자로 개방 폐쇄 원칙이라고 합니다. 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 대해서 개방되어야 하지만 변경에 대해서는 폐쇄되어야 한다는 의미를 가집니다. 즉, 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 합니다. OCP를 적용시키기 위해서는 바로 템플릿 메소드 패턴과 전략 패턴에 대해 알아야 합니다.

 

템플릿 메소드 패턴(Template Method Pattern)

토비의 스프링 中

템플릿 메소드 패턴이란 : 상속의 개념(is-a 관계)이 있는 상위 클래스와 하위 클래스의 구조를 가진다. 상위 클래스에서는 추상 메소드를 통해 기능의 골격을 제공하고, 하위 클래스에서는 구체적인 메소드를 작성한다. 즉, 변하지 않는 부분은 상위 클래스에 두고 특정한 작업을 처리하는 부분을 하위 클래스에서 구체화(오버라이드)시켜 동작시킨다.  

 

장점

• 중복코드를 줄일 수 있음
• 핵심 로직의 관리가 편리함
• 확장성과 재사용성을 높일 수 있음

단점

• 추상 메소드가 많아지면서 클래스간의 관리가 복잡해짐
• 클래스 간의 관계와 코드가 엉킬 수 있음

상속의 개념을 적용하다 보니 상위 클래스와 하위 클래스의 관계가 매우 밀접합니다. 따라서 상위의 내용이 변경이 되면 하위의 내용도 바뀌게 됩니다.

 

전략 패턴 (Strategy Pattern)

토비의 스프링 中

전략이란 : 어떤 목적을 달성하기 위해 일을 수행하는 방식 - 비즈니스 규칙, 문제를 해결하는 알고리즘 등

 

전략 패턴이란 : 컴포지션(has-a)관계에 있는 인터페이스를 활용하여 전략 패턴을 구현한다. 확장에 해당하는 변하는 부분을 별도의 클래스로 만들어 추상화된 인터페이스를 통해 위임하는 방식이다. 즉, 클라이언트가 전략을 생성해 전략을 실행할 컨텍스트에게 주입하는 패턴.

 

특징

• 디자인 패턴의 꽃
• 전략을 쉽게 바꿀 수 있도록 해주는 디자인패턴
• 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴
• 새로운 기능의 추가가 기존의 코드에 영향을 미치지 못하게 하므로 OCP를 만족

Context
- 전략 패턴을 이용하는 역할을 수행
- 객체 주입을 통해 필요에 따라 동적으로 구체적인 전략을 바꿀 수 있도록 한다.(DI나 setter)

Strategy
- 인터페이스나 추상클래스로 외부에서 동일한 방식으로 알고리즘을 호출하는 방법을 명시한다.

ConcreteStrategy
-전략패턴에서 명시한 알고리즘을 실제로 구현한 클래스

 

장점

• 컨텍스트의 코드의 변경없이 새로운 전략 추가 가능
• 핵심 로직의 관리가 편리함
• 확장성과 재사용성을 높일 수 있음
• 새로운 전략을 추가하기 쉬움

단점

• 모든 상황에서 전략패턴을 사용하는 경우는 옳지 않음
• Strategy 객체와 Composition 클래스 객체 사이에 통신 오버헤드가 발생할 수 있음 -> 특정 ConcreteStrategy는 해당 인터페이스를 통해 들어온 모든 매개변수를 사용하지 않는데도 전달 받아야 할 때가 생길 수 있다.
• 객체 수의 증가