[디자인패턴] (iOS) 디자인 패턴이란? 개요 및 분류 방법!

 

스터디를 운영하고 있습니다. 
아래 깃허브 PR 내역을 보시면, 다양한 의견을 주고받은 history를 보실 수 있습니다.

https://github.com/JulSaMo/CS-start/pulls

 

---

 

🟠 디자인 패턴 (Design Pattern) 이란

- 소프트웨어를 개발할 때 발생하는 다양한 문제에 대한 재사용 가능한 탬플릿 해결 방법

• 프로그래밍을 할 때 특정 상황에 적용되는 패턴을 정형화해 두면 비슷한 상황에서는 더욱 빠르게 대처할 수 있음
• 프로젝트에 항상 적용해야하는 것은 아니지만, 추후 재사용, 호환, 유지보수 시 발생하는 문제 해결을 예방하기 위해서 패턴을 만들어 둔 것

🔸 디자인 패턴의 특징

1. 디자이패턴은 하나의 아이디어이다. 특정한 구현이 아니다.
2. 경험을 통해 얻을 수 있다.
3. 특정한 형식을 갖고 체계적으로 작성되는 것이 일반적이다.
4. 패턴에는 각기 다른 추상화 수준이 존재하여 계속 진화한다.

🔸 디자인 패턴의 장점

1. 프로그래밍 과정에서 의사소통을 도와준다.

• 디자인 패턴을 알고 있는 설계자들은 문제에 대해 공통적으로 알고 있는 패턴을 이용해 논의할 수 있기 때문에 더욱 원활하게 의사소통이 가능

1. 개발 비용을 줄일 수 있다.

• 검증된 지식을 바탕으로 패턴을 사용하므로, 높은 완성도의 디자인을 빠른 시간안에 만들어 낼 수 있기 때문에.
• 또한 코드의 수준을 높여주며 적은 수의 클래스로 원하는 목적을 달성할 수 있는 환경이 제공된다.

1. 개발자는 그 패턴 이름만으로 그 소프트웨어의 구조를 알 수 있다.

• 이전의 소프트웨어 개발에서 사용한 설계나 구조를 쉽게 이해할 수 있고, 새로운 소프트웨어를 빠르게 적용할 수 있어서 소프트웨어 재사용이 쉽다.

🟠 객체 지향 디자인의 5대 원칙 SOLID

좋은 객체지향 설계를 위해서 5가지 원칙, SOLID를 따르는 것이 좋다. 이 원칙들을 기반으로 디자인 패턴이 되기 때문에 알아두는 것이 좋을 것이다.

• SRP (Single Responsibility Principle, 단일 책임 원칙)
  • 하나의 클래스는 하나의 역할만 해야한다.
• OCP (Open-Close Principle, 개방 폐쇄 원칙)
  • 확장(상속)에는 열려있고, 수정에는 닫혀있어야 한다.
• LSP (Liskov Substitution Prinsicple, 리스코프 치환 원칙)
  • 자식이 부모의 자리에 항상 교체될 수 있어야한다.
• ISP (Interface Segregation Principle, 인터페이스 분리 원칙)
  • 인터페이스가 잘 분리되어서, 클래스가 꼭 필요한 인터페이스만 구현하도록 해야함.
• DIP (Dependency Inversion Property, 의존성 역전 원칙)
  • 상위 모듈이 하위 모듈에 의존하면 안된다.
  • 둘 다 추상화에 의존하며, 추상화는 세부 사항에 의존하면 안된다.

🤔 패턴은 SOLID 원칙을 따르는 것이 좋다고 하는데, 
어떻게 따라야 하는건지 자세한 설명은 이슈에 작성할 예정이다.
코드를 패턴화 시키면서, 동시에 SOLID 원칙에 무너지지 않는 코드를 짜는게 중요할 것 같다.

🟠 디자인 패턴의 분류

• 개발자는 어떤 클래스를 만들고 어느 시점에 객체를 생성하고, 소멸시킬지, 데이터를 어떻게 받아서 처리할지, 구조설계를 어덯게 해야할지 고민한다.
• 디자인패턴 분류는, 위와 같이 소프트웨어 코드를 작성할 때 자주 반복되는 특정 상황에서 설계를 용이하게 하며 코드의 재사용이 용이하도록 패턴을 정리해 놓은 것
• 가장 잘 알려진 분류법으로 GoF 패턴 분류 방법이 있다.
• GoF 분류 방법은, 디자인 패턴을 목적과 범위로 분류했다.

