기술면접 준비하기-2

HeumHeum2·2020년 4월 19일

기술면접

목록 보기

2/5

Object Oriented Programming(OOP)이란 무엇인가요?

객체 지향 프로그래밍. 이전에는 컴퓨터가 사고하는대로 프로그래밍을 하는 패러다임이였다면, 객체 지향 프로그래밍은 인간 중심적 프로그래밍 패러다임이라고 합니다.
학교를 예를 들면, 학생, 과목, 선생 등 현실 세계에서 객체들의 필요한 특징들을 뽑아와 프로그래밍하는 것을 말합니다. 이것을 객체 지향 프로그래밍의 특징인 추상화라고 합니다.
다른 키워드로는 클래스/인스턴스, 캡슐화, 상속성, 다형성이 있습니다.

장점
- 코드에 대한 재사용이 용이하다.
- 객체 단위로 코드가 나눠져 작성되기 때문에 디버깅이 쉽다.
- 유지보수에 용이하다.
- 클래스단위로 모듈화 시켜서 개발할 수 있으므로, 업부 분담 용이하다.
단점
- 처리속도가 상대적으로 느리다.
- 객체가 많으면 용량이 커질 수 있다.
- 설계 시 많은 시간과 노력이 필요하다.
- 객체가 상태를 갖기에, 변수가 존재하고 변수를 통해 객체가 예측할 수 없는
  상태를 갖게되면, Application 내부에서 버그를 발생시킵니다.

추상화
공통의 속성이나 기능을 묶어 이름을 붙이는 것을 말합니다. (객체지향 관점에서는 클래스를 정의합니다.)

클래스/인스턴스

클래스
- 문제를 해결하기 위한 데이터를 만들기 위해 추상화를 거쳐,
  집단에 속하는 속성(attribute)과 행위(behavior)를 변수와 메소드로 정의한 것입니다.
인스턴스(객체)
- 클래스에서 정의한 것을 토대로 실제 메모리상에 할당된 것으로 실제 데이터입니다.

캡슐화
코드를 재수정 없이 재활용하기 위해 관련된 기능과 특성을 한 곳에 모으고 분류한 것입니다.
즉, 객체 지향 프로그래밍에서 기능과 특성을 한 곳에 모은 클래스를 캡슐에 분류한 것을 말합니다. 타인이 외부에서 조작을 대비해 외부에서 특정 속성이나 메서드를 사용자가 사용할 수 없도록 숨겨놓는 기능도 합니다.

상속성
부모클래스의 속성과 기능을 그대로 이어받아 사용할 수 있고, 기능의 일부분을 변경해야 할 경우 상속받은 자식클래스에서 해당 기능만 수정 및 정의하여 사용 할 수 있습니다.

다형성
하나의 변수명, 함수명 등이 상황에 따라 다른 의미로 해석될 수 있는 것을 말합니다.
자식클래스가 부모클래스의 상속을 받고 있으면 부모의 속성을 가져다가 사용할 수 있지만,
자식클래스의 상황에 맞지 않을 때, Overriding을 통해 해당 클래스에서만 속성을 재정의 할 수 있습니다.
같은 이름의 함수를 사용하나, 매개변수의 종류를 다르게 선언하는 것으로 다양한 매개변수를 받을 수 있는 Overloading도 있습니다.

참고 > https://jeong-pro.tistory.com/95

Functional Programming이란 무엇인가요?

객체 지향 프로그래밍에서는 멤버변수의 상태를 공유하고, 상태를 변경함으로써 예상치 못한 버그를 일으킬 수 있습니다.
이를 보안한 함수형 프로그래밍은 불변성 으로 선언한 값을 복사해 변경하므로, 반환되는 값이 예측이 가능하다는 장점이 있습니다. 또한, 상태를 공유하기보다는 반환되는 값을 이용해 함수를 사용하기에 프로그램의 실행에 있어 영향을 끼치지 않습니다.
이것을 고차 함수(High-Order Function), 순수 함수(Pure Function) 라고 합니다.
고차 함수는 1급 함수의 부분집합입니다. 따라서 함수를 변수에 할당할 수 있으며, 매개변수로 전달 할 수 있고 함수를 반환할 수도 있습니다.
이처럼 어떤 방법 으로 해야하는지를 나타내기보다 무엇 과 같은지 생각하는 것을 우리는 선언형 이라고 합니다.

참고 > https://velog.io/@kyusung/함수형-프로그래밍-요약

RESTful API란 무엇인가요?

REST란
웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.
구체적으로는 HTTP URI를 통해 어떤 자원인지 명시하고, HTTP Method(GET, POST, PUT, PATCH, DELETE)를 통해 해당 자원을 처리하도록 설계된 것입니다.

6가지 원칙

Uniform Interface(인터페이스 일관성)
- URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 것을 말합니다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.
Stateless(무상태)
- 세션 정보나 쿠키를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만
  단순히 수행합니다.
- 이전 요청이 다음 요청의 처리에 연관되면 안됩니다. (이전 요청이 DB를 수정해 바뀌는 것 제외)
- 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이
  단순해집니다.
