객체지향 프로그래밍(OOP), REST API란?

OOP란?

프로그램 구현에 필요한 객체를 파악하고 각각의 객체들의 역할이 무엇인지를 정의하여 객체들 간의 상호작용을 통해 프로그램을 만드는 것

캡슐화 (Encapsulation)

객체의 속성(Field)과 행위(Method)를 하나로 묶고, 외부로 부터 내부를 감싸 숨기는 것

가장 중요한 목적은 정보의 은닉화이다.

예를 들어, public 으로 선언하면 누구나 접근이 가능해 조작될 수 있다. 따라서 변수를 바로 접근할 수 없도록 private 로 선언하고 데이터를 보호하는 것이다.

이렇게 보호된 변수는 getter나 setter 등의 메서드를 통해서만 간접적으로 접근이 가능하도록 하는 것이다.

추상화 (Abstraction)

객체의 공통적인 속성과 기능을 추출하여 정의하는 것

예를 들어, 사자, 호랑이, 토끼, 강아지 등이 있을 때 이것들을 각각의 객체라 하며 이 객체들을 하나로 묶을 때, 동물이라는 어떤 추상적인 객체로 크게 정의 할 수 있다. 이렇게 묶는 것을 추상화라고 한다,

다형성 (Polymorphism)

하나의 메서드나 클래스가 있다고 가정할 때 이 메서드나 클래스를 다양한 방법으로 동작하게 하는 것

• 오버로딩 (OverLoading)
  같은 이름의 메서드를 매개변수의 유형과 개수를 다르게 하여 다양하게 재정의 하는 것
• 오버라이딩 (Overriding)
  상위 클래스가 가지고 있는 메서드를 하위 클래스에서 재정의하여 사용 하는 것(즉, 메서드의 이름과 매개변수는 같지만 메서드를 덮어쓴다는 느낌)
  

상속성 (Inheritance)

상위 클래스의 모든 것을 하위 클래스가 새롭게 클래스와 행위를 정의 할 수 있는 것

상위 클래스의 기능을 가져와 재사용할 수 있고 동시에 새로운 기능을 추가해서 사용할 수 있다.
코드의 재사용성이 있다.

예를 들어 동물이라는 상위 클래스에서 포유류, 조류 이렇게 하위클래스로 나뉘게 된다. 상위에서 숨쉰다, 먹이를 먹는다 등의 메서드만 있다면 하위 클래스에선 포유류는 뛰어다닌다, 조류는 난다 등으로 기존 메서드도 사용가능하고 새로운 메서드도 추가해서 사용할 수 있다.

OOP의 5가지 설계 원칙(SOLID)

1. SRP(Single Responsibility Principle) : 단일 책임 원칙

• 객체는 단 하나의 책임만 가져야 한다.

2. OCP(Open Close Principle) : 개방 - 폐쇠 원칙

• 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.

3. LSP(Liskov Substitution Principle) : 리스 코프 치환 원칙

• 일반화 관계에 대한 이야기며, 자식 클래스는 최소한 자신의 부모에서 가능한 행위는 수행할 수 있어야 한다.

4. ISP(Interface Segragation Principle) : 인터페이스 분리 원칙

• 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계의 원칙

5. DIP(Dependency Inversion Principle) : 의존 역전 원칙

• 상위 클래스가 하위 클래스에 의존하면 안 된다는 법칙
• 의존 관계를 맺을 때 변화하기 쉬운 것 보단 변화가 없는 것에 의존하라는 것이다.

REST API란?

REST 기반으로 서비스 API를 구현한 것이다. URL 형식으로 HTTP 메서드(GET, POST, PUT, DELETE)를 요청해 자원을 조회, 생성, 수정, 삭제할 수 있는 것이다.

특징

• 클라이언트 - 서버 구조 : 자원이 있는 쪽이 서버, 요청하는 쪽이 클라이언트다.
• Stataless(무상태) : 클라이언트 상태를 서버에 저장하지 않는다.
• Cacheable(캐시 처리 가능) : 대량의 요청을 효율적으로 처리하기 위한 캐시를 사용할 수 있다. 이를 통해 응답 시간 빨라지고 성능, 서버의 자원 이용률 향상할 수 있다.
• Layered System(계층화) : 클라이언트는 REST API만 호출한다. REST 서버는 다중 계층으로 구성될 수 있다.
• Uniform Interface(인터페이스 일관성) : URL로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행

사용이유

클라이언트와 서버의 완전한 분리

• 클라이언트와 서버는 REST API를 이용해 정보를 주고 받는다. stateless한 특징에 따라 서버는 클라이언트의 히스토리, 문맥을 유지할 필요가 없게 된다. 즉, 각자의 역할이 명확하게 나뉘어져 있다.
• 이런 점은 개발자의 업무량 감소 뿐만 아니라 플랫폼의 독립성 확장이라는 효과를 가져올 수 있다.

쉬운 소통

• REST API는 헤더 부분에 URL 메서드를 명시한다. 이는 주소와 메서드만 보고 요청의 내용을 알아볼 수 있어서 개발자 간 소통도 쉽고 개발 시 혼선이 덜 빚어질 수 있다.

참고
https://day0404.tistory.com/43
https://theheydaze.tistory.com/603
https://code-lab1.tistory.com/194