[면접을 위한 CS 전공지식 노트] 디자인 패턴과 프로그래밍 패러다임

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

 

---

SECTION 1 디자인패턴

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

※ 코딩그라운드 링크: https://www.tutorialspoint.com/compile_java_online.php

 

 

1. 싱글톤 패턴(singleton pattern)

• 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
• 보통 db 연결 모듈에 많이 사용
• 장점: 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 떄문에 인스턴스를 생성할 때 드는 비용이 줄어듬
• 단점: 의존성이 높아짐 -> 의존성 주입을 통해 모듈간의 결합을 느슨하게 만들어 해결 가능

※  의존성 주입(Dependency Injection)

• 의존성 주입의 장점: 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션하기도 수월함
• 모듈들이 더욱 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있음, 약간의 런타임 페널이 생길 가능성
• 의존성 주입 원칙: "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 함", "둘다 추상화에 의존해야 하며, 이떄 추상화는 세부 사항에 의존하지 말아야 함"

---

2. 팩토리 패턴(factory pattern)

• 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
• 장점: 상위 클래스와 하위 클래스가 분리되어 있기 때문에 느슨한 결합을 가지며 유연성이 있음, 유지보수성 증가
• ex) 아메리카노 레시피, 라떼 레시피(하위 클래스) -> 컨베이어 벨트 -> 바리스타 공장(상위 클래스) => 음료 생산

---

3. 전략 패턴(strategy pattern) = 정책 패턴(policy pattern)

• 객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
• ex) 결제방식(삼성페이, 카카오페이 등)

※ 컨텍스트 : 상황, 맥락, 문맥을 의미하며 개발자가 어떠한 작업을 완료하는 데 필요한 모든 관련 정보를 말함

---

4. 옵저버 패턴(observer pattern)

• 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 떄마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려 주는 디자인 패턴
• 주체: 객체의 상태 변화를 보고 있는 관찰자
• 옵저버: 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들
• ex) 트위터 -> "팔로우", mvc 패턴

※ 자바의 상속과 구현

• 상속(extends) : 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용하며 자식 클래스에서 추가 및 확장할 수 있는것, 재사용성, 중복의 최소화, 일반클래스와 abstract 클래스 기반
• 구현(implements) : 부모 인터페이스(interface)를 자식 클래스에서 재정의하여 구현하는 것, 인터페이스 기반

---

5. 프록시 패턴과 프록시 서버(proxy pattern)

• 대상 객체(subject)에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
• 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용

※ 프록시 서버에서의 캐싱

• 캐시 안에 정보를 담아두고, 캐시 안에 있는 정보를 요구하는 요청에 대해 다시 저 멀리 있는 원격 서버에 요청하지 않고 캐시 안에 있는 데이터를 활용하는 것
• 이를 통해 불필요하게 외부와 연결하지 않기 때문에 트래픽을 줄일 수 있음

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

1. nginx: 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버, 주로 Node.js 서버 앞단의 프록시 서버로 활용됨

2. CloudFlare : 전 세계적으로 분산된 서버가 있고 이를 통해 어떠한 시스템의 콘텐츠 전달을 빠르게 할 수 있는 CDN 서비스

• DDOS 공격 방어 : 짭은 기간동안 네트워크에 많은 요청을 보내 네트워크를 마비시켜 웹 사이트의 가용성을 방해하는 사이버 공격
• HTTPS 구축 : 별도의 인증서 설치없이 손쉽게 HTTPS 구축 가능

※ CDN(Content Delivery Network): 각 사용자가 인터넷에 접속하는 곳과 가까운 곳에서 콘텐츠를 캐싱 또는 배포하는 서버 네트워크를 말함, 콘텐츠 다운로드 시간을 줄일 수 있음

 

CORS(Cross-Origin Resource Sharing) : 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘

※ 오리진: 프로토콜과 호스트 이름, 포트의 조합

---

6. 이터레이터 패턴(iterator pattern)

• 이터레이터(iterator)를 사용하여 컬렉션(collection)의 요소들에 접근하는 디자인 패턴
• 이를 통해 순회할 수 있는 여러가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스 순회가 가능
• ex) set과 map같은 다른 자료구조도 똑같은 for a of b를 이터레이터 프로토콜을 통해 순회하는 것

