1. ⭕Design Pattern⭕

1. 정의:

디자인 패턴(Design Pattern): 방식을 통해 소프트웨어 설계에서 얻은 세세한 경험들을 기록해 놓도록 하는 것
-패턴 "어떤 상황의 문제에 대한 해법"

-개발자들이 개발을 하면서 프로그램의 유연성과 확장성과 관련된 비슷한 문제들을 마주하며, 이 문제들은 풀기 위해서 많은 시간이 소요된다. 이 문제점을 해결하기 위한 방법이 소프트웨어 디자인 패턴이다.

-개발을 하면서 생길 수 있는 문제를 유형별로 나눠서 해결책을 제시한다.
프로그래밍 전문가들은 디자인 패턴을 장황하게 설명하지 않고, 디자인 패턴 그 자체의 이름만을 말해서 프로그램 설계의 복잡도를 줄인다.또 의사소통에 편리함을 준다.

2. 디자인 패턴 기술하기

1) 패턴 이름과 분류(Pattern Name and Classification)
하나의 패턴에 붙은 이름은 그 자체가 핵심을 간결하게 전달해 준다. 개발자가 설계를 할 때 직접 사용할 단어이기 때문에 좋은 이름은 패턴의 생명이다. 패턴의 분류는 패턴의 구성방식을 반영한다.

2) 의도(Intent)
이 디자인 패턴은 무엇을 하는 가? 의도와 논리적인 근거가 무엇인가? 어떤 특정한 문제나 이슈를 해결하기 위한 것일까요? 라는 질문에 간결한 답을 제시하는 부분이다.

3) 다른 이름(Also Known As)
이 패턴을 다르게 부르는 이름이 있다면 그것을 제시 한다.

4) 동기(Motivation)
설계 문제를 제시하고, 패턴안에서 클래스나 객체 구조가 어떻게 문제를 해결하는 지 설명해주는 일종의 시나리오 이 시나리오는 패턴에 대한 좀 더 추상화된 설명을 이해할 수 있게 도와 준다.

5) 활용성(Applicability)
해당 패턴을 어떤 상황에 적용할 수 있을까? 패턴이 문제로 삼는 잘못된 설계에는 무엇일까? 이 상황을 어떻게 파악할 수 있을까?

6) 구조(Structure)
객체 모델링 기법(Object Modeling Technique)1에 기반을 둔 표기법을 이용하여 해당 패턴에서 쓰는 클래스들을 시각적으로 나타낸다 또한 객체 사이에 오가는 요청과 협력 관계의 순차를 표현하기 위해서 상호작용 다이어그램을 사용했다.

7) 참여자(Participant)
주어진 패턴을 구성하고 책임을 수행하는 클래스나 객체들을 설명한다.

8) 협력방법(Collaboration)
참여자들이 작업을 수행하기 위한 참여자들 간의 협력관계를 정의한다.

9) 결과(Consequence)
이 패턴이 자신의 목표를 어떻게 지원할까? 이 패턴을 이용한 결과는 무엇이고 장단점은 무엇? 이 패턴을 사용하면 시스템 구조의 어떤 면을 독립적으로 다양화 시킬수 있을까?

10) 구현(Implementation)
패턴을 구현할 때 주의해야 할 함정, 힌트, 기법등은 무엇? 특정 언어에 국한된 특이사항은 무엇?

11) 예제코드(Sample Code)
주어진 패턴을 실제로 C++나 스몰토크를 이용해서 어떻게 구현할 수 있는가를 보여주는 코드

12) 잘 알려진 사용 예(Known Use)
실제 시스템에서 찾아볼 수 있는 패턴들의 예로서 서로 다른 개발 분야에서는 쓰는 예제를 두 가지 이상 포함 시켰다

13) 관련 패턴(Related Pattern)
이 패턴과 밀접하게 관련된 다른 패턴들은 무엇? 이들의 중요한 차이점은 무엇? 어떤 다른 패턴에 이 패턴이 사용되어 질까?

