20230317 기술 면접 스터디

HYEON17·2023년 3월 15일
0

TIL

목록 보기
7/17
post-thumbnail

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

1.1 디자인 패턴

1.1.1 싱글톤 패턴

해당 클래스의 인스턴스가 오직 하나만 생성되도록 보장하고 이를 전역적으로 제공하는 디자인 패턴입니다. 여러 번의 인스턴스 생성으로 인한 자원 낭비를 막을 수 있으며, 하나의 인스턴스를 공유하여 사용하므로 객체 간 정보 교환에 용이

장점과 단점

장점
  1. 하나의 인스턴스만 생성됩니다. 싱글톤 패턴을 사용하면 전역적으로 하나의 인스턴스만 생성되기 때문에, 메모리를 절약할 수 있습니다.

  2. 전역적인 접근이 가능합니다. 자바스크립트에서 전역 변수를 사용하면 전역적으로 접근 가능하지만, 이는 전역 네임스페이스 오염 문제를 발생시킬 수 있습니다. 하지만 싱글톤 패턴을 사용하면 전역적으로 접근 가능하면서도, 전역 네임스페이스 오염 문제를 방지할 수 있습니다.

  3. 객체 지향 프로그래밍의 원칙을 따릅니다. 싱글톤 객체는 전역적으로 사용되기 때문에, 단일 책임 원칙(Single Responsibility Principle)을 준수할 수 있습니다. 즉, 하나의 객체가 하나의 책임만을 지니기 때문에, 객체 지향 프로그래밍의 원칙을 잘 따르고 있습니다.

  4. 객체 생성과 소멸에 대한 비용을 줄일 수 있습니다. 객체 생성과 소멸에는 비용이 들기 때문에, 이러한 비용을 줄일 수 있는 싱글톤 패턴을 사용하면 프로그램의 성능을 향상시킬 수 있습니다.

단점
  1. 유연성이 떨어진다. 싱글톤은 전역적인 접근을 가능하게 하기 때문에, 다른 객체들과의 상호작용이 어렵다. 객체 간 결합도가 높아지고, 테스트가 어려워진다.

  2. 테스트가 어렵다. 싱글톤 객체가 전역적으로 접근 가능하기 때문에, 해당 객체에 의존하는 다른 객체들의 테스트를 진행할 때, 싱글톤 객체의 초기 상태를 설정하고 해제하는 작업이 필요하다.

  3. 멀티스레드 환경에서 안전하지 않다. 싱글톤 객체는 동시에 여러 스레드에서 접근 가능하기 때문에, 동기화 문제가 발생할 수 있다.

  4. 메모리 누수가 발생할 수 있다. 싱글톤 객체는 프로그램이 종료될 때까지 메모리를 차지하게 되는데, 이를 해제하지 않으면 메모리 누수가 발생할 수 있다.

의존성 주입

모듈 간의 결합을 강하게 만들 수 있다는 단점
의존성 주입(DI, Dependency Injection)을 통해 모듈 간의 결합을 조금 더 느슨하게 만들어 해결

의존성이란 종속성이라고도 한다
A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A 또한 변해야 된다는 것을 의미


의존성 주입자가 가로채 메인모듈이 간접적으로 의존성을 주입하는 방식
메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 된다
이를 디커플링이라고 한다

디커플링

각각의 컴포넌트나 모듈을 독립적으로 개발 및 수정할 수 있도록 만드는 것
이를 통해 시스템이나 구성 요소 간의 결합도(coupling)를 낮추고, 유연성과 확장성을 향상시킬 수 있습니다.

의존성 주입의 장점

모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅 하기 쉽고 마이그레이션하기도 수월
추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있으며, 모듈간의 관계들이 조금 더 명확해진다

의존성 주입의 단점

모듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 패널티가 생기기도 한다

의존성 주입 원칙

상위모듈은 하위모듈에서 어떠한 것도 가져오지 않아야 한다
둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 한다

1.1.2 팩토리 패턴

팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 만드는 패턴.

장점과 단점

장점
  1. 유지보수성이 높아집니다.
  2. 코드 중복을 피할 수 있습니다.
  3. 코드 확장성이 높아집니다.
  4. 객체 생성 코드가 감춰집니다.