---

7. 노출모듈 패턴(revealing module pattern)

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
• public : 클래스에 정의된 함수에서 접근 가능하며 자식 클래스와 외부 클래스에서 접근 가능한 범위
• protected : 클래스에 정의된 함수에서 접근 가능, 자식 클래스에서 접근 가능하지만 외부 클래스에서 접근 불가능한 범위
• private : 클래스에 정의된 함수에서 접근 가능하지만 자식 클래스와 외부 클래스에서 접근 불가능한 범위
• 즉시 실행 함수 : 함수를 정의하자마자 바로 호출하는 함수, 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용

---

8. MVC 패턴

• 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴
• 모델 : 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등
• 뷰 : 모델을 기반으로 사용자가 볼 수 있는 화면(input box, checkbox, testarea 등)
• 컨트롤러 : 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할, 이벤트 등 메인 로직을 담당
• ex) 스프링(Spring)

---

9. MVP 패턴

• MVC 패턴으로부터 파생되었으며 MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체된 패턴

---

10. MVVM 패턴

• MVC의 C에 해당하는 컨트롤러가 뷰모델(view model)로 바뀐 패턴
• 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
• 커맨드 : 여러가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법
• 데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법, 뷰모델을 변경하면 뷰가 변경됨

 

---

SECTION 2 프로그래밍 패러다임

프로그래밍 패러다임(programmin paradigm) : 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

프로그래밍 패러다임의 분류

 

1. 선언형(declarative)과 함수형(functional) 프로그래밍(programin)

• 작은 '순수 함수'들을 블록처럼 쌓아 로직을 구현하고 '고차 함수'를 통해 재사용성을 높인 프로그래밍 패러다임
• 순수 함수 : 출력이 입력에만 의존하는 것
• 고차 함수 : 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것

---

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

• 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
• 설계에 많은 시간이 소요되며 처리 속도가 다른 프로그래밍 패러다임에 비해 상대적으로 느림

객체지향 프로그래밍의 특징
추상화(abstraction)	복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려 내는 것
캡슐화(encapsulation)	객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
상속성(inheritance)	상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
다형성(polymorphism)	하나의 메서드나 클래스가 다양한 방법으로 동작하는 것(ex. 오버로딩, 오버라이딩)

오버로딩(overloading) : 같은 이름을 가진 메서드를 타입/매개변수의 유형 및 개수 등으로 여러 개를 두는 것, '정적' 다형성
오버라이딩(overridin) : 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의 하는 것, '동적' 다형성

 

설계원칙
단일 책임 원칙(SRP, Single Responsibility Principle)	모든 클래스는 각각 하나의 책임만 가져야 하는 원칙
개방-폐쇄 원칙(OCP, Open Closed Principle)	유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 떄는 닫혀 있어야 하는 원칙
리스코프 치환 원칙(LSP, Liskov Substitution Principle)	프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는
인터페이스 분리 원칙(ISP, Interface Segregation Principle)	하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙
의존 역전 원칙(DIP, Dependency Inversion Principle)	자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙

---

3. 절차형 프로그래밍

• 로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있음
• 장점 : 코드의 가독성이 좋으며 실행속도가 빠름 -> 계산이 많은 작업에 사용(ex. 머신 러닝의 배치 작업, 연산 작업)
• 단점 : 모듈화하기가 어렵고 유지 보수성이 떨어짐

---

4. 패러다임의 혼잡

• 비즈니스 로직이나 서비스의 특징을 고려해서 패러다임을 정하는 것이 좋음
• 하나의 패러다임을 기반으로 통일하여 서비스를 구축하는 것도 좋은 생각이지만 여러 패러다임을 조합하여 상황과 맥락에 따라 패러다임 간의 장점만 취해 개발하는 것이 좋음
• ex) 백엔드에 머신 러닝 파이프라인과 거래 관련 로직이 있는 경우 -> 머신 러닝 파이프라인은 절차지향형 패러다임, 거래관련 로직은 함수형 프로그래밍 적용

 

---

참고문서 : 면접을 위한 CS 전공지식 노트