[Development common sense] 객체 지향 프로그래밍, RESTful API

Object Oriented Programming [객체 지향 프로그래밍]

: 객체 지향 프로그래밍이란 인간 중심적 프로그래밍 패러다임이라고 할 수 있다. 현실 세계의 사물들을 객체라고 보고 그 객체로부터 개발하고자 하는 애플리케이션에 필요한 특징들을 뽑아와 프로그래밍 하는 것이다. 이것을 추상화라고 한다.

 

 

객체 지향 프로그래밍의 핵심 개념

• 클래스(Class): 객체를 생성하기 위한 템플릿 또는 블루프린트. 크래스는 객체의 상태를 정의하는 필드(속성, 멤버 변수)와 객체의 행동을 정의하는 메서드(함수)로 구성된다.
• 객체(Object): 클래스에 의해 생성된 인스턴스. 객체는 소프트웨어의 기본 단위로, 실제 메모리 상에 할당되어 있으며, 각 객체는 고유한 상태와 행동을 가진다.
• 상속(Inheritance): 한 클래스가 다른 클래스의 속성과 메서드를 상속받아 사용할 수 있게 하는 기능이다. 이를 통해 기존 코드의 재사용성을 높이고, 중복 코드를 줄일 수 있다.
• 캡슐화(Encapsulation): 객체의 세부 구현 내용을 숨기고, 사용자에게는 필요한 인터페이스만을 제공하는 기술이다. 이는 객체 내부의 상태를 보호하고, 외부에서의 무단 접근을 방지한다.
• 다형성(Polymorphism): 하나의 인터페이스나 메서드가 다양한 방식으로 동작할 수 있게 하는 능력이다. 이를 통해 같은 인터페이스를 가진 객체들이 상황에 따라 다른 방식으로 동작할 수 있게 한다.

 

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

1. 재사용성(Reusability): 이미 개발된 클래스를 다른 프로그램에서 쉽게 재사용할 수 있으며, 이를 통해 개발 시간과 비용을 절약할 수 있다. 또한 상속을 통해 기존 클래스의 속성과 메서드를 확장하여 새로운 기능을 쉽게 추가할 수 있다.
2. 유지보수성(Maintainability): 객체 지향 프로그래밍에서는 프로그램을 독립적인 객체 단위로 나누어 관리하기 때문에, 한 부분의 수정이 다른 부분에 미치는 영향을 최소화할 수 있다. 이는 프로그램의 유지보수를 용이하게 하며, 오류 수정과 기능 개선을 보다 효율적으로 수행할 수 있게 한다.
3. 확장성(Scalability): 객체 지향 프로그래밍은 시스템의 확장성을 높인다. 새로운 기능이 필요할 때 기존 코드를 수정하는 대신, 새로운 클래스를 추가하거나 기존 클래스를 상속받아 확장함으로써 기능을 추가할 수 있다ㅏ. 이는 시스템의 성장과 변화에 유연하게 대응할 수 있게 한다.
4. 모듈성(Modularity): 객체 지향 프로그래밍에서는 프로그램을 구성하는 각 부분을 독립적인 모듈로 취급한다. 이 모듈들은 서로 분리되어 있으며, 각각의 모듈은 특정한 기능을 수행한다. 이러한 모듈성은 코드의 가독성을 높이고, 팀 작업에서 협업을 용이하게 한다.
5. 추상화(Abstraction): 객체 지향 프로그래밍은 복잡한 내부 구현 세부 사항을 숨기고 사용자에게 필요한 인터페이스만을 제공한다. 이러한 추상화는 사용자가 복잡한 내부 구현을 이해하지 않고도 객체의 기능을 사용할 수 있게 하며, 프로그램의 복잡성을 관리하는 데 도움을 준다.
6. 캡슐화(Encapsulation): 객체 지향 프로그래밍에서는 데이터와 그 데이터를 처리하는 메서드를 하나의 단위, 즉 객체로 묶는다. 이를 통해 데이터 접근을 제어할 수 있으며, 객체 내부의 상세 구현을 외부로부터 보호할 수 있다.

 

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

1. 성능 저하: 객체 지향 프로그래밍은 추상화, 캡슐화, 상속, 다형성 등의 특징을 갖는다. 이러한 특징들은 프로그램의 유연성과 재사용성을 높이지만, 추가적인 처리가 필요하므로 성능 저하를 일으킬 수 있다. 예를 들어, 메서드 호출 시에는 호출 스택, 객체 생성 및 소멸 과정에서의 오버헤드가 발생할 수 있다.
2. 복잡성 증가: 객체 지향 프로그래밍은 프로그램을 객체로 구분하고, 이 객체들이 서로 상호작용하도록 설계한다. 복잡한 시스템에서는 수많은 객체들이 서로 복잡하게 연결될 수 있으며, 이로 인해 시스템의 전체적인 이해와 관리가 어려워질 수 있다.

 

