⇒ OOP란 컴퓨터 프로그래밍 방법론이다. 프로그램을 여러 개의 독립된 단위인 객체로 나누고 객체들의 상호작용으로 프로그램을 구성하는 프로그래밍 방법이다. 객체들은 메시지를 주고 받으며 데이터를 처리한다.
⇒ OOP의 특징으로는 캡슐화, 정보 은닉, 다형성, 추상화, 상속, 동적 바인딩의 특징이 있다.
⇒ OOP의 원칙으로는 SOLID 원칙이 있다.
1. SRP
=> OCP 약화
자식 클래스 규칙에 부합하지 않는 부모 클래스 메소드가 존재하고, 그 메소드가 의도치 않게 자식 클래스의 코드에서 동작한다면 문제가 발생한다.
완벽한 캡슐화를 원하면 상속을 포기하거나 적절한 private 사용을 해야한다.
=> 설계가 유연하지 않아진다
상속하면 자식과 부모 클래스 간의 의존성이 생긴다.
결합도가 높다면 부모 클래스의 변경으로 자식 클래스가 취약해질 수 있다.
=> LSP 위배
잘못된 상속은 캡슐화 약화, 결합도 상승 문제로 LSP를 위반한다.
자식 클래스와 부모 클래스가 HAS-A 관계면 컴포지션 패턴을 사용한다.
⇒ REST API는 REST 아키텍처 스타일의 조건을 준수하는 웹 서비스와 통신할 수 있는 API이다.
REST 설계 규칙은 URI는 정보의 자원만 표현해야 하며, 자원의 상태와 행위는 HTTP Method에 명시하는걸 말한다.
⇒ 쉬운 사용성을 가진다. REST API의 메시지를 읽는 것 만으로 메시지의 의도를 파악할 수 있다.
REST 형식을 이용한 개발이 익숙하다.
JSON 형식을 응답하는 API 개발을 했는데 REST API가 잘 어울렸다.
=> grpc
ProtoBuf가 지원하는 IDL을 활용한 서비스 및 메시지 정의는 MSA에서 다양한 기술 스택의 공존으로 인해 중복이 발생한다는 단점을 보완하고 수많은 서비스 간의 API 호출로 인한 성능 저하를 개선한다.
ProtoBuf에 의한 높은 메시지 압축률로 시스템 전체에서의 네트워크 트래픽을 줄여준다.
=> GraphQL API 는 주로 전체 API를 위해서 하나의 Endpoint 를 사용한다.
RESTful API 는 Resource 마다 하나의 Endpoint 를 가지고, 그 Endpoint 에서 그 Resource 에 대한 (거의) 모든 것을 담당한다.
Restful API 로는 다양한 기종에서 필요한 정보들을 일일히 구현하는 것이 힘들었다.
예를 들어 IOS 와 Android 에서 필요한 정보들이 조금씩 달랐고, 그 다른 부분마다 API를 구현하는 것이 힘들었다.
=> REST 스타일을 정확히 지키기 어렵다.
표준 규약이 없어 관리가 쉽지 않다.