suhhyun.md

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

1.1 디자인 패턴

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

싱글톤 패턴

하나의 클래스에 오직 하나의 인스턴스만을 가지는 패턴, DB 연결 모듈에 많이 사용

• 장점: 하나의 인스턴스 공유 -> 생성 비용 줄어듦
• 단점: TDD에 걸림돌 -> 단위 테스트 시 독립적으로 수행하기 어려움 (<- 의존성 주입으로 모듈 간의 결합을 느슨하게 만들어 해결)
  • 의존성 주입: 외부에서 두 모듈 간의 관계를 동적으로 주입하는 것
    • 장점
      • 모듈 교체가 쉬움 -> 테스트, 마이그레이션 하기 쉬움
      • 애플리케이션 의존성 방향이 일관, 애플리케이션 추론이 쉬워짐
      • 모듈 관의 관계가 더 명확해짐
    • 단점
      • 모듈의 분리 -> 클래스 수가 늘어나 복잡해짐
      • 런타임 패널티가 생기기도 함
    • 원칙
      • 상위 모듈은 하위 모듈에서 어느 것도 가져오지 않아야 함
      • 상위 모듈과 하위 모듈 모두 추상화에 의존해야 함
      • 추상화는 세부 사항에 의존하지 말아야 함

팩토리 패턴

• 객체를 사용하는 코드에서 객체 생성 부분을 추상화로 분리
• 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정
• 상위 클래스와 하위 클래스 분리 -> 느슨한 결합
• 상위 클래스는 객체 생성 로직을 알 필요 없음 -> 유연성 증가
• 객체 생성 로직의 분리로 리팩토링 쉬워짐 -> 유지보수성 증가

전략 패턴(정책 패턴)

객체의 행위를 직접 수정하지 않고 전략이라고 불리는 캡슐화된 알고리즘을 컨텍스트 안에서 바꿔주며 상호 교체가 가능하게 만드는 패턴

옵저버 패턴

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

• 주체: 관찰자
• 옵저버: 메서드 등으로 추가 변화 사항이 생기는 객체
• 주체/객체를 따로 분리하지 않기도 함
• ex. 트위터

상속(extends)

• 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용, 추가 및 확장 가능
• 일반 클래스, abstract 클래스 기반 구현

구현(implements)

• 부모 인터페이스를 자식 클래스에서 반드시 재정의하여 구현
• 인터페이스 기반 구현

프록시 패턴과 프록시 서버

프록시 패턴

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

프록시 서버

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

• nginx
  • 직접적인 서버 접근 차단 -> 한 단계 추가로 보안 강화
  • 포트 감추기 가능
  • 메인 서버 앞단에서 로깅 가능
• CloudFlare: 웹 서버 앞단에 구축
  • DDOS 공격 방어
  • HTTPS 구축
• 프론트엔드에서의 프록시 서버
  • CORS 문제 해결 위해 사용

이터레이터 패턴

이터레이터를 이용해 컬렉션의 요소에 접근하는 디자인 패턴

노출모듈 패턴

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

MVC 패턴

Model, View, Controller로 이루어진 디자인 패턴

• 구성 요소를 세 가지로 구분하여 각각의 구성 요소에 집중하여 개발 가능

• 재사용성/확장성 용이

• 애플리케이션이 복잡해질수록 모델과 뷰의 관계도 복잡해짐

• 모델: 데이터베이스, 상수, 변수 등

• 뷰: 사용자 인터페이스 요소

• 컨트롤러: 모델과 뷰를 잇는 다리 역할, 메인 로직/생명주기 등 담당

MVP 패턴

MVC 패턴에서 파생, 컨트롤러 -> 프레젠터 뷰-프레젠터 일대일 관계

MVVM 패턴

컨트롤러 -> 뷰 모델 뷰 모델: 뷰를 더 추상화한 계층 커맨드와 데이터 바인딩을 가짐

1.2 프로그래밍 패러다임

프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

선언형

무엇을 풀어내는가에 집중

함수형 프로그래밍

작은 순수 함수들을 이용해 로직 구현, 고차 함수를 통해 재사용성 높인 프로그래밍 패러다임

• 순수 함수: 출력이 입력에만 의존
• 고차 함수: 함수를 매개변수로 받아 로직 생성
• 일급 객체
  • 변수나 메서드에 함수 할당 가능
  • 함수 안에 함수를 매개변수로 담을 수 있음
  • 함수가 함수 반환 가능

명령형

객체지향

객체들의 집합으로 프로그램의 상호작용 표현, 데이터를 객체로 취급하여 객체 내부 메서드를 활용

• 추상화: 복잡한 시스템에서 핵심 개념, 기능을 간추려 내는 것
• 캡슐화
• 상속성: 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용, 추가, 확장하는 것
• 다형성: 하나의 메서드, 클래스가 다양한 방법으로 동작하는 것
  • 오버로딩: 같은 이름을 가진 메서드가 여러 개
  • 오버라이딩: 상위 클래스에서 상속받은 메서드를 하위 클래스가 재정의하는 것
• 설계 원칙(SOLID)
  • 단일 책임 원칙: 모든 클래스는 하나의 책임만을 가짐
  • 개방-폐쇄 원칙: 확장에는 open, 수정에는 close
  • 리스코프 치환 원칙: 자식이 부모 객체 대체 가능
  • 인터페이스 분리 원칙: 하나의 일반적인 인터페이스보다 구체적인 여러개의 인스턴스 생성
  • 의존 역전 원칙: 하위 계층의 변경이 상위 계층에 영향을 끼치지 말아야 함

절차지향

• 로직이 수행되어야 할 연속적인 계산 과정으로 이루어짐, 가독성 good, 속도 빠름 -> 계산이 많은 작업
• ex) 머신러닝 배치 작업, 대기과학 관련 연산 작업
• 모듈화 어렵고 유지보수성 bad