디자인 패턴과 프로그래밍 패러다임에 대해 알아보자!

이번 글은 면접을 준비하며 읽은 ' 면접을 위한 CS 전공지식 노트 ' 를 정리했습니다.

https://product.kyobobook.co.kr/detail/S000001834833

면접을 위한 CS 전공지식 노트 | 주홍철 - 교보문고

 

 

안녕하세요.

오늘은 라이브러리나 프레임워크의 기본이 되는 디자인 패턴과 어떠한 방식으로 로직을 구성해야 하는지에 대한 시각을 담은 프로그래밍 패러다임에 대해 알아보겠습니다.

 

 

라이브러리란?

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미합니다.

폴더명, 파일명 등에 대한 규칙이 없고 프레임워크에 비해 자유롭습니다.

 

 

프레임워크란?

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미합니다.

폴더명, 파일명 등에 대한 규칙이 있으며 라이브러리에 비해 좀 더 엄격합니다.

 

 

 

1.1 디자인 패턴이란?

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

1.1.1 싱글톤 패턴이란?

하나의 클래스는 하나의 인스턴스만 가지는 패턴입니다.

데이터베이스 연결 모듈에 많이 사용합니다.

장점

하나의 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스 생성 비용을 줄일 수 있습니다.

단점

하나의 인스턴스에만 의존하기 때문에 의존성이 높아집니다.

TDD를 할 때 걸림돌이 됩니다.

(단위 테스트는 서로 독립적이어서 어떠한 순서로든 실행할 수 있어야하기 때문이다.
싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 하므로 각 테스트마다 독립적인 인스턴스를 만들기가 어렵다.)

 

싱글톤 패턴에서의 의존성 주입

의존성 주입(DI, Dependency Injection)을 통해 싱글톤 패턴의 강한 의존성 문제를 완화할 수 있습니다.

의존성이란, A가 B에 의존성이 있을 때 B가 변경되면 A도 변경되어야 한다는 것을 의미합니다.

 

의존성 주입은 다음과 같은 방식으로 이뤄집니다.

메인 모듈이 직접 다른 하위 모듈에 의존성을 주는 것이 아니라,

중간에 의존성 주입자(dependency injector)가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식입니다.

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

 

의존성 주입의 장점

모듈을 쉽게 교체할 수 있는 구조가 되어 테스팅과 마이그레이션이 수월합니다.

또한 추상화 레이어를 기반으로 구현체를 넣어주기 때문에  의존성 방향이 일관되고, 추론이 쉬워지며 모듈 간 관계가 명확해집니다.

의존성 주입의 단점

모듈이 여러 개로 분리되어 클래스 수가 늘어나므로 복잡성이 증가할 수 있습니다.

약간의 런타임 페널티가 생깁니다.

의존성 주입 원칙

상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 합니다.

또한 두 모듈은 추상화에 의존해야 하며, 추상화는 세부 사항에 의존하지 말아야 합니다.

 

 

 

 

1.1.2 팩토리 패턴

객체 생성 부분을 떼어내 추상화한 패턴입니다.

상속 관계에 있는 두 클래스에서,

상위 클래스가 중요한 뼈대를 결정하고 하위 클래스는 객체 생성에 관한 구체적인 내용을 결정하는 패턴입니다.

 

장점

상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 갖습니다.

상위 클래스는 인스턴스 생성 방식을 몰라도 되기 때문에 유연성을 갖습니다.

객체 생성 로직이 분리되어 있어 유지 보수성이 증가됩니다.

 

 

 

 

1.1.3 전략 패턴 (정책 패턴)

객체의 행위를 바꾸고 싶을 때, 직접 수정하지 않고 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔서 상호 교체가 가능하게 만드는 패턴입니다.

예) 결제 시, 네이버페이와 카카오페이 등 다양한 방법으로 결제

 

 

 

 

 

1.1.4 옵저버 패턴

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 옵저버들에게 변화를 알려주는 디자인 패턴입니다.

주체는 객체(subject)의 상태 변화를 보고 있는 관찰자입니다.

옵저버들은 객체의 상태 변화에 따라 추가 변화 사항이 생기는 객체들을 의미합니다.

상태가 변경되는 객체가 주체가 되어 옵저버들에게 알리는 형태로 구현하기도 합니다.

 

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

예) 주체인 모델에서 변경 사항이 생기면, update()로 옵저버인 뷰에 알리고 컨트롤러 작동

 

 

 

자바에서의 extends와 implements

상속 (extends)

자식 클래스가 부모 클래스의 필드와 메서드를 상속받아 사용할 수 있는 것을 말합니다.

재사용성이 증가하고 중복성을 최소화할 수 있습니다.

