디자인 패턴

싱글톤 패턴

• 하나의 클래스로 하나의 인스턴스를 만듦(ex. DB 연결 모듈)
• 장점 : 하나의 인스턴스를 만들어 놓고 다른 모듈들이 공유하기때문에 인스턴스 생성시 발생하는 비용 감소
• 단점
  • TDD(Test Driven Development)를 수행할 때 단위 테스트를 하지만, 싱글톤은 미리 생성된 하나의 인스턴스를 기반으로 구현하므로 테스트 마다 독립적인 인스턴스를 만들기가 어려움
  • 모듈간의 결합을 강하게 만듦(의존적 종속성) -> 의존성 주입(DI, Dependency Injection)으로 해결할 수 있음
    - 의존성 주입 장점 : 의존성 주입을 통해 모듈들을 쉽게 교체할 수 있는 고조가 되어 테스트 및 마이그레이션을 수행할 때 수월해짐 /
    - 의존성 주입 단점: 모듈들이 분리되기 때문에 클래스 수가 늘어나 복잡성이 증가되며 약간의 런타임 패널티가 발생함.
    - 의존성 주입의 원칙 - 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 말아야하며, 둘다 추상화에 의존하고, 추상화는 세부사항에 의존하지 말아야함.

팩토리 패턴

• 결합도( 한 클래스에 변경점이 얼마나 다른 클래스에 영향을 주는가를 의미 )를 줄이기 위해 생김
• 객체를 생성하기위해 인터페이스를 정의할 때 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정-> 클래스의 인스턴스를 만드는 일을 서브클래스에 맡김.
• 장점
  • 객체간의 결합도를 낮춤
  • 단일 책임의 원칙을 따름. 프로그램의 코드에서 생성자 코드를 분리
• 단점
  • 패턴을 구현할 많은 서브 클래스를 도입함으로써 코드가 복잡해짐

전략 패턴 / 정책패턴

• 객체의 행위를 바꾸고 싶은 경우 캡슐화한 알고리즘을 컨텍스트안에서 바꿔주면서 상호교체 가능하게 만드는 패턴
• ex. node.js에서 passport 인증모듈 라이브러리 -> 아이디 비밀번호로 인증하는 LocalStrategy 혹은 다른 서비스를 기반으로 인증하는 OAuth 전략으로 인증

옵저버 패턴

• 주체(객체의 상태변화를 보고잇는 관찰자)가 객체의 상태 변화를 관찰하다가 변화가 있을 경우에만 메서드 등을 통해 옵저버 목록에 있는 옵저버(객체의 변화에 따라 추가 변화 사항이 있는 객체들)들에게 변화를 알려주는 디자인 패턴
• ex. 인스타그램에 글을 올리면 팔로잉 하는 사람들에게 알림이 감 / MVC패턴에도 모델에서 변경이 생겨 update() 메서드로 옵저버인 뷰에 알려주고, 컨트롤러등이 작동하는 방식

프록시 패턴과 프록시 서버

• 대상 객체에 접근하기 전 그접근에 대한 흐름을 가초래 대상 객체 앞단의 인터페이스 역할을 하는 디자인패턴
• ex. 객체의 속성, 변환등을 보완하여 보안, 데이터 검증, 캐싱, 로깅에 사용
• 프록시 서버는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킴 -> ex. nginx는 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹서버
• cors 에러 해결을 위해서도 프록시 서버를 구성해서 프론트엔드-> 백엔드로 넘어갈때 포트번호를 맞춰주어 cors 에러를 해결

이터레이터 패턴

• 이터레이터를 사용해 컬렉션의 요소들에 접근하는 디자인 패턴
• 집합체 내에서 어떤 식으로 일이 처리되는지 몰라도 그 안에 들어있는 항목들에 대해서 반복작업을 수행

노출모듈 패턴

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