[면접,CS] 디자인패턴

 

디자인패턴?

디자인패턴은 프로그램 설계에 있어서 마주하는 문제들을 객체 간의 상호관계 등을 이용해 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것이다.

 

싱글톤 패턴

싱글톤 패턴(singleton pattern)은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다.

메모리 절약을 위해 인스턴스를 새로만들지 않고 기존의 인스턴스를 가져와 활용하는 기법이다.

따라서, 리소스를 많이 차지하는 역할(데이터베이스 연결 모듈 등)을 하는 무거운 클래스에 적합하다.

데이터베이스 연결, socket.io 등 네트워크 통신에 많이 사용된다.

 

장점

하나의 인스턴스를 기반으로 해당 인스턴스를 다른 모듈들이 공유하여 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어든다.

 

단점

- 모듈간 의존성이 높아진다.

- SOLID 원칙에 위배되는 경우가 많다.

- 단위테스트가 어렵다.

---

팩토리 메서드 패턴

객체를 사용하는 코드에서 생성부분을 떼어내 추상화한 패턴이다.

상속 관계에 있는 두 클래스에서 상위클래스가 중요한 뼈대를 결정하고, 하위클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴이다.

 

 

패턴사용시기

- 클래스 생성과 사용의 처리 로직을 분리하여 결합도를 낮추고자 할 때

- 코드가 동작해야 하는 객체의 유형과 종속성을 캡슐화를 통해 정보 은닉 처리 할 때

- 라이브러리 혹은 프레임워크 사용자에게 구성 요소를 확장하는 방법을 제공할 경우

- 기존 객체를 재구성하는 대신 기존 객체를 재사용하여 리소스를 절약하고자 하는 경우

 

 

장점

- 생성자와 구현 객체의 강한 결합을 피할 수 있다.

- 팩토리 메서드를 통해 객체의 생성 후 공통으로 할 일을 수행하도록 지정할 수 있다.

- 캡슐화, 추상화를 통해 생성되는 객체의 구체적인 타입을 감출 수 있다.

- 유지보수 및 확장성이 좋다.

 

단점

- 관련 클래스 수가 많아진다.

- 코드의 복잡성이 증가한다.

---

전략 패턴

전략 패턴은 실행(런타임) 중에 알고리즘 전략을 선택하여 객체 동작을 실시간으로 바뀌도록 할 수 있게 하는 디자인 패턴이다.

 

패턴 사용 시기

- 알고리즘 코드가 노출되어서는 안 되는 데이터에 액세스하거나 데이터를 활용할때 (캡슐화)

- 알고리즘의 동작이 런타임에 실시간으로 교체되어야 할 때

 

예시 -> passport.js 라이브러리

const passport = require('passport'); // passport.js의 객체 가져오기
const KakaoStrategy = require('passport-kakao').Strategy; 
const NaverStrategy = require('passport-naver-v2').Strategy;
const GoogleStrategy = require('passport-google-oauth20').Strategy;
 
// 카카오 로그인 전략 등록
passport.use(new KakaoStrategy({ clientID, callbackURL }, async (accessToken, refreshToken, profile, done) => {
	// ...
});
 
// 네이버 로그인 전략 등록
passport.use(new NaverStrategy({ clientID, clientSecret, callbackURL }, async (accessToken, refreshToken, profile, done) => {
	// ...
});
 
// 구글 로그인 전략 등록
passport.use(new GoogleStrategy({ clientID, clientSecret, callbackURL }, async (accessToken, refreshToken, profile, done) => {
	// ...
});

 

장점

- 전략 사용자의 코드 변경 없이 새로운 전략을 추가할 수 있다.

- 확장에 유리한 코드를 작성할 수 있다.

- 런타임에 전략을 변경할 수 있다.

 

단점

- 어플리케이션에 들어가는 모든 전략을 알고 있어야 한다.

- 전략을 추상화한 인터페이스가 효율적이지 못할 수 있다.

 

---

옵저버 패턴

옵저버 패턴은 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴이다.

 

 

패턴사용시기

- 객체의 상태가 변경될 때마다 어떤 이벤트를 실행하고 싶을때

- MVC 패턴에서 많이 사용한다.

 

 

장점

- 변경 사항이 생셔도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축

- 상호의존성을 최소화한다.

- 개방/폐쇄 원칙을 지킨다.

 

단점

- 알림이 가는 순서를 보장할 수 없다.

 

---

프록시 패턴

프록시 패턴은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴이다.

주로, 보안, 데이터검증, 캐싱, 로깅에 사용하며 nginx를 생각하면 된다.

 

 

장점

- 사이즈가 큰 객체가 로딩되기 전에도 프록시를 통해 참조할 수 있다.

- 실제 객체의 pubilc, protected 메소드를 숨기고 인터페이스를 통해 노출시킬 수 있다.

- 로컬에 있지 않고 떨어져있는 객체를 사용할 수 있다.

- 원래 객체에 접근에 대해 사전처리를 할 수 있다.

 

단점

- 객체 생성시 한 단계를 거쳐서 진행되기 때문에 빈번한 객체 생성시 성능 저하가 될 수 있다.

- 로직이 난해해져 가독성이 떨어질 수 있다.