일반 클래스나 abstract 클래스를 기반으로 구현합니다.

 

구현 (implements)

부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것을 말합니다.

반드시 부모 클래스의 메서드를 재정의하여 구현해야 합니다.

인터페이스를 기반으로 구현합니다.

 

 

 

 

1.1.5 프록시 패턴과 프록시 서버

프록시 패턴 (proxy pattern)

대상 객체(subject)에 접근하기 전 그 접근에 대한 흐름을 가로채

해당 접근을 필터링하거나 수정하는 역할을 하는 계층이 있는 디자인 패턴입니다.

객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용합니다.

+ 프록시 서버에서의 캐싱
   캐시 안에 정보를 담아두고, 캐시 안에 있는 정보를 요구하면 원격 서버에 요청하지 않고 캐시 안의 데이터를 활용하는 것이다.

   이를 통해 불필요하게 외부와 연결하지 않아 트래픽을 줄일 수 있는 장점이 있다.

 

프록시 서버 (proxy server)

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램입니다.

프록시 서버의 예시로는 Node.js 서버 앞단의 프록시 서버로 활용되는 nginx가 있습니다.

 

nginx는 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리하는 웹 서버입니다.

nginx를 Node.js 서버의 앞단에 두어, 사용자가 직접적으로 서버에 접근하는 것을 차단하고, 간접적으로 한 단계를 더 거치게 만들어서 보안을 강화할 수 있습니다.

또한 실제 포트를 숨길 수 있고 정적 자우너을 gzip 압축하거나, 메인 서버 앞단에서의 로깅을 할 수도 있습니다.

•  gzip 압축
  LZ77과 Huffman 코딩의 조합인 DEFLATE 알고리즘을 기반으로한 압축 기술입니다.
  gzip 압축을 하면 데이터 전송량을 줄일 수 있지만, 압축 해제 시 서버에서의 CPU오버헤드도 생각해야 합니다.
  

• 프록시 서버로 쓰는 CloudFlare
  전세계적으로 분산된 서버를 통해 콘텐츠 전달을 빠르게 할 수 있는 CDN(Content Delivery Netwok) 서비스입니다.
  DDOS(Distributed Denial of Service) 공격 방어나 HTTPS 구축에 쓰입니다.
  CAPTCHA 기반으로 의심스러운 트래픽 발생 시 막아주기도 합니다.
   + CDN(Content Delivery Network)
     사용자가 인터넷과 접속하는 곳과 가까운 곳에서 콘텐츠를 캐싱, 배포하는 서버 네트워크입니다.
     사용자가 웹서버로부터 콘텐츠를 다운로드하는 시간을 줄일 수 있습니다.

CORS와 프론트엔드의 프록시 서버

CORS(Cross Origin Resource Sharing)은 서버가 웹 브라우저에 리소스를 로드할 때 다른 origin(도메인)을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘입니다. (origin = protocal + domain + port, 예: https://my-frontend.com:3000)

백엔드 서버와 프론트엔드 서버가 통신할 때 발생하는 CORS에러는 프론트엔드에서 프록시 서버를 만들어 해결할 수 있습니다.

[브라우저] → [프록시 서버(localhost:3000)] → [백엔드 서버(localhost:8080)]

(백엔드에서 CORS 헤더 설정해서 특정 경로 허용해도 됨)

 

 

 

 

1.1.6 이터레이터 패턴(Iterator Pattern)

iterator를 사용하여 collection의 요소들에 접근하는 디자인 패턴입니다.

장점: 자료형의 구조와는 상관없이(다른 객체여도) 이터레이터라는 하나의 인터페이스로 순회가 가능합니다.

 

 

 

 

 

1.1.7 노출모듈 패턴(Revealing Module Pattern)

자바스크립트에서 실행함수를 통해 접근 제어자(private, public, ...)을 만드는 패턴입니다.

접근제어자 (JAVA)

• public: 어디에서나 접근 가능
• protected: 같은 패키지 + 자식
• default → 같은 패키지
• private → 클래스 내부에서

 

 

 

 

1.1.8 MVC 패턴

model, view, controller로 이루어진 디자인 패턴입니다.

장점: 재사용성과 확장성이 용이합니다.

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

• model: 애플리케이션의 데이터(db, 상수, 변수)
• view: 사용자가 볼 수 있는 화면(사용자 인터페이스 요소). 변경 시 컨트롤러에게 전달해야함.
• controller: model과 view를 잇는 다리 역할. 메인 로직 담당.

 

 

 

 

1.1.9 MVP 패턴

controller가 presenter로 교체된 패턴입니다.

mvc와 다르게 view와 presenter가 일대일 관계를 가져, 더 강한 결합을 지닙니다.

 

 

 

 

 

1.1.10 MVVM 패턴

MVC패턴의 controller가 view model로 바뀐 패턴입니다.

view model은 뷰를 더 추상화한 계층입니다.

command(여러 요소 처리를 하나의 액션으로 처리하는 기법)와 data binding(뷰모델 변경 -> 뷰변경)을 가지는 것이 특징입니다.

 

장점

뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원합니다.

코드 수정없이 ui 재사용이 가능합니다.

단위테스트가 용이합니다.

예) Vue.js (함수 사용 없이 값 대입만으로 변수가 변경)

 

 

 

 

 

 

 

 

 

 