1. Behavioral Patterns

:객체간의 공통된 커뮤니케이션 패턴을 알아내기 위한 디자인 패턴
-> 이 디자인 패턴으로 커뮤니케이션을 수행할 때 유연성을 높일 수 있다.

-어떤 처리의 책임을 어느 객체에 할당하거나,
알고리즘을 어떤 객체에 정의하는게 좋을지 정하는 패턴!

1. Observer

Observer 패턴은 객체가 상태에 대한 변경 사항을 게시할 수 있도록 하기 위해 사용된다. 다른 객체들은 모든 변경 사항을 즉각적으로 알기 위해 구독하고 있다.
=> 변화하는 데이터에 반응하는 프로그램 = 리액티브 프로그램
(이전에는 명령형 프로그램)

-옵저버 패턴은 리액티브 프로그래밍의 기초가 된다. 데이터의 변화를 관찰하며, 관찰한 변화를 필요한 곳에 알린다.
-발행자(변화하는 데이터), 구독자(데이터의 변화를 관찰해 필요한 동작 수행)로 구성된다.

var data: String by Delegates.observable(
	initialValue="",
    onChange = { property: KProperty<*>, oldValue: String, newValue: String ->
    println("Data Changed >> from ${oldValue} to ${newValue}")
    }
)

//onChange의 람다식 = 구독자, data = 발행자

2. Strategy

Strategy 패턴은 작업 처리 과정에서 필요에 따라 선택할 수 있는 교체가 가능한 알고리즘을 만드는 데에 사용된다.
-하나의 객체가 다양하면서 변화하는 역할을 할 때 사용된다.

ex) 이메일을 보낼 때, 이메일에는 시작말과 맺음말이 들어가며, 사람마다 이를 다르게 설정할 수 있어야 한다.

class MessageConverter(private var messageGenerateStrategy: MessageGenerateStrategy){
	fun convert(string: String): String{
    	return messageGenerateStrategy.process(string)
    }
    //MessageGenerateStrategy의 전략에 따라 다르게 코드를 만들어낸다.
    fun setStrategy(messageGenerateStrategy: MessageGenerateStrategy) {
 	this.messageGenerateStrategy = messageGenerateStrategy
    }
    //MessageGenerateStrategy를 동적으로 바꾼다.
}

fun main(){
	val message = "Hello"
    val fromIOSStrategy = MessageGenerateStrategy.Etc { message : String -> "${message} : Written from IOS" }
    val messageConverter = MessageConverter(fromIOSStrategy)
    
    println(messageConverter.convert(message))
    //Hello : Written from IOS
    
    val messageHeaderStrategy = MessageGenerateStrategy.AttachHeader("Message : ")
    messageConverter.setStrategt(messageHeaderStrategy)
    
    println(messageConverter.convert(message))
    //Message : Hello

2. Creational Patterns

생성 패턴(creational pattern)은 인스턴스를 만드는 절차를 추상화하는 패턴입니다. 이 범주에 해당하는 패턴은 객체를 생성 합성하는 방법이나 객체의 표현 방법과 (소프트웨어) 시스템을 분리해 줍니다.

1) 클래스 생성 패턴 - 인스턴스로 만들 클래스를 다양하게 만들기 위한 용도로 상속을 사용함
2) 객체 생성 패턴 - 인스턴스화 작업을 다른 객체에게 떠넘김
생성 패턴의 특징

생성 패턴은 시스템이 어떤 구체 클래스를 사용하는 지에 대한 정보를 캡슐화합니다. 생성 패턴은 이들 클래스의 인스턴스들이 어떻게 만들고 어떻게 서로 맞붙는지에 대한 부분을 완전히 숨깁니다. 생성 패턴을 이용하면 무엇이 생성되고 누가 이것을 생성하며, 이것이 어떻게 생성되는지, 언제 생성할 것인지 결정하는 데 유연성을 확보할 수 있게 됩니다.

1. Abstract Factory 추상 팩토리
:상세화된 서브클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터페이스를 제공합니다

