디자인 패턴
프로그램 설계 중 발생한 문제들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 만든 것.
1) 싱글톤 패턴
하나의 클래스에 하나의 인스턴스만 가지는 것
하나의 인스턴스를 여러 모듈들이 공유 - 비용이 줄지만 의존성 높아짐
주의할 점: Unit test를 시행하려면 각 Unit test가 독립적이어야 하는데 싱글톤 패턴은 각 테스트마다 독립적인 인스턴스 만들기 어려움
개선 방법: 의존성 주입 - 메인 모듈에서 직접 의존성을 제공하기보다 의존성 주입자에 제공하여, 주입자에서 각 하위 모듈에 제공하도록 구현하여 의존성을 낮출 수 있음
2) 팩토리 패턴
객체 생성 부분을 떼어내 추상화한 패턴
상위 클래스에서 뼈대를 정의(abstract 키워드 사용가능)하고 하위 클래스에서 구체적인 내용 결정(상속 이용)
예시)
Coffee Class - price 값과 getPrice 메소드(abstract)
Latte Class - Coffee 상속. 구체적인(Latte의) price 값 제공
CoffeeFactory(type) - type을 입력받아 해당 type의 Coffee Class 인스턴스 제공
3) 전략 패턴
객체의 행위를 바꾸는 경우 전략을(캡슐화한 알고리즘) 교체하여 바꾸는 패턴
전략에 관한 interface를 정의하고 해당 타입으로 변수를 선언하여 필요 시 전략 인터페이스를 상속받는 다른 객체 타입으로 교체.
예시)
interface Strategy 선언
Class Strategy1, Strategy2 - Strategy interface 구현(구체적인 행동 정의).
Strategy 타입 변수에 Strategy1 또는 Strategy2 인스턴스를 넣어 interface 함수 실행
4) 옵저버 패턴
주체가 관찰 대상(Subject)을 관찰하다가 변화가 생기면 모든 관찰자(Observer)에게 알려주는 패턴
Subject와 Observer interface를 정의하고 Subject에 Observer들을 등록한 후 값을 변경하는 set 함수가 호출되면 등록된 모든 Observer들에게 update함수 호출로 알림.
예시)
Subject(등록, 제거, 업데이트 함수), Observer interface(업데이트 함수) 선언
Class TestSubject - Subject 구현. 멤버변수로 Observer 배열 존재. 멤버변수 데이터가 변경될 경우(set 호출) notify함수를 통해 배열의 모든 Observer들의 update()함수 호출
Class TestObserver - Observer 구현. 멤버변수로 Subject 존재. Observer update함수에서 해당 Subject 변수의 update함수를 호출하여 변경된 데이터 제공받음
5) 프록시 패턴
대상 객체에 접근하기 전 접근 흐름을 가로채 인터페이스로 연결하는 패턴
프록시 서버 구축에 주로 쓰이며 모든 사용자가 서버에 직접 접속하지 못하도록 간접적으로 한 단계를 더 거치도록 함 (NGINX, CloudFlare 등)
+)프록시 서버: 서버 앞단에 둬서 캐싱, 로깅, 데이터 분석 미리 하는 서버. 포트 번호를 바꿔 실제 서버의 포트에 접근하지 못하도록 하는 등 기능 가능
6) 이터레이터 패턴
iterator를 사용하여 컬렉션의 요소들에 접근하는 패턴
대상 컬렉션이 어떤 타입인지(Array, List, Map, Set 등)에 관계없이 순회가 가능하도록 Iterator 객체를 구현
Iterator interface를 선언하여 hasNext와 next 함수를 정의하고 ArrayIterator, ListIterator 등 구현 객체를 선언한 후 내부적으로 순회 로직을 작성함
7) MVC 패턴
Model, View, Controller로 어플리케이션 구성 요소를 나누어 개발하는 패턴.
재사용성과 확장성이 용이하며 어플리케이션이 복잡해 질수록 모델과 뷰 관계 복잡
Controller는 여러 개의 View를 선택할 수 있음(1:N)
View는 Controller를 알지 못함
-
모델 - 어플리케이션의 데이터(db, 상수, 변수 등)
-
뷰 - 사용자 인터페이스 요소(보이는 부분). 모델 정보 따로 저장X, 변경 시 컨트롤러에 전달
-
컨트롤러 - 모델과 뷰 잇는 역할. 이벤트 등 메인 로직 담당
이벤트→ 갱신→ 뷰 ↔ 컨트롤러 ↔ 모델 ←갱신 ←알림
8) MVP 패턴
Model, View, Presenter로 어플리케이션 구성 요소를 나누어 개발하는 패턴
MVC와 유사하나 View와 Presenter가 일대일 관계로 더 강한 결합.
View와 Model 사이에 의존성이 없음
이벤트→ 갱신→
뷰 ↔ 프레젠터 ↔ 모델
←갱신 ←변경9) MVVM 패턴
Model, View, ViewModel로 어플리케이션 구성 요소를 나누어 개발하는 패턴
UI를 별도의 코드 수정 없이 재사용 가능하며 단위 테스트하기 좋음.
ViewModel과 View는 1:N 관계.
View와 ViewModel(데이터 바인딩 이용), 그리고 View와 Model 사이의 의존성이 없음
databinding, command 갱신→
View ↔ ViewModel → Model
←알림 ←알림