1.2 프로그래밍 패러다임이란?

프로그래밍의 관점을 갖게 해주는 개발 방법론입니다.

프로그래밍 패러다임
├─ 선언형
│   └─ 함수형
│
└─ 명령형
    ├─ 객체지향형
    └─ 절차지향형

 

 

 

 

 

1.2.1 선언형과 함수형 프로그래밍

선언형 프로그래밍(declaritive programming)

무엇을 풀어내는가에 집중하는 패러다임입니다.

" 프로그램은 함수로 이루어진 것이다. " 라는 명제가 담겨있습니다.

 

함수형 프로그래밍(functional programming)

선언형 패러다임의 일종으로,

순수함수를 블록처럼 쌓아 로직을 구현하고, 고차함수를 통해 재사용성을 높인 프로그래밍 패러다임입니다.

+ 순수함수
   출력이 입력에만 의존하는 함수입니다.

+ 고차함수
   함수를 매개변수로 받을 수 있는 함수입니다.
   언어가 일급 객체의 특징을 가질 때 쓸 수 있습니다.

   

   일급객체?

1. 변수나 메서드에 함수를 할당할 수 있습니다.
2. 함수 안에 함수를 매개변수로 둘 수 있다.
3. 함수가 함수를 반환할 수 있다.

 

 

 

 

 

1.2.2 객체지향 프로그래밍 (OOP, Object Oriented Programming)

데이터를 개체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식입니다.

객체들의 집합으로 프로그램의 상호작용을 표현합니다.

다른 패러다임들에 비해 속도가 느립니다.

 

객체지향 프로그래밍의 특징

추상화

복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것을 의미합니다.

 

캡슐화

객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것을 말합니다.

 

상속성

상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것을 말합니다.

코드의 재사용, 계층적 관계 생성, 유지보수성 증가 측면에서 중요합니다.

 

다형성

하나의 메서드나 클래스가 다양한 방법으로 동작하는 것으로 말합니다.

예) 오버라이딩, 오버로딩

• 오버라이딩
  상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것입니다.
  런타임 중에 발생하는 동적 다형성입니다.
• 오버로딩
  같인 이름을 가진 메서드를 여러 개 두는 것입니다.
  메서드 타입, 매개변수 유형, 개수 등을 달리하여 오버로딩할 수 있습니다.
  컴파일 중에 발생하는 정적 다형성입니다.

 

 

 

객체지향 프로그래밍의 SOLID 원칙

• SRP(Single Responsibility Principle), 단일 책임 원칙
  모든 클래스는 하나의 책임만 가져야 한다.
  예) A 로직이 존재할 때, 어떠한 클래스는 A에 관한 클래스여야 하고 이를 수정한다고 해도 A와 관련된 수정이어야 한다.
• OCP(Open Closed Principle), 개방-폐쇄 원칙
  유지보수사항이 생기면 코드를 쉽게 확장할 수 있도록 하고, 수정할 때는 닫혀있어야 한다.
  기존의 코드는 잘 변경하지 않으면서도, 확장은 쉬워야 한다.
• LSP(Liskov Substitution Principle), 리스코프 치환 원칙
  객체는 프로그램의 정확성을 깨뜨리지 않으며 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  부모 대신 자식 객체를 넣어도 시스템이 문제없이 돌아가야 한다.
• ISP(Interface Segregation Principle), 인터페이스 분리 원칙
  하나의 인터페이스를 만들기보다, 구체적인 여러개의 인터페이스를 만들어야 한다.
• DIP(Dependency Inversion Principle), 의존 역전 원칙
  상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 한다.
  추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 영향을 받지 않게 만들어야한다.

 

 

 

 

 

 

1.2.3 절차형 프로그래밍

로직이 수행되어야 할 연속적인 계산 과정으로 구성합니다.

 

장점

코드의 가독성이 좋으며 실행 속도가 빠릅니다.

계산이 많은 작업에 유리합니다.

단점

모듈화가 어렵고 유지 보수성이 떨어집니다.

 

 

 

제일 좋은 패러다임은 없다!
여러가지를 조합하여 상황에 맞게 쓰면 된다!