1)객체지향 프로그래밍(OOP)란

객체지향 프로그래밍은 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고, 그 객체들간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.

즉, 상태와 행위를 가진 객체들을 레고 블럭처럼 조립해서 하나의 프로그램을 만드는 것을 객체지향 프로그래밍 이라고 할 수 있다.

객체지향 프로그램은 코드 재사용 및 유지보수가 용이하고, 대규모 프로젝트에 적합하다는 장점이 있다.
반면, 처리 속도가 상대적으로 느리고 객체의 수가 증가함에 따라 용량이 커질 수 있수 있다.
또한 현실을 잘 반영하기 위해서는 설계시 많은 시간과 노력이 필요하다는 단점이 있다.

1-1) 객체지향의 4가지 특징

1) 추상화
구체적인 사물들의 공통적인 특징을 파악해서 이를 하나의 개념(집합)으로 다루는 것
(현실 세계의 객체나 개념을 프로그래밍에서 모델링하는 과정을 의미합니다. 이것은 복잡한 현실 세계를 단순화하고 필요한 부분에만 집중할 수 있도록 해줍니다. 추상화를 통해 우리는 객체의 중요한 특징을 강조하고 불필요한 세부 사항을 숨길 수 있습니다)

2) 캡슐화(접근 제한자 or 접근 제어자 활용)
정보 은닉 : 필요가 없는 정보는 외부에서 접근하지 못하도록 제한하는 것
높은 응집도, 낮은 결합도를 유지하여 유연함과 유지보수성 증가

3) 상속
여러 개체들이 가진 공통된 특성을 부각시켜 하나의 개념이나 법칙으로 성립시키는 과정

4) 다형성
서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 능력
오버라이딩(Overriding), 오버로딩(Overloading)

객체지향 프로그래밍 장점.

간편한 유지보수

객체라는 단위를 사용해서 프로그램을 구성하기에, 중복 코드의 관리가 수월해지며, 문제가 있거나, 수정이 필요로 할 때, 해당 객체만 원하는 방식으로 처리하면된다. 그래서 유지보수가 간편하다.
규모가 큰 프로그램의 구성에 유리
객체와 모듈의 특징을 이용해 프로그램을 구성하기에 규모가 큰 프로그램의 구성에서 유리한 이점을 가지고 있다.

코드의 재사용성

모듈화 된 객체를 사용해서, 해당 객체가 필요한 부분에 이식만 하면 됩니다. 그래서 재사용성이 뛰어납니다.

객체지향 프로그래밍 단점.

코드의 잠재적인 복잡성 증가(Complexity)

객체지향 프로그래밍의 복잡한 개념을 이해하고, 사용하는데 있어서 코드의 구조를 파악하기 어려울 수 있으며, 다양한 개념을 적용하면 코드가 복잡해질 수 있습니다.

설계 역량의 요구 및 오버디자인(Over-Design)

모듈, 객체간의 관계를 설계할 수 있는 능력이 있어야 합니다. 그래서 주어진 문제를 해결하는 초점을 넘어서 계층간 구조나 상속 관계, 인터페이스 등을 설계하는데 많은 시간을 소모하는 오버 디자인으로 이어질 수 있습니다.

비교적 느린 속도(Performance)

절차지향과 다르게 객체지향은 여러 객체가 의존하고 있는 관계로 대채적으로 속도가 느립니다. 다른 절차지향 언어에 비해 많은 메모리를 사용할 수 있으며 더 많은 오버헤드와 추상화를 요구합니다. 그래서 속도가 느려질 수 있습니다.

1-2)SOLID

1) 단일 책임 원칙(Single Responsibility Principle)
객체는 단 하나의 책임만 가져야 한다.

2) 개방 폐쇄 원칙(Open Closed Priciple)
기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.
예시로 추상 팩토리 패턴, 전략패턴, 데코레이션 패턴등이있다.
(찾아보기)
7가지 패턴이 있음
다른곳도 찾아보기

3) 리스코프 치환 원칙(Liskov Substitution Principle)
일반화 관계에 대한 원칙이며, 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다.

4) 인터페이스 분리 원칙(Interface Segregation Principle)
인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이다.

5) 의존 역전 원칙(Dependency Inversion Principle)
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것 보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것이다.

2)REST API란