단점
  1. 팩토리 클래스가 많아질 수 있습니다.
    팩토리 패턴을 사용하면서 팩토리 클래스가 많아질 수 있습니다. 이는 코드의 복잡도를 높일 수 있습니다.

  2. 객체 생성 메서드를 추가할 때, 팩토리 클래스를 수정해야 합니다.
    객체 생성 메서드를 추가할 때, 팩토리 클래스를 수정해야 합니다. 이는 코드 변경이 필요하므로 유연성이 떨어집니다.

  3. 객체 생성 메서드를 오버라이딩할 수 없습니다.
    자바스크립트에서는 클래스를 정의할 때 메서드를 오버라이딩할 수 있지만, 팩토리 패턴에서는 객체 생성 메서드를 오버라이딩할 수 없습니다.

1.1.3 전략 패턴

전략 패턴은 알고리즘을 캡슐화하여, 필요에 따라 서로 교환해서 사용할 수 있도록 만든 디자인 패턴입니다. 이를 통해 클라이언트는 각각의 알고리즘을 선택하여 사용할 수 있으며, 알고리즘의 변경이나 추가가 용이해지며 코드의 재사용성과 유지보수성이 좋아집니다.

장점

유연성: 전략 패턴은 알고리즘을 실행 중에 변경하거나 확장해야 할 때 유용합니다. 즉, 코드 수정 없이 새로운 알고리즘을 추가하거나 기존 알고리즘을 수정할 수 있습니다.

재사용성: 전략 패턴은 알고리즘을 클래스로 캡슐화하여 재사용성을 높입니다. 이러한 구조를 사용하면 알고리즘이 다른 클래스에서도 재사용될 수 있습니다.

테스트 용이성: 전략 패턴은 알고리즘을 캡슐화하고 인터페이스를 사용하여 각 알고리즘을 테스트하기 쉽습니다. 즉, 각각의 전략을 단위 테스트할 수 있으며, 코드의 결함을 발견하고 수정하기 쉽습니다

단점

복잡성: 전략 패턴은 추가적인 클래스와 인터페이스를 필요로 합니다. 이러한 클래스와 인터페이스는 코드의 복잡성을 증가시키므로, 작은 프로그램에서는 사용하지 않는 것이 좋습니다.

오버헤드: 전략 패턴은 실행 시간에 알고리즘을 변경하기 때문에 약간의 오버헤드가 발생할 수 있습니다. 이러한 오버헤드는 알고리즘이 간단한 경우 큰 문제가 되지 않지만, 알고리즘이 복잡한 경우 성능 저하를 초래할 수 있습니다.

선택의 어려움: 전략 패턴을 사용할 때 적절한 전략을 선택하는 것이 중요합니다. 올바른 전략을 선택하지 않으면 프로그램의 성능이 저하될 수 있습니다.

1.1.4 옵저버 패턴

객체의 상태 변화를 관찰하고, 이에 따른 처리를 다른 객체에게 알리는 디자인 패턴입니다. 이를 통해 객체 간의 의존성을 줄이고, 객체 간의 결합도를 낮출 수 있으며, 이를 통해 유연한 객체 지향 설계가 가능

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

프록시 패턴

객체의 대리자 역할을 하는 객체를 통해 객체의 접근을 제어하는 디자인 패턴입니다. 이를 통해 객체의 접근 제어, 객체의 생성과 삭제 등의 부가적인 작업을 수행할 수 있으며, 객체의 사용이 필요한 시점까지 객체의 생성을 지연할 수 있습니다

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

1.1.6 이터레이터 패턴

순차적으로 데이터에 접근하는 인터페이스를 제공하는 디자인 패턴
이를 통해 컬렉션 내부의 데이터에 접근할 수 있는 일관된 방법을 제공하며, 데이터에 대한 추상화 수준을 높이고, 컬렉션과 데이터에 대한 불필요한 종속성을 제거할 수 있습니다.

1.1.7 노출모듈 패턴

모듈의 내부 상태나 메서드를 숨기고, 일부 기능만 외부에 노출하는 디자인 패턴
모듈 간의 결합도를 낮추고, 모듈의 구현 세부 사항을 숨길 수 있으며, 코드의 가독성과 유지보수성이 향상

1.1.8 MVC 패턴

MVC 패턴은 Model + View + Controller를 합친 용어

1) 구조

  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
  • View : 사용자에서 보여지는 UI 부분입니다.
  • Controller : 사용자의 입력(Action)을 받고 처리하는 부분입니다.

2) 동작

