Object Oriented Programming
객체지향 프로그래밍
- 인간 중심적 프로그래밍 패러다임. 즉, 현실세계를 프로그래밍으로 옮겨와 프로그래밍하는 것
- 현실 세계의 사물들을 객체라 보고 그 객체로부터 개발하고자 하는 애플리케이션에 필요한 특징들을 뽑아와 프로그래밍 하는 것 (추상화)
- 자주 사용되는 로직을 라이브러리로 만들어두면 계속해서 사용할 수 있어 재사용성이 높고 신뢰성 확보, 생산성 증가, 유지보수 용이
- 객체 간 정보 교환이 모두 메시지 교환을 통해 일어나므로 실행 시스템에 많은 overhead가 발생
- 객체가 상태를 가져 변수가 존재하고 이 변수를 통해 객체가 예측할 수 없는 상태를 갖게 되어 애플리케이션 내부에서 버그 발생 > 함수형 패러다임 주목
설계 원칙
- SRP (Single Responsibility Principle) : 단일 책임 원칙
클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유여야 한다. - OCP (Open-Closed Principle) : 개방-폐쇄 원칙
확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다. - LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. - ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다. - DIP (Dependency Inversion Principle) : 의존 역전 원칙
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
함수형 프로그래밍
immutable vs mutable
immutable : 변경 불가능함. 값이 변결될 경우, 새로운 객체를 생성하고 변경된 값 주입
mutable : 해당 객체의 값이 변경될 경우, 값에 반영
first-citizen
함수 (function)는 일급 객체(first class citizen)으로 간주
일급 객체
- 변수나 데이터 구조 안에 함수를 담을 수 있어 함수의 파라미터로 전달할 수 있고, 함수의 반환값으로 사용 가능
- 할당에 사용된 이름과 관계 없이 고유한 구별이 가능
- 함수를 리터럴로 바로 정의 가능
Reactive Programming
반응형 프로그래밍(Reactive Programming)은 선언형 프로그래밍(Declarative Programming)이라고도 불리며, 명령형 프로그래밍(Imperative Programming)의 반대말이다.
함수형 프로그래밍 패러다임을 활용한다.
반응형 프로그래밍은 기본적으로 모든 것을 stream으로 본다.
stream이란, 값들의 집합으로 볼 수 있으며 제공되는 함수형 메소드를 통해 테이터를 immutable하게 관리할 수 있다.
RESTful API
월드 와이드 웹(World Wide Web a.k.a WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴
REST
- REpresentational State Transfer
- ~ful 이라는 형용사형 어미를 붙여 ~한 API 라는 표현으로 사용된다. 즉, REST 의 기본 원칙을 성실히 지킨 서비스 디자인은 'RESTful'하다라고 표현할 수 있다.
- 디자인 패턴, 아키텍처 등으로 분류된다는 의견이 존재하는데, 하나의 아키텍처로 볼 수 있다. 좀 더 정확한 표현으로 말하자면, REST 는 Resource Oriented Architecture 이다. API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다.
REST 원칙
- Uniform Interface
- Stateless
- Caching
- Client-Server
- Hierarchical system
- Code on demand
RESTful하게 API를 디자인 한다는 의미
- 리소스와 행위를 명시적이고 직관적으로 분리
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
- 행위는 HTTP Method로 표현. GET(조회) POST(생성) PUT(기존 entity 전체 수정) PATCH(기존 entity 일부 수정) DELETE(삭제)를 분명한 목적으로 사용
- Message는 Header와 Body를 명확하게 분리해서 사용
- Entity에 대한 내용은 Body에 담는다.
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header에 담는다.
- header 와 body 는 http header 와 http body 로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있다.
- API 버전을 관리한다.
- 환경은 항상 변하기 때문에 API 의 signature 가 변경될 수도 있음에 유의
- 특정 API 를 변경할 때는 반드시 하위호환성을 보장
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json으로 보내거나 둘 다 form-data 형식으로 보내는 등의 하나로 통일한다.
- URI 가 플랫폼 중립적이어야 한다.
장점
- Open API 제공 용이
- 멀티 플랫폼 지원 밑 연동 용이
- 원하는 타입으로 데이터 공유 가능
- 기존 웹 인프라(HTTP) 사용 가능
단점
- 사용 가능한 메소드 4가지
- 분산 환경 부적합
- HTTP 통신 모델에 대해서만 지원
MVC
Controller
- 조정자 역할.
- 클라이언트의 요청을 받았을 때, 요청에 대해 실제 업무를 수행하는 모델 컴포넌트 호출
- 클라이언트가 보낸 데이터가 있으면, 모델에 전달하기 쉽게 데이터 가공
- 모델이 업무를 마치면 결과를 뷰에 전달
Model
-
컨트롤러 호출 시, 요청에 맞는 역할 수행
-
비즈니스 로직을 수현하는 영역으로, 응용프로그램에서 데이터를 처리하는 부분
비즈니스 로직
업무에 필요한 데이터 처리를 수행하는 응용 프로그램의 일부
-
DB에 연결하고 데이터를 추출하거나 저장, 삭제, 업데이트, 수정 등의 작업을 수행한다.
-
상태 변화 시, 컨트롤러와 뷰에 통보해 후속 조치 명령을 받을 수 있게 한다.
View
- 컨트롤러로부터 받은 모델의 결과값을 가지고 사용자에게 출력할 화면을 제공
- 사용자와의 상호작용을 위한 인터페이스를 표시하는 영역