🔸 목적에 따른 분류

패턴이 무엇인지 정의하는 것으로 "생성", "구조", "행위" 중 한 가지의 목적을 갖는다.

1️⃣ 생성 (Creational Pattern)

- 객체의 생성 과정에 관여하는 패턴이다.
- 객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크;게 받지 않도록 하여 프로그램에 유연성을 더해준다.

• (예시) DBConnection을 관리하는 Instance를 하나만 만들 수 있도록 제한하여, 불필요한 연결을 막음. (객체 생성에 관여!)

2️⃣ 구조 (Structural Patternn)

- 클래스나 객체의 구성을 통해 더 큰 구조를 만들 수 있게 해주는 것과 관련된 패턴
- 구조패턴은 구조가 복잡한 시스템을 개발하기 쉽게 도와준다.
- 총 7개의 패턴이 있다.

• (예시) 2개의 인터페이스가 서로 호환이 되지 않을 때, 둘을 연결해주기 위해서 새로운 클래스를 만들어서 연결시킬 수 있도록 하는 패턴.

3️⃣ 행위 패턴 (Behavioral Pattern)

- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 하나의 객체로 수행할 수 없는 작업들을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다.
- 총 11개의 패턴이 있다.

• (예시) 하위 클래스에서 구현해야하는 함수 및 알고리즘을 미리 선언하여, 상속시 이를 필수록 구현하도록 하는 패턴

🔸 생성, 구조, 행위 패턴의 종류

생성 패턴구조 패턴행위 패턴

추상 팩토리 (Abstract Factory)	어댑터 (Adapter)	책임 연쇄 (Chain of Responsibility)
빌더 (Builder)	브리지 (Bridge)	커맨드 (Command)
팩토리 메소드 (Factory Method)	컴포지트 (Composite)	인터프리터 (Interpretor)
프로토타입 Prototype)	데코레이터 (Decorator)	미디에이터 (중재자) (Mediator)
싱그톤 (Singleton)	퍼싸드 (Facade)	메멘토 (Memento)
	플라이웨이트 (Flyweight)	옵저버 (Observer)
	프록시 (Proxy)	상태 (State)
	✨MVC✨	전략 (Stretegy)
	✨MVP✨	템플릿 메소드 (Template Method)
	✨MVVM✨	비지터 (방문자) (Visitor)
		반복자 (Iterator)

🤔 각각의 패턴 간단하게 알아보기

정말 정말 간단하게 개념만 짚고 넘어가는 단계입니다. (안할려다가 함!) 각각 패턴에 대한 자세한 사항은 추후 업로드 되는 패턴 관련 파일을 따로 보시면 자세한 이해가 가능합니다.

💬 생성패턴

추상 팩토리 (Abstract Factor)

- 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관,
   의존하는 객체들의 그룹으로 생성하여 추상적으로 표현한다.
- 연관 서브 클래스를 묶어 한 번에 교체하는 것이 가능하다.

빌더 (Builder)

- 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성한다.
- 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어낼 수 있다.

퍅토리 메서드 (Factory Method)

- 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴이다.
- 상위 클래스에서 인터페이스만 정의하고 실제 생ㅅ겅은 서브클래스가 담당한다.
- 가상 생성자 (Virtual Constructor) 패턴이라고도 한다.

프로토타입 (Prototype)

- 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴이다.
- 일밙덕인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용한다.

싱글톤 (Singleton)

- 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없다.
- 클래스 내에서 인스턴스가 하나 뿐임을 보장하며, 불핖요한 메모리 낭비를 최소화할 수 있다.

💬 구조패턴

MVC, MVVM, MVP 는 iOS에서 가장 대표적으로 사용하는 '구조패턴'이다.

✨MVC✨

- Model: 앱의 비즈니스 로직이나 데이터를 담당하는 코드
- View: 사용자에게 보여지는 집단
- Controller: Model과 View 사이의 중간자 역할
✅ iOS는 주로 ViewController로 View + Controller로 사용

