디자인 패턴(Design Pattern)

디자인 패턴이란?

 디자인 패턴이란 프로그래밍 할 때에 문제를 해결하고자 코드의 구조들을 일정한 형태로 만들어 재이용하기 편리하게 만든 일정한 패턴이다. 즉, 구조적인 문제를 해결하는 방식을 이름을 붙여서 재이용하기 좋은 형태로 정리해둔 것이다. 사용하는 목적은 SW 재사용성, 호환성, 유지보수성을 보장함에 있다. 일반적으로 문제가 있어보이는 코드 구조 및 패턴을 'Design Smells' 스파게티 코드라고 한다. 이것들은 아래와 같다.

1. Rigidity (경직성)

• 시스템이 변경하기 어렵고 하나의 변경을 위해서 다른 것들을 변경 해야할 때 경직성이 높다. 경직성이 높다면 non-critical한 문제가 발생했을 때 관리자는 개발자에게 수정을 요청하기가 두려워진다.

2. Fragility (취약성)

• 취약성이 높다면 시스템은 어떤 부분을 수정하였는데 관련이 없는 다른 부분에 영향을 준다. 수정사항이 관련되지 않은 부분에도 영향을 끼치기 때문에 관리하는 비용이 커지며 시스템의 credibility 또한 잃는다.

3. Immobility (부동성)

• 부동성이 높다면 재사용하기 위해서 시스템을 분리해서 컴포넌트를 만드는 것이 어렵다. 주로 개발자가 이전에 구현되었던 모듈과 비슷한 기능을 하는 모듈을 만들려고 할 때 문제점을 발견한다.

4. Viscosity (점착성)

• 점착성은 디자인 점착성과 환경 점착성으로 나눌 수 있다.
• 시스템에 코드를 추가하는 것보다 핵을 추가하는 것이 더 쉽다면 디자인 점착성이 높다고 할 수 있다. 예를 들어 수정이 필요할 때 다양한 방법으로 수정할 수 있을 것이다. 어떤 것은 디자인을 유지하는 것이고 어떤 것은 그렇지 못할 것이다.
• 환경 점착성은 개발환경이 느리고 효율적이지 못할 때 나타난다. 예를 들면 컴파일 시간이 매우 길다면 큰 규모의 수정이 필요하더라도 개발자는 recompile 시간이 길기 때문에 작은 규모의 수정으로 문제를 해결하려고 할 것이다.

이와 같은 문제들이 있었기에 디자인 패턴들이 만들어지게 되었다. 

 

---

디자인 패턴의 장점

1. 코드 재사용성의 향상 : 잘 정의된 패턴을 사용함으로써 개발자들은 반복적인 작업을 줄이고, 이미 검증된 솔루션을 활용해 효율성을 높일 수 있다. 
2. 유지보수 용이성 : 명확하고 일관된 설계 접근 방식을 채택함으로써, 코드는 더 읽기 쉽고 이해하기 쉬워진다. 
3. 팀 커뮤니케이션 개선 : 공통된 용어와 개념을 사용함으로써, 팀원들은 더 빠르고 정확하게 아이디어를 전달하고 이해해 프로젝트의 진행 속도가 빨라진다.
4. 효과적인 문제해결 : 디자인 패턴은 복잡한 문제를 구조화하고 해결하는 데 도움을 준다. 각 패턴은 특정 문제 유형에 최적화된 해결책을 제공하며, 이를 통해 개발자들은 효과적이고 신속하게 문제에 접근할 수 있습니다.
5. 장기적인 시스템 안정성 : 검증된 패턴의 사용은 시스템의 장기적인 안정성과 신뢰성을 보장한다. 이는 소프트웨어가 시간이 지남에 따라 변경되고 확장될 때 중요한 이점을 제공하게 된다.

디자인 패턴의 단점

 

1. 객체지향 설계/구현 위주로 사용된다.
2. 초기 투자 비용의 부담이 든다.

---

디자인 패턴의 기본 원칙 (SOLID 법칙)

디자인 패턴은 효율적인 SW설계와 구현을 위해 기본 원칙에 기반하여 구축된다. 대부분의 디자인 패턴들은 객체 지향 프로그래밍의 원칙에 깊이 뿌리를 두고 있음으로, 객체 지항의 다섯가지 설계원칙에 맞춰 설계된다. 

1. 단일 책임 원칙 (Single Responsibility Principle): 각 클래스는 하나의 기능 또는 책임만을 가져야 합니다. 이는 코드의 복잡성을 줄이고, 유지보수를 용이하게 합니다.
2. 개방-폐쇄 원칙 (Open-Closed Principle): 소프트웨어 엔티티는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 합니다. 이는 기존 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있도록 합니다.
3. 리스코프 치환 원칙 (Liskov Substitution Principle): 파생 클래스는 기반 클래스의 기능을 손상시키지 않으면서 대체 가능해야 합니다.
4. 인터페이스 분리 원칙 (Interface Segregation Principle): 클라이언트는 사용하지 않는 메소드에 의존하도록 강제되어서는 안 됩니다. 더 작고 구체적인 인터페이스로 분리하는 것이 바람직합니다.
5. 의존성 역전 원칙 (Dependency Inversion Principle): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다.

---

디자인 패턴의 종류

생성 패턴, 구조 패턴, 행동 패턴 세가지로 나뉜다. 

1. Creational 생성 패턴 : 객체의 생성에 관련된 패턴이다. 특정 객체가 생성되어도 프로그램의 구조에 큰 영향을 받지 않는 유연함을 갖는다.
   • 추상 팩토리
   • 팩토리
   • 빌더
   • 프로토타입
   • 싱글톤
2. Structural 구조 패턴 : 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴이다.  객체를 묶어 새로운 기능 제공한다.
   • 어댑터
   • 브릿지
   • 컴포짓
   • 데코레이터
   • 파사드
   • 플라이웨이트
   • 프록시
3. Behavioral 행위 패턴 : 클래스나 객체 간의 알고리즘이나 책임 분배에 관련된 패턴이다. 한 객체가 수행할 수 없는 작업을 어떻게 분배할지, 그 과정에서 어떻게 결합도를 낮게 유지할지를 목표로 한다. 
   • 책임 체인
   • 커맨드
   • 인터프리터
   • 이터레이터
   • 중재자
   • 메멘토
   • 옵저버
   • 상태
   • 전략
   • 템플릿 메소드
   • 방문자

각각에 대해서는 다음 포스트에서 자세히 설명하겠다.