객체 지향적 설계 원칙

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

클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유이어야 한다.

- OCP(Open-Closed Principle): 개방-폐쇄 원칙

확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

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

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

- ISP(Interface Segregation Principle): 인터페이스 분리 원칙

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

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

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

 

 

 

---

 

 

 

RESTful API

REST란, REpresentational State Transfer의 약자다. 여기에 ~ful이라는 형용사형 어미를 붙여 ~한 API라는 표현으로 사용된다.

즉, REST의 기본 원칙을 성실히 지킨 서비스 디자인은 'RESTful'하다라고 표현할 수 있다.

 

REST가 디자인 패턴이다 or 아키텍처다 많은 이야기가 존재하는데 하나의 아키텍처로 볼 수 있다. 좀 더 정확한 표현으로 말하자면 REST는 Resource Oriented Architecture이다. API설계의 중심에 자원(Resource)이 있고 HTTP Method(GET, POST, PUT, DELETE 등)를 통해 자원을 처리하도록 설계하는 것이다.

 

 

Rest의 6가지 원칙

• Uniform Interface
• Stateless
• Caching
• Client-Server
• Hierarchical system
• Code on demand

 

RESTful하게 API를 디자인 한다는 것은 무엇을 의미하는가?

1. 리소스와 행위를 명시적이고 직관적으로 분리한다.

• 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
• 행위는 HTTP Method로 표현하고, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)을 분명한 목적으로 사용한다.

2. Message는 Header와 Body를 명확하게 분리해서 사용한다.

• Entity에 대한 내용은 body에 담는다.
• 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header에 담는다.
• headerdhk body는 http header와 http body로 나눌 수도 있고, http body에 들어가는 json 구조로 분리할 수도 있다.

3. API 버전을 관리한다.

• 환경은 항상 변하기 때문에 API의 signature가 변경될 수도 있음에 유의하자.
• 특정 API를 변경할 때는 반드시 하위호환성을 보장해야 한다.

4. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.

• 브라우저는 form-data 형식의 submit으로 보내고 서버에서는 json형태로 보내는 식의 분리보다는 json으로 보내든, 둘 다 form-data형식으로 보내든 하나로 통일한다.
• 다른 말로 표현하자면 URI가 플랫폼 중립적이어야 한다.

 

RESTful API의 장점

1. 플랫폼 독립성: RESTful API는 HTTP를 사용하기 때문에, 어떤 플랫폼이나 언어로도 클라이언트를 구현할 수 있다. 이는 다양한 환경에서의 접근을 용이하게 한다.
2. 간단한 인터페이스: REST는 HTTP 표준 메서드를 사용하므로, API를 사용하기 위한 인터페이스가 단순하고 이해하기 쉽다.
3. 확장성: RESTful API는 상태가 없으므로, 서버 측에서 클라이언트의 상태 정보를 유지할 필요가 없다. 이는 서버 설계를 단순화하고, 시스템 확장성을 높인다.
4. 캐싱 가능: HTTP프로토콜의 기능을 그대로 사용할 수 있기 때문에, HTTP가 가진 캐싱 기능을 이용해 응답을 캐시하고, 재사용할 수 있어서 효율적이다.
5. 자체 표현성(self-descriptiveness): REST API 메시지만 보고도 쉽게 이해할 수 있다. 예를 들어, 'GET /users'는 사용자 정보를 조회하는 것으로 해석할 수 있다.

 

RESTful API의 단점

1. 메서드 제한성: REST는 HTTP메서드를 사용하기 때문에, 정해진 메서드(GET, POST, PUT, DELETE 등)만을 사용하여 통신해야 한다. 때로는 이러한 제한이 작업을 어렵게 만들 수 있다.
2. 상태 유지 불가: RESTful API는 상태를 유지하지 않는(Stateless) 특성 때문에, 클라이언트와 서버 간의 통신에서 각 요청이 독립적이다. 이로 인해, 연속된 작업을 처리하기 위해서는 모든 요청에 필요한 정보를 계속해서 전달해야 한다.
3. 보안 및 인증 방법 제한: RESTful API는 HTTP를 기반으로 하기 때문에, HTTP 자체의 보안 취약점에 노출될 수 있다. 따라서, SSL/TLS같은 프로토콜을 별도로 사용하여 데이터를 암호화해야 한다.
4. 표준의 부재: REST는 설계 원칙과 가이드라인을 제공하지만, 엄격한 표준이 존재하지 않는다. 이로 인해 API 설계자에 따라 API의 구현과 해석이 달라질 수 있다.

 

 

 

참고

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/main/Development_common_sense#restful-api