MVC 패턴의 동작 순서는 아래와 같습니다.

사용자의 Action들은 Controller에 들어오게 됩니다.
Controller는 사용자의 Action를 확인하고, Model을 업데이트합니다.
Controller는 Model을 나타내줄 View를 선택합니다.
View는 Model을 이용하여 화면을 나타냅니다.

3) 특징

Controller는 여러개의 View를 선택할 수 있는 1:n 구조입니다.
Controller는 View를 선택할 뿐 직접 업데이트 하지 않습니다. (View는 Controller를 알지 못합니다.)

4) 장점

MVC 패턴의 장점은 널리 사용되고 있는 패턴이라는 점에 걸맞게 가장 단순합니다. 단순하다 보니 보편적으로 많이 사용되는 디자인패턴입니다.

5) 단점

MVC 패턴의 단점은 View와 Model 사이의 의존성이 높다는 것입니다. View와 Model의 높은 의존성은 어플리케이션이 커질 수록 복잡하지고 유지보수가 어렵게 만들 수 있습니다.

1.1.9 MVP 패턴

MVP 패턴은 Model + View + Presenter를 합친 용어입니다. Model과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 존재합니다.

1) 구조

  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
  • View : 사용자에서 보여지는 UI 부분입니다.
  • Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분입니다. View와 Model을 붙여주는 역할을 합니다.

2) 동작

MVP 패턴의 동작 순서는 아래와 같습니다.

사용자의 Action들은 View를 통해 들어오게 됩니다.
View는 데이터를 Presenter에 요청합니다.
Presenter는 Model에게 데이터를 요청합니다.
Model은 Presenter에서 요청받은 데이터를 응답합니다.
Presenter는 View에게 데이터를 응답합니다.
View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.

3) 특징

Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 합니다.
Presenter와 View는 1:1 관계입니다.

4) 장점

MVP 패턴의 장점은 View와 Model의 의존성이 없다는 것입니다. MVP 패턴은 MVC 패턴의 단점이었던 View와 Model의 의존성을 해결하였습니다. (Presenter를 통해서만 데이터를 전달 받기 때문)

5) 단점

MVC 패턴의 단점인 View와 Model 사이의 의존성은 해결되었지만, View와 Presenter 사이의 의존성이 높은 가지게 되는 단점이 있습니다. 어플리케이션이 복잡해 질 수록 View와 Presenter 사이의 의존성이 강해지는 단점이 있습니다.

1.1.10 MVVM 패턴

MVVM 패턴은 Model + View + View Model를 합친 용어입니다. Model과 View은 다른 패턴과 동일합니다. MVVM 패턴의 구조, 동작, 특징, 장점, 단점을 이야기하겠습니다.

1) 구조

  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
  • View : 사용자에서 보여지는 UI 부분입니다.
  • View Model : View를 표현하기 위해 만든 View를 위한 Model입니다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분입니다.

2) 동작

MVVM 패턴의 동작 순서는 아래와 같습니다.

사용자의 Action들은 View를 통해 들어오게 됩니다.
View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달합니다.
View Model은 Model에게 데이터를 요청합니다.
Model은 View Model에게 요청받은 데이터를 응답합니다.
View Model은 응답 받은 데이터를 가공하여 저장합니다.
View는 View Model과 Data Binding하여 화면을 나타냅니다.

3) 특징

MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.

Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴습니다.

View Model과 View는 1:n 관계입니다.

4) 장점

MVVM 패턴은 View와 Model 사이의 의존성이 없습니다. 또한 Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성 또한 없앤 디자인패턴입니다. 각각의 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있습니다.

5) 단점

MVVM 패턴의 단점은 View Model의 설계가 쉽지 않다는 점입니다.

1.2 프로그래밍 패러다임

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

  • 프로그램을 수학적인 함수들의 조합으로 구성하는 방법
  • 함수형 프로그래밍에서는 상태를 변경하는 명령형 프로그래밍과 달리, 입력값을 받아 출력값을 반환하는 순수 함수(pure function)를 중심으로 프로그래밍
  • 순수 함수는 같은 입력에 대해 항상 같은 출력을 반환하며, 함수 내부에서 외부의 상태를 변경하지 않기 때문에 병렬성과 안정성, 테스트 용이성 등의 장점이 있습니다. 또한, 함수형 프로그래밍에서는 데이터의 상태 변화를 추적하기 위해 변수 대신 불변성 데이터 구조를 사용하고, 고차 함수(higher-order function)를 활용하여 코드의 재사용성을 높입니다.