용도:

• 객체가 생성되거나 구성, 표현되는 상식과 무관하게 시스템을 독립적으로 만들고자 할 때

-관련된 제품 객체들이 함께 사용되도록 설계되었고, 이부분에 대한 제약이 외부에도 지켜지도록 하고 싶을 때

2. Builder
-많은 변수(인자)를 가진 객체 생성을 대신 해준다.
-사용자가 이 과정에서 커스텀 가능하다. (팩토리 패턴은 불가능하다.)
-가독성이 좋다. (각 인자의 의미를 파악하기 쉽다)
-필수 매개변수, 선택적 매개변수를 통해 객체를 생성할 때보다 유연하기 활용할 수 있다.

3. Factory Method
-공장처럼 특정 객체를 만들어서 반환하는 경우

Factory Method Pattern vs Abstract Factory Pattern

• 객체 1개 생성 vs 객체 여러개 생성
  추상 팩토리 패턴은 연관된 객체로 이루어진 여러 종류의 객체를 생성하기 위해 사용된다!
• 객체의 종류를 결정 vs 팩토리의 종류를 결정
• 과정(Process) 중심 vs 종류(Platform) 중심

3. Structral Patterns

1. Composite
-컴포짓 패턴은 클라이언트가 복합 객체나 단일 객체를 동일하게 취급하는 것을 목적으로 한다. 컨테이너와 내용물을 동일시 한다고 보면 된다.

=> 즉, 상하관계가 있는 객체들을 동일하게 취급할 수 있도록 하는 패턴.

모든라이더들배달()
    정규직라이더 정규직라이더 = new 정규직라이더()
    파트타임라이더 파트타임라이더 = new 파트타임라이더()
    배민커넥트라이더 배민커넥트라이더 = new 배민커넥트라이더()

    정규직라이더.배달()
    파트타임라이더.배달()
    배민커넥트라이더.배달()

    ...

=> composite pattern 활용

모든라이더들배달()
    for (라이더 : 라이더리스트)
        라이더.배달()

-개수와 상관없이 일관적으로 객체를 사용할 수 있고, 코드가 단순해진다!
-새로운 객체를 추가하는 것이 용이하다.
-단, 여러 종류의 객체를 일반화했기 때문에, 특정 객체에 제약 조건을 줄 수 없다.

=> 객체의 구성, 개별 객체 간의 차이를 무시할 때 써야 한다.
디자인을 지나치게 일반적으로 만들 수 있다.

4. Decorator

• 데코레이터 패턴이란 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다.
  -같은 클래스의 다른 객체 동작에 영향을 주지 않고, 개별 객체에 동작을 동적으로 추가할 수 있다.
  
  위와 같이 사용자에게 이벤트를 알리는 라이브러리가 있다고 가정해보자.
  이 때, 알림을 이메일 이외에 SMS, 페이스북 등으로 하고 싶다면,
  Notifier 클래스를 확장하고, 추가 알림 메서드를 하위 클래스에 넣는다.
  
  그런데 누군가는 알림을 동시에 쓰고 싶다고 한다면!
  
  클래스를 확장해야겠다는 생각이 든다.
  하지만 상속은 정적이기때문에, 전체 객체를 다른 하위클래스에서 생성된 다른 객체로만 바꿀 수 있고, 하위 클래스는 하나의 상위 클래스만 가질 수 있다.
  => 데코레이터 패턴을 쓰면, 사용자가 구조를 변경하지 않고, 기존 객체에 새 기능을 추가할 수 있다.
  데코레이터 패턴은 기능을 확장하기 위해 상속 대신 구성을 사용한다.

공부할수록 디자인 패턴들이 명확히 구분되어 있지 않고,
용도나 기능이 중첩되는 부분도 많아
그때그때 필요한 용도에 따라 선택해서 사용하는 건 개발자의 몫이겠다고 생각했다.

참조:
https://onlyfor-me-blog.tistory.com/434?category=905380

https://kotlinworld.com/361