<🤔단점>
- View와 Controller간의 의존성이 높아짐에 따라 재사용성이 낮아지게 된다. -> 그래서 MVP 등장

✨MVP✨

Controller를 대신해 present라는 개념으로 바뀌었다.
하지만 이 역시 view - present의 관계가 1:1 이라는 의존성 문제가 생겨 낮은 재사용성을 갖는다는 단점이 있다.

✨MVVM✨

- 이벤트의 흐름이 단방향이다.
- 사용자의 이벤트를 view가 viewmodel로 전달하고, model에게 수정사항을 토스하는 식으로 진행
- command pattern(행위패턴!!)과 data binding을 이용하여 view와 viewmodel 사이의 의존성을 제거한다.

* data binding: viewmodel 에서 일어나는 일을 view가 observing하고 있음.
그리고 관찰하고 있던 viewmodel이 변경되면 자신이 보여주고 있는 view에 변경 사항을 알리며 바꿔서 보여줌

어댑터 (Adpator)

- 호환성이 없는 클래스들의 인터페이스를, 다른 클래스가 이용할 수 있또록 변환해주는 패턴
- 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용한다.

브리지 (Bridge)

- 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴이다.
- 기능과 구현을 두 개의 별도 클래스로 구현한다.

컴포지트 (Composite)

- 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴이다.
- 객체들을 트리 구조로 구성하여 디렉터리 안에 디랙터리가 있듯이,
  복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있다.

데코레이터 (Decorator)

- 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
- 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현

퍼싸드 (Facade)

- 복잡한 서브 클래스들을 피해 더 상위에 인터페이스들을 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요하다

플라이웨이트 (Flyweight)

- 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고, 가능한 한 공유해서 사용함으로써 메모리를 절약하는 피턴
- 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용할 수 있음

프록시 (Proxy)

- 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
- 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 

💬 행위 패턴

책임 연쇄 (Chain of Responsibility)

- 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리되지 못하면 다음 객체로 넘어가는 형태의 패턴
- 요청을 처리할 수 있는 각 객체들이 chain으로 묶여 있어 요청이 해결될 때까지 chain을 따라 책임이 넘어간다.

커맨드 (Command)

- 요청을 객체의 형태로 캡슐화하여 재이용하거나 최소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
- 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화한다.

인터프리터 (Interpreter)

- 언어에 문법 표현을 정의하는 패턴
- SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용한다.

반복자 (Iterator)

- 자료구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
- 내부 표현 방법의 노출 없이 순차적인 접근이 가능 

중재자 (Mediator)

- 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
- 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음
- 중재자는 객체 간의 통제와 지시의 역할을 수행

메멘토 (Memento)

- 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
- Cmd+Z 같은 되돌리기 기능을 개발할 때 주로 이용함

옵저버 (Observer)

- 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
- 주로 분산된 시스템 간에 이벤트를 생성, 발행하고 이를 수신해야할 때 이용

상태 (State)

- 객체의 상태에 따라 동일한 동ㅊ작을 다르게 처리해야할 때 사용하는 패턴
- 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리

전략 (Stretgy)

- 동일한 계열의 알고리즘을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
- 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향없이 알고리즘의 변경이 가능하다

탬플릿 메서드 (Template Method)

- 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
- 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 한다.

방문자 (Visitor)

- 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
- 분리된 처리 기능은 각 클래스를 방문(visit) 하여 

 

 

---

📖 Reference

https://woovictory.github.io/2019/05/10/What-is-SOLID/

[개발상식]객체 지향 디자인의 5대 원칙

https://velog.io/@myeongs07/iOS-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80

[iOS] 프로그래밍 디자인 패턴이란?

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Design%20Pattern/%5BDesign%20Pattern%5D%20Overview.md

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

https://velog.io/@ragnarok_code/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%EC%83%9D%EC%84%B1-%ED%8C%A8%ED%84%B4

디자인 패턴 - 생성 패턴

https://velog.io/@ragnarok_code/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%ED%96%89%EC%9C%84-%ED%8C%A8%ED%84%B4

디자인 패턴 - 행위 패턴

https://velog.io/@ragnarok_code/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%EA%B5%AC%EC%A1%B0-%ED%8C%A8%ED%84%B4

디자인 패턴 - 구조 패턴