객체지향 프로그래밍
객체지향 프로그래밍(OOP)
- 데이터를 추상화 시켜 (상태와 행위를 가진 객체)로 만들어 상호작용을 통해 로직을 구성하는 프로그래밍 방법론이다.
객체
- 값을 저장할 변수와 작업을 수행할 메소드를 연관된 것들끼리 묶은 것
추상화
- 공통된 속성과 행위를 추출하는 것
- 불필요한 정보를 숨겨서 프로그램을 단순화 시킨다
- 추상화로 자동차를 구현해두면 현대가 추가될 때 다른곳의 코드를 수정할 필요 없이 자동차에서 추가로 만들 부분만 새로 생성해주면 된다
캡슐화
- 클래스 안에 서로 연관있는 속성과 기능들을 하나의 캡슐(capsule)로 만들어 데이터를 외부로부터 보호하는 것
상속
- 하위 클래스가 상위 클래스의 속성과 행위를 물려받는것
- 코드 재사용성의 증가
- 단점 - 상위클래스 변경이 힘들어짐
다형성
- 어떤 요소에 여러 개념을 넣어 놓는 것
- 오버라이딩 - 상위 클래스의 메소드를 하위 클래스에서 재정의
- 오버로딩 - 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 함
객체지향 프로그래밍의 장점과 단점
- 장점
- 모듈화 개발 - 업무분담 편리 - 대규모 개발에 적합
- 클래스 단위별 수정 - 유지보수 편리
- 클래스 재사용 또는 상속을 통한 확장 - 재사용 용이
- 단점
- 처리속도가 느리고 용량이 큼
- 설계시 많은 노력이 필요
SOLID 원칙
1. 단일 책임 원칙 (SRP, Single Responsibility Principle)
- 하나의 클래스는 단 하나의 책임만 가져야 한다.
- 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.
2. 개방-폐쇄 원칙 (OCP, Open/Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.
3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)
- 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
- 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
- 인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
- 클라이언트가 필요로 하는 인터페이스로 분리함으로써 각 클라이언트가 사용하지 않는 인터페이스에 변경이 있어도 영향을 받지 않도록 만들어야 한다.
5. 의존관계 역전 원칙 (DIP), Dependency Inversion Principle)
- 추상화에 의존해야지 구체화에 의존하면 안된다.
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되고 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
REST API
API
- 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
- 애플리케이션과 운영체제, 애플리케이션과 프로그래밍 언어가 제공하는 기능 사이의 ‘상호작용’을 도와준다.
- 웹에서 쓰이는건 웹 api
REST API
- REpresentational State Transfer
- 자원(uri), 행위(http method), 표현을 구조적으로 깔끔하게 표현하는 방법
- 원칙
- 리소스에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE)로 표현해야 함.
URI에 동사는 GET, POST와 같은 HTTP Method를 표현하기 때문이다.동사가 아니라 명사를 사용함. - /(슬래시)는 계층 관계를 나타낼때 사용함.
- URI 마지막 문자에 /(슬래시)를 사용하지 않음.
- URI에 _(underscore)는 사용하지 않도록 합니다. 또한 영어 대문자보다는 소문자를 씁니다.그리고 가독성을 위해서 긴 단어는 잘 사용하지 않음.
- URI에 파일의 확장자(예를들어 .json , .JPGE)를 포함 시키지 않음.
- 리소스에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE)로 표현해야 함.
프로젝트에 REST API를 사용한 이유 ( 보충필요 ! ! ! )
- API의 목적이 무엇인지 명확하게 하기 위해 ( 보충필요 ! ! ! )
REST API 말고 다른 비교할 만한 것
- SOAP API (simple object access protocol)
- 보통 웹서비스에서 개발자들은 SOAP의 이점이 확실하게 필요한 것이 아니라면 REST방식을 선택하는 경우가 많고 기업용 애플리케이션의 경우는 많은 리소스와 보안, 여러 요구사항을 만족하기위해 SOAP방식을 선택하는 경우가 많다고 함.
참고 링크
객체지향 프로그래밍이란?
API란 개념,종류(REST API, SOAP API),역사 쉽게정리
[WEB] 🌐 REST API 구성/특징 총 정리
HTTP의 기초
URI, URL, URN 뭐가 다른걸까요?
객체 지향 설계 5원칙 - SOLID
Stop thinking. Just do it.