1. Design Patterns

패턴이란?

• 문제에 관한 솔루션

 

왜 사용해야할까?

• 객체지향 Software와 재사용가능한 소프트웨어 설계는 매우 힘들고 경험 많은 설계자는 이전에 일하면서 증명된 솔루션을 재사용함
• 패턴에 관한 지식을 가지고 있다면 더 유연하고 재사용가능한 Software 개발할 수 있음
• 개발자들 사이에서 좋은 커뮤니케이션에 대한 도구 (common language)
• 누군가 이미 너의 problem을 해결하여 만든 패턴!
  
  

디자인 패턴의 3가지 파트

1. context : 패턴을 적용하고자 하는 상황 (자주 발생)
2. problem : 이루고자 하는 목표 또는 context에서 발생하는 제약사항
3. solution : 설계 패턴에서 제시하는 해결책
   • 컴포넌트 구조와 그 관계
   • 런타임의 메커니즘 

  ※ 예시 : Iterator Pattern

        - Context : 객체를 담고 있는 collection이 있음

        - Problem : collection 내의 element를 하나씩 꺼내고 싶은데 그때 collection의 implementation은 보여지고 싶지 않음

        - Solution : iteration을 가진 독립된 class를 만들어서 캡슐화

 

GoF Patterns 분류

• 목적에 따라 분류
  1. 생성(Creational) : 생성 작업을 클라이언트가 아닌 다른 객체가 담당. new라는 연산자 없이 객체 생성 가능
  2. 구조(Structural) : 객체를 조합해서 더 큰 객체를 만들고 싶거나 조직화하고 싶은 경우
  3. (Behavioral) : 책임을 어떤 클래스에 줘야하는가? 클래스 간의 static한 관계나 커뮤니케이션 방식을 정의
• Scope에 따라 분류
  1. Class : 클래스의 관계만을 이용
  2. Object : 객체들의 관계만을 이용

 

디자인 패턴의 주요 구성 요소

1. 패턴명 : 디자인 의도를 간결하게 전달할 수 있음
2. Intent : 이 패턴의 의도
3. Problem : 패턴이 해결해야할 문제
4. Solution : 추상적인 설명. 어떤 역할의 클래스가 있어야 하고 그들의 관계는 어떤지
5. Participants and collaborators : 패턴에 참여하는 개체들
6. Consequences : 패턴 사용에 의한 장단점 (재사용성, 확장성 등)
7. Implementation : 특정 플랫폼, 언어에 대한 예시
8. Generic structure : UML 등을 통해 패턴의 일반적인 구조 설명

 

 

패턴의 Level

1. Architectural pattern
   • SW의 구조적인 스키마를 정할 때 사용하는 패턴
   • 잘 정의된 서브시스템, 그들의 책임 등을 가이드함
   • ex) MVC 패턴
2. Design pattern (:= micro-architecture pattern)
   • 서브시스템 또는 컴포넌트, 또는 그들의 관계를 정제
   • 전반적인 시스템 구조에 영향을 미치지 않음. 
   • ex) Observer 패턴
3. Coding pattern(or programming idiom)
   • 특정 언어에 종속되어있는 패턴
   • ex) Counter Pointer
     
     
     
     

첫 번째 문제 - 3번, 두 번째 문제 - 4번