Cacheable(캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있습니다.
- HTTP가 가진 캐싱 기능 적용이 가능합니다. 그렇기에 대량의 요청을 효율적으로 처리 할 수 있습니다.
Client-Server(클라이언트-서버 구조)
- Client는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하고 책임집니다.
- REST 서버는 API 제공하고 비즈니스 로직 처리 및 저장을 책임집니다.
- 각각의 역할이 확실히 구분되기 때문에 서로 간 의존성이 줄어듭니다.
Layered System(계층화)
- Client는 REST API Server만 호출합니다.
- REST API Server는 다중 계층으로 구성됩니다.
  - 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있습니다.
  - PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.
Code-On-Demand(Optional)
- Server가 네트워크를 통해 Client에 프로그램을 전달하면 Client에서 실행될 수 있어야합니다.
- 반드시 충족할 필요는 없습니다.

REST API란
API(Application Programming Interface)란 프로그램과 또 다른 프로그램을 연결해주는 일종의 다리라고 볼 수 있습니다. REST기반으로 서비스 API를 구현한 것입니다.
즉, HTTP 요청을 보낼 때, 어떤 URI에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속입니다.

REST API 설계 기본 규칙

URI는 정보의 자원을 표현해야합니다.
- 동사보다는 명사를, 대문자보다는 소문자
- 자료에 따라 단수 명사, 복수 명사 구분
자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현합니다.
- URI에 HTTP Method가 들어가면 안됩니다.
- URI에 행위에 대한 동사 표현이 들어가면 안됩니다.
- 경로 부분 중 변하는 부분은 유일한 값으로 대체

REST API 설계 규칙

슬래시 구분자( / )는 계층 관계를 나타내는데 사용합니다.
URI 마지막 문자로 슬래시( / )를 포함하지 않습니다.
하이픈( - )은 URI 가독성을 높이는데 사용합니다.
밑줄( _ )은 URI에 사용하지 않습니다.
URI 경로에는 소문자가 적합합니다.
파일확장자는 URI에 포함하지 않습니다.

응답상태코드

1xx : 정보 응답
2xx : 성공 응답
3xx : 리다이렉션 메시지
4xx : 클라이언트 에러 응답
5xx : 서버 에러 응답

RESTful이란
RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다.
'REST API'를 제공하는 웹 서비스를 'RESTful'하다고 할 수 있습니다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아닙니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됩니다.

참고 >
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

call, apply의 차이점은 무엇인가요?

둘다 함수 호출 방법으로 call은 단일인자가 들어가며, apply는 배열을 들어갑니다.

Framework와 Library의 차이점은 무엇인가요?

Framework
필수적인 코드, 데이터베이스 연동 등 개발을 할 때 필요한 기본 구조를 제공해줍니다. 개발자들은 그 위에서 코드를 작성해 Application을 완성해야합니다.

Library
Library는 특정 기능이나 함수들을 모은 도구입니다. 개발자들은 필요한 기능들을 찾아 Application에 추가해 이용할 수 있습니다.

차이점
Framework는 기본 구조 위에 필요한 코드들을 작성하여 Application을 완성하는 반면, Library는 프로그래머가 필요한 상황에 적절한 Library를 가져다 쓰는 것의 차이가 있습니다.

MVC와 Flux의 디자인패턴 차이점은 무엇인가요?

MVC 디자인패턴

M은 Model로 응용프로그램의 동작 및 데이터를 관리합니다.
V는 View로 UI를 화면에 표출시킵니다.
C는 Controller로 사용자에게 입력을 받아 Model을 조작하고, View를 업데이트 시킵니다.

간단한 웹사이트에서는 여전히 사용 가능하지만, Facebock같은 많은 Model들이 필요할 때 문제가 생겼습니다. 그 이유는, 양방향 통신으로 코드 하나를 변경하면 루프백되어 전체 코드에 영향을 미쳤습니다. 결국 코드를 디버깅하기 어려워지게 만들었습니다.

Flux 디자인패턴
Flux는 Action, Store, Dispatcher, View가 있습니다.

Action은 type속성과 일부 데이터가 있는 단순한 객체입니다.
Store는 상태값을 저장하고 있는 저장소입니다.
Dispatcher는 일종의 허브역할로 Action의 type 속성을 읽어 Store에 등록된 콜백함수를 호출합니다.
View는 Store가 변경된 상태를 알려주면 해당 부분만 리렌더링합니다.

MVC와 다르게 Component간의 데이터의 흐름을 단방향 통신으로 강제화 했습니다.

차이점

Flux에선 Component간의 데이터의 흐름이 단방향 통신으로 강제적, MVC에서는 흐름이 양방향 통신으로 강제적이지 않습니다.
Flux는 모든 변화는 Action을 거쳐 Dispatcher에서 실행됩니다. MVC는 Model과 View 서로 변화가 이루어집니다.
Store는 Model이 없어도 모든 상태가 저장 가능하며, MVC에서는 객체를 모델링합니다.

참고 > https://dogbirdfoot.tistory.com/14

HeumHeum2

커피가 본체인 개발자 ☕️

이전 포스트

기술면접 준비하기-1

다음 포스트