(디자인 패턴과 프로그래밍 패러다임) 1. 디자인 패턴

코드 예제와 내용 좀더 추가하기

1.1 싱글톤 패턴
1.2 팩토리 패턴
1.3 전략 패턴
1.4 옵저버 패턴
1.5 MVC 패턴
1.6 mvp 패턴
1.7 MVVM 패턴

디자인 패턴이란

• 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것을 의미합니다.

1.1 싱글톤 패턴

싱글톤 패턴(singleton pattern)은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴입니다. 보통 데이터베이스 연결 모듈에 많이 사용합니다.

 

하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있습니다. 하지만 의존성이 높아진다는 단점이 있습니다.

자바 코드 예제 : 

 

 

싱글톤 패턴은 TDD(Test Driven Development)를 할 때 걸림돌이 됩니다.  TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 합니다. 

 

하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 '독립적인' 인스턴스를 만들기가 어렵습니다.

 

이러한 단점을 보완한수 있는게 '의존성 주입'이다.

 

의존성 주입 (이부분을 파보자!!!)

싱글톤 패턴은 사용하기가 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있습니다. 이때 의존성 주입(DI, Dependency Injection)을 통해 모듈간의 결합을 조금 더 느슨하게 만들어 해결할 수 있습니다.

 

의존성이란 종속성이라고도 하며 A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A 또한 면해야 한다는 것을 의미합니다. 

 

 

메인 모듈이 '직접' 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 '간접'적으로 의존성을 주입하는 방식입니다.

 

이를 통해 메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 됩니다. 이를 '디커플링 된다'라고 합니다.

의존성 주입의 장점

모듈들을 쉽게 교체할 수 있는 구조가 되어 (1) 테스팅하기 쉽고,  (2) 마이그레이션하기도 수월합니다. 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 (3) 애플리케이션 의존성 방향이 일관되고, (4) 애플리케이션을 쉽게 추론할 수 있으며, (5) 모듈 간의 관계들을 조금 더 명확해집니다. 

 

의존성 주입의 단점

모듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 패널티가 생기기도 합니다.

 

의존성 주입 원칙

의존성 주입은 "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 합니다. 또한, 둘다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 합니다." 라는 의존성 주입 원칙을 지켜주면서 만들어야 합니다. 

 

1.2 팩토리 패턴

팩토리 패턴(factory pattern)은 객체를 사용하는 코드에서 객체 생성 부분을 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴입니다.

 

• 상위 클래스 : 뼈대 
• 하위 클래스 : 객체 생성

 

상위 클래스와 하위 클래스가 분리되기 떄문에 느슨한 결합을 가지며 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 갖게 됩니다. 그리고 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링하더라도 한 곳만 고칠 수 있게 되니 유지 보수성이 증가됩니다.

• 느슨한 결합 -> 유연성
• 유지 보수성 up

 

예를 들자면 라떼 레시피와 아메리카노 레시피, 우유 레시피라는 구체적인 내용이 들어 있는 하위 클래스가 컨베이어 벨트를 통해 전달되고, 상위 클래스인 바리스타 공장에서 이 레시피를 토데로 우유 등을 생산하는 생산 공정을 생각하면 됩니다.

1.3 전략 패턴

전략 패턴(strategy pattern)은 정책 패턴(policy pattern)이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트안으로 바꿔주면서 상호 교체가 가능하게 만드는 패턴이다.

 

우리가 어떤 것을 살 때 네이버페이, 카카오페이 등 다양한 방법으로 결제하듯이 어떤 아이테을 살 때 LUNACard로 사는 것과 KAKAOCard로 사는 것을 구현한 예제입니다. 결제 방식의 '전략' 만 바꿔서 두가지 방시으로 결제하는 것을 구현했습니다.

 

-코드는 나중에 추가 예정

passport 전략 패턴

전략 패턴을 활용한 라이브러리로는 passport가 있습니다.

passport는 Node.js에서 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리로, 여러 가지 '전략'을 기반으로 인증할 수 있게 합니다. 서비스 내의 회원가입된 아이디와 비밀번호를 기반으로 인증하는 LocalStrategy 전략과, 페이스북, 네이버 등 다른 서비스를 기반으로 인증하는 OAuth 전략 등을 지원합니다. 

1.4 옵저버 패턴

옵저버 패턴(observer pattern)은 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려 주는 디자인 패턴입니다. 

 

여기서 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는 메소드 등을 기반으로 '추가 변화 사항'이 생기는 객체들을 의미한다. 

옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC(Model - View - Controller) 패턴에도 사용됩니다.

 

예를 들어 주체라고 볼 수 있는 모델(model)에서 변경 사항이 생겨 update() 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러(controller) 등이 작동하는 것이다.

자바: 상속과 구현

상속(extends) : 자식 클래스와 부모 클래스의 메소드 등을 상속 받아 사용하며 자식 클래스에서 추가 및 확장을 할 수 있는 것을 말합니다. 이로 인해 재사용성, 중복성의 최소화가 이루어지니다. (!!! 재사용성 증가 && 중복성 최소화 !!!)

 

구현(implements) : 부모 인터페이스(interface)를 자식 클래스에서 재정의하여 구현하는 것을 말하며, 상속과는 달리 반드시 부모 클래스의 매서드를 재정의하여 구현해야 합니다.  (!!! 매서드 재정의 && 구현 !!!)

 

상속과 구현의 차이: 상속은 일반 클래스, abstract 클래스를 기반으로 구현하며, 구현은 인터페이스를 기반으로 구현.

 

1.5 MVC 패턴

MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴입니다.

mvc 패턴

애플리케이션의 구성 요소를 세가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있습니다. 

 

장점 : (a) 재사용성, (b) 확장성

단점 : 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해진다.  

 

Model (모델):

모델(model)은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻합니다.

예를 들어 사각형 모양의 박스 안에 글자가 들어 있다면 그 사각형 모양의 박스 위치 정보, 글자 내용, 글자 위치, 글자 포멧(utf-8 등)에 관한 정보를 모두 가지고 있어야 합니다. 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신합니다.

 

View(뷰) :

뷰(view)는 inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냅니다. 즉, 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻합니다. 모델을 가지고 있는 정보를 따로 저장하지 않아야 하며 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 합니다. 또한, 변경이 일어나면 컨트롤러에 이를 전달해야 합니다. 

 

Controller(컨트롤러) :

컨트롤러(Controller)는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당합니다. 또한, 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줍니다. 

 

1.6 mvp 패턴

MVP 패턴은 MVP 패턴으로부터 파생되었으며  MVC에서 C에 대항하는 컨트롤러가 프레텐터(presenter)로 교체된 패턴입니다.

 

View와 Presenter는 1:1 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이라고 볼 수 있습니다.

 

1.7 MVVM 패턴

MVVM패턴은 MVC에서 Controller 부분이 View Model(뷰모델)로 바뀐 패턴입니다. 

mvvm 패턴

여기서 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징입니다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅 하기 쉽다는 장점이 있습니다.

 

커멘드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법이다.

데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰모델을 변경하면 뷰가 변경된다