1.2.2 객체지향 프로그래밍

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

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

추상화

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

캡슐화

객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉

상속성

상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것을 말한다
코드의 재사용 측면, 계층적인 관계 생성, 유지 보수성 측면에서 중요

다형성

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

오버로딩

같은 이름을 가진 메서드를 여러개 두는 것을 말한다

오버라이딩

상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것을 의미

설계 원칙

단일 책임 원칙

모든 클래스는 각각 하나의 책임만 가져야 하는 원칙

개방-폐쇠 원칙

유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 하는 원칙

리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것을 의미

인터페이스 분리 원칙

하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙

의존 역전 원칙

자신보다 변하기 쉬운것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙

1.2.3 절차형 프로그래밍

장점: 코드의 가독성이 좋으며 실행속도가 빠르다
단점: 모듈화하기가 어렵고 유지 보수성이 떨어진다

질문

질문 리스트

1

질문: MVC 패턴과 MVP 패턴, MVVM 패턴의 차이점은 무엇인가요?
답변: MVC 패턴, MVP 패턴, MVVM 패턴은 UI 구현 방법 중에 가장 대표적인 패턴입니다. 이 세 가지 패턴은 모두 UI와 비즈니스 로직의 분리를 위해 고안된 패턴입니다.

MVC 패턴은 모델, 뷰, 컨트롤러 세 가지 요소로 이루어져 있습니다. 모델은 데이터를 처리하고, 뷰는 UI를 담당하고, 컨트롤러는 뷰와 모델 간의 상호작용을 조정합니다.

MVP 패턴은 모델, 뷰, 프리젠터 세 가지 요소로 이루어져 있습니다. MVP 패턴은 컨트롤러 대신에 프리젠터라는 개념이 도입됩니다. 프리젠터는 뷰와 모델 사이의 중개자 역할을 하며, 뷰와 모델을 분리하여 유지보수성을 높입니다.

MVVM 패턴은 모델, 뷰, 뷰모델 세 가지 요소로 이루어져 있습니다. 뷰모델은 뷰와 모델 간의 인터페이스로서, 뷰와 모델을 느슨하게 결합시켜주는 역할을 합니다. 또한 데이터 바인딩을 통해 뷰와 뷰모델 사이의 상호작용을 단순화하여 코드의 가독성과 유지보수성을 높입니다.

2

질문: 싱글톤 패턴이란 무엇이며, 어떤 상황에서 사용할 수 있나요?
답변: 싱글톤 패턴은 애플리케이션에서 특정 클래스의 인스턴스가 하나만 생성되도록 보장하는 디자인 패턴입니다. 이 패턴을 사용하면, 메모리를 절약할 수 있고, 데이터 일관성을 유지할 수 있습니다. 예를 들어, 데이터베이스 연결을 담당하는 클래스에서 싱글톤 패턴을 사용하면, 데이터베이스 연결 객체가 여러 개 생성되는 것을 방지할 수 있습니다.

3

질문: 객체지향 프로그래밍과 절차형 프로그래밍의 차이점은 무엇인가요?
답변: 객체지향 프로그래밍은 데이터와 데이터를 처리하는 메서드를 하나의 객체로 묶어서 관리합니다. 이는 문제를 객체의 집합으로 분해하고, 각각의 객체가 자신의 상태를 캡슐화하고 독립적으로 동작하도록 하는 것을 목표로 합니다. 이와 달리, 절차형 프로그래밍은 순차적인 명령어들의 집합으로 구성된 함수와 변수들의 집합으로 문제를 해결합니다. 즉, 절차적인 방법으로 문제를 해결하는 것이 주 목적입니다.

객체지향 프로그래밍은 코드의 재사용성과 유지보수성이 뛰어나며, 코드의 가독성을 높일 수 있습니다. 또한 클래스의 상속과 다형성을 이용하여 복잡한 문제를 쉽게 해결할 수 있습니다. 반면에, 절차형 프로그래밍은 프로그램의 실행 순서가 명확하고, 디버깅이 쉽다는 장점이 있습니다. 하지만 대규모 프로젝트에서는 코드의 복잡성과 유지보수성이 떨어질 수 있습니다.

나에게 온 질문

답변

profile
프론트엔드 개발자

0개의 댓글