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

디자인 패턴

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

1. 싱글톤 패턴 (Singleton pattern)

• 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
• 데이터베이스 연결 모듈에 많이 사용
• 인스턴스를 공유하며 사용하기 때문에 생성에 드는 비용이 줄어드는 장점
• 의존성이 높아진다는 단점 / TDD에 부적합 / 의존성 주입 (DI) 를 통해 해결 가능
• 의존성 주입 시 장점
  • 모듈을 쉽게 교체할 수 있어 테스팅, 마이그레이션이 쉬움
  • 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있으며 모듈간의 관계가 명확함
• 의존성 주입 시 단점
  • 모듈들의 분리로 인한 복잡성 증가, 런타임 패널티
• 의존성 주입 원칙
  • 상위 모듈은 하위모듈에서 가져오지 않아야 함
  • 추상화에 의존해야 하며, 추상화는 세부사항에 의존하지 말아야 함

2. 팩토리 패턴 (Factory pattern)

• 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화 한 패턴
• 상속관계에 있는 두 클래스에서 상위 클래스는 뼈대, 하위 클래스는 구체적인 내용을 결정하는 패턴
• 상위, 하위 클래스의 분리로 인해 유연성을 가지고, 유지보수가 용이함

3. 전략 패턴, 정책 패턴 (Strategy pattern, Policy pattern)

• 객체의 행위를 바꾸고 싶은 경우 직접 수정이 아닌 '전략'이라 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 교체가 가능하게 만드는 패턴
• 결제 시 카드의 종류를 골라 결제하는 방식으로 이해
• node.js passport 인증 모듈이 해당 패턴을 활용

4. 옵저버 패턴 (Observer pattern)

• 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 생길 때마다 메소드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
• 주체란 관찰자, 옵저버란 변화 사항이 생기는 객체
• JS에서 프록시 객체를 활용해 옵저버 패턴 구현
• 주로 이벤트 기반 시스템에 사용되며 MVC패턴에 사용됨

5. 프록시 패턴 (Proxy pattern)

• 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 패턴
• 객체의 속성, 변환 등을 보완하며 보안, 데이트 검증, 캐싱, 로깅에 사용
• 프록시 서버란
  • 서버 앞단에서 캐싱, 로깅, 데이터 분석을 메인 서버보다 먼저하는 서버
    • DDOS 공격 방어, 캐싱 처리에 용이

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

• 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 패턴
• 하나의 인터페이스로 순회가 가능

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

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

8. MVC 패턴

• 모델, 뷰, 컨트롤러로 이루어진 패턴
• 재사용성, 확장성이 용이, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡
• React.js

9. MVP 패턴

• MVC보다 더 강한 결합을 지닌 패턴

10. MVVM 패턴

• 뷰와 뷰모델 사이의 양방향 바인딩 / 단위 테스팅이 쉬움
• Vue.js

프로그래밍 패러다임

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

1. 함수형 프로그래밍 (Functional Programming)

• 상태 값을 지니지 않는 함수 값들의 연속으로 생각
• 선언형 패러다임의 일종
• 순수함수 - 출력이 입력에만 의존하는 함수
• 고차함수 - 함수가 함수를 매개변수로 받아 로직을 생성할 수 있는 것
• 일급 객체
  • 변수나 메소드에 함수를 할당할 수 있음
  • 함수 안에 함수를 매개변수로 담을 수 있음
  • 함수가 함수를 반환할 수 있음

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

• 객체들의 집합으로 프로그램의 상호 작용을 표현
• 데이터를 객체로 취급하여 객체 내부에 선언된 메소드를 활용하는 방식
• 설계에 많은 시간이 소요되며 처리 속도가 다른 패러다임에 비해 상대적으로 느림
• 특징
  • 추상화(abstraction) - 복잡한 시스템으로부터 핵심적인 개념 또능 기능을 간추려내는 것
  • 캡슐화(encapsulation) - 객체의 속성과 메소드를 하나로 묶고 일부를 외부에 감춰 은닉하는 것
  • 상속성(inheritance) - 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장
  • 다형성(polymorphism) - 하나의 메소드나 클래스가 다양한 방법으로 동작하는 것 / 오버로딩, 오버라이딩
• 설계 원칙
  • SOLID 원칙 - 객체지향 프로그래밍을 설계할 때 지켜야 할 원칙
  1. 단일 책임 원칙 (SRP, Single Responsibility Principle)
     • 모든 클래스는 각각 하나의 책임만을 가져야 함
  2. 개방-폐쇄 원칙 (OCP, Open Closed Principle)
     • 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 함
  3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)
     • 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함
  4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
     • 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 함
  5. 의존 역전 원칙 (DIP, Dependency Inversion Principle)
     • 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 함

3. 절차형 프로그래밍

• 로직이 수행되어야 할 연속적인 계산과정으로 이루어 짐
• 가독성이 좋고 실행 속도가 빠름 - 계산이 많은 작업에 주로 사용, 포트란(fortran)
• 모듈화와 유지보수가 어려움

 

출처: 면접을 위한 CS 전공지식 노트