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

1.1  디자인 패턴

1. 싱글톤 패턴(Singleton Pattern): 하나의 클래스에 하나의 인스턴스만 가지는 패턴. 데이터베이스 연결 모듈에 많이 사용. 인스턴스 생성 비용을 줄일 수 있지만 의존성이 증가하는 문제.

1-1. 단점: TDD(Test Driven Development)시 불리: TDD 시에는 보통 테스트가 서로 독립적이어야 하는데 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 독립적인 인스턴스 생성이 어려움

1-2. 의존성 주입(DI, Dependency Injection): 의존성이 증가하는 문제를 해결

※ 의존성 주입 원칙: 상위 모듈은 하위 모듈에서 어떠한 것도 가져올 수 없음. 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 않아야 함.

 

2. 팩토리 패턴(Factory Pattern): 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화하고 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 설정, 그리고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴

 

3. 전략 패턴(Strategy Pattern): 정책 패턴(Policy Pattern). 객체의 행위를 바꾸고 싶은 경우, 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴

 

4. 옵저버 패턴(Observer Pattern): 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴.

e.g., 트위터: 한 유저를 팔로워한 사람들에게 그 유저의 새로운 트윗을 알려준다.

e;g., MVC 패턴: Model에서 변경 사항이 생기면 옵저버인 View에게 알려주고 이를 기반으로 Controller가 작동

 

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

 

6. 이터레이터 패턴(Iterator Pattern): 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴

 

7. 노출 모듈 패턴(Revealing Module Pattern): 즉시 실행 함수를 통해 privatge, public과 같은 접근 제어자를 만드는 패턴

 

8. MVC 패턴: Model, View, Controller로 이루어진 디자인 패턴

- Model: 애플리케이션의 데이터인 데이터베이스, 상수, 변수

- View: inputbox, checkbox, textarea 등 사용자 인터페이스 요소. 모델을 기반으로 사용자가 볼 수 있는 화면. 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며 단순히 화면에 표시한 정보만 가지고 있어야 함. 변경이 일어나면 컨트롤러에 전달.

- Controller: 이벤트 등 메인 로직 담당. 모델과 뷰의 생명주기 관리. 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌.

 

View -> Controller: 유저 이벤트 / Controller -> View: 갱신

Model -> Controller: 알림 / Controller -> Model: 갱신

 

9. MVP 패턴: Model, View, Presenter로 이루어진 디자인 패턴

 

View -> Presenter: 유저 이벤트 / Presenter -> View: UI 갱신

Model -> Presenter: 모델 변경 / Presenter -> Model: 모델 갱신

-> 뷰와 프레젠터는 일대일 관계 => MVC 패턴보다 더 강한 결합

 

10. MVVM 패턴: Model, View, View Model로 이루어진 디자인 패턴

- View Model: View를 더 추상화한 계층

 

View Model -> View: 알림 / View <-> View Model: 양방향 데이터 바인딩

Model -> View Model: 알림 / View Model -> Model: 갱신

 

 

1.2 프로그래밍 패러다임

프로그래밍 패러다임

- 선언형

  - 함수형

- 명령형

  - 객체지향형

  - 절차지향형

 

1.2.1 함수형 프로그래밍: 순수 함수들을 블록처럼 쌓아 로직을 구현하고 고차 함수를 통해 재사용성을 높은 프로그래밍 패러다임

※ 순수 함수: 출력이 입력에만 의존하는 것

※ 고차 함수: 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것

 

1.2.2 명령형 프로그래밍

1.2.2.1 객체지향 프로그래밍: 데이터를 객체로 취급하여 객체 내부에 선언된 메소드를 활용하는 방식.

- 특징: 추상화, 캡슐화, 상속성, 다형성

  - 추상화: abstarction. 핵심적인 개념 또는 기능을 간추려내는 것.

  - 캡슐화: encapsulation. 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것

  - 상속성: inheritance. 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것.

  - 다형성: polymorphism. 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것. 오버로딩, 오버라이딩 등.

     - 오버로딩: 같은 이름을 가진 메서드를 여러 개 두는 것. 컴파일 중에 발생하는 정적 다형성.

     - 오버라이딩: 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것. 런타임 중에 발생하는 동적 다형성.

- 설계원칙: SOLID 원칙

  - S: 단일 책임 원칙(SRP, Single Responsibility Principle). 모든 클래스는 각각 하나의 책임만 가져야 하는 원칙.

  - O: 개방-폐쇄 원칙(OCP, Open-Closed Principle). 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 하는 원칙. 즉, 기존의 코드는 변경을 최소화하면서 확장은 쉽게 할 수 있도록 하는 원칙.

  - L: 리스코프 치환 원칙(LSP, Liskov Substitution Principle). 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 원칙. 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가도록 해야하는 원칙.

  - I: 인터페이스 분리 원칙(ISP, Interface Segregation Principle). 하나의 일반적인 인터페이스를 만드는 대신, 여러 개로 분리해서 인터페이스를 만들어야 하는 원칙.

  - D: 의존 역전 원칙(DIP, Dependency Injection Principle). 상위 계층이 하위 계층의 변화에 대한 구현으로부터 독립해야 하는 원칙.

 

1.2.2.2 절차지향 프로그래밍: 로직이 수행되어야 할 연속적인 계산과정으로 이루어져 있음. 일이 진행되는 방식으로 그저 코드를 구현하기만 하면 되기 때믄에 코드의 가독성이 좋으며 실행속도가 빠름. 모듈화하기 어렵고 유지 보수성이 떨어진다는 단점이 있음.