REST 기반으로 서비스 API를 구현한 것
Open API는 대부분 REST API를 제공한다.
REST API 설계 규칙
URI는 자원의 정보를 표시해야 한다.
아래 ~사용한다 예시 링크

• resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
  resource는 도큐먼트 이름으로는 단수명사를 사용해야 한다.
  resource는 컬렉션 이름으로는 복수 명사를 사용해야 한다.
  resource는 스토어 이름으로는 복수 명사를 사용해야 한다.

/api/user x
/api/users

자원에 대한 행위는 HTTP Method(GET/POST/PUT/DELETE)로 표현한다.
URI HTTP Method가 들어가면 안된다.

/api/user/get X
/api/user

URI에 행위에 대한 동사 표현이 들어가면 안된다(CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
경로 부분 중 변하는 부분은 유일한 값으로 대체한다(즉, id는 하나의 특정 resource를 나타내는 고유값이다.)
REST란?
HTTP URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

2-1)Rest란 무엇인가

링크

• “Representational State Transfer” 의 약자
  자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

• REST의 구체적인 개념
  HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

• 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.

2-2)프로젝트에 REST API를 사용한 이유

• REST는 HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없고, REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다는 장점이 있다.

• 또한 클라이언트와 서버는 REST API를 이용해 정보를 주고 받기 때문에 서버는 클라이언트의 히스토리, 문맥을 유지할 필요가 없게 된다.
  각자의 역할이 명확하게 나뉘어져 있어 개발자의 업무량이 감소되고 플랫폼의 독립성 확장이라는 효과를 기대할 수 있다.

2-3)REST API를 대체할 수 있는 통신방법

• 그러나 REST API는 표준이 존재하지 않는다.

• 사용할 수 있는 메소드가 4가지 밖에 없었다.
  Create : 생성(POST) Read : 조회(GET) Update : 수정(PUT) Delete : 삭제(DELETE)
  요즘은 Patch: 부분 수정 라는게 하나 추가되어서 5개다

HTTP Method 형태가 제한적이다.

• 이러한 단점을 가진 REST API를 대체할 수 있는 것으로는 SOAP과 GraphQL이 있다.

1) SOAP
서로 다른 애플리케이션 통신을 지원하는 초기 통신 프로토콜이다.

HTTP Method중 POST만을 이용하여 데이터의 CRUD를 처리하는 특징이 있다.
다양한 오류에 대한 처리가 가능하고, stateful / stateless 모두 지원한다.

2) GraphQL
GraphQL은 필요한 컬럼에 대해서만 선택적으로 요청할수 있어 불필요한 데이터를 받지 않고, 필요한 데이터만 받을 수 있다.
GraphQL은 REST와는 다르게 Resource에 대한 엔드포인트가 따로 존재하지 않고, 하나의 엔드포인트만 존재한다.

해당 엔드포인트로 요청 시, 원하는 리소스와 해당 리소스에서 원하는 필드를 특정하는 GraphQL query를 함께 보낸다.

• GraphQL은 여러 Depth의 조인이 필요한 복잡한 요청 데이터도 할 수 있어서, 효율적으로 데이터를 주고 받을 수 있다.

장점

• controller가 필요없이 service 단에서 바로 기능한다.
  (컨트롤러를 신경쓰지 않아도 된다.)

@Service
//추가
@GraphQLApi
public class PostService {

	@Autowired
	private PostRepository postRepository;
	
	public PostService(PostRepository postRepository) {
		this.postRepository = postRepository;
	}
	
	//{
	//	posts{
	//		id
	//  	title
	//	}
	//}
	
	@GraphQLQuery(name = "posts")
	public List getPosts(){
		return postRepository.findAll();
	}
	
	//{
	//	post(id:1){
	//		id
	//		title
	//	}
	//}
	@GraphQLQuery(name = "post")
	public Optional getPostById(Long id){
		return postRepository.findById(id);
	}
}

• 원하는 부분만 보내거나 받을수있다.링크

단점

• 따로 post.graphql 라는 파일을 만들어서 관리해줘야한다.

	post(id:1){
		id
		title
	}

이런식으로 post.graphql 라는 것을 만들고 작성해줘야한다.

• Rest API가 좀 더 처리가 빠를 때도있다. 상황에 맞춰 사용해야한다.