[패스트캠퍼스] Java & SpringBoot로 시작하는 웹 프로그래밍 : 자바 인강_6주차 학습일지

# 객체지향

1. 추상화, 상속, 은닉, 재사용, 인터페이스 등의 특성을 띔

2. 실존하는 사물을 있는 그대로 모델링하여, 그 사물을 객체(Object), 그 사물이 하는 행위를 Method, 그 사물이 가지는 속성을 변수(Variable)라고 정의

 

# 객체의 3가지 요소

1. 상태 유지 (객체의 상태)

객체의 속성은 변수로 정의되어져야 하고, 이 속성값이 바뀌면 객체의 상태도 바뀌어야 함

2. 기능 제공 (객체의 책임)

객체의 기능은 Method를 통해 제공되어져야 함

3. 고유 식별자 제공 (객체의 유일성)

각각의 객체는 고유한 식별자를 가져야 함

 

※ 이 3가지 요소가 갖춰지지 않았을 경우, 불완전한 객체라고 부름

 

# 물리 객체 & 개념 객체

물리 객체 : 실제로 사물이 존재하고, 이것을 클래스로 정의한 객체를 의미

개념 객체 : 실제로 존재하는 사물이 아니고, 웹 시스템에서 Service에 해당하고 business logic을 처리하는 부분을 의미  

 

# 객체지향의 4대 특성

1. 캡슐화 : 객체의 속성을 보호하기 위해 사용

< Method 설계 >

- Getter / Setter Method

- CRUD Method

- Business Logic Method

- 객체의 생명 주기 처리 Method

- 객체의 영구성 관리 Method

-> 추상화 제공, 재사용성 향상, 유지 보수성 향상, 무결성의 장점들이 있음

 

2. 상속 : 하위로 내려갈수록 구체화되는 것

-> 프로그램 구조에 대한 이해도 증가, 재사용성 향상, 확장성 향상, 유지 보수성 향상의 장점들이 있음

 

3. 다형성 : 하나의 개체가 여러 개의 형태로 변화하는 것

 

4. 추상화 : 모델링, 특성을 재조합, 정의하는 과정, 앞서 배운 특성들 모두 추상화에 속함

 

# 객체지향 설계 5원칙 SOLID

좋은 소프트웨어 설계는 결합도는 낮추고 응집도는 높이는 것

결합도(coupling) : 클래스 간의 상호 의존 정도

응집도(cohesion) : 기능적으로 관련성이 있는 요소들의 응집 정도

 

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

어떠한 클래스의 변경 이유는 하나뿐이여야 함

 

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

인터페이스를 하위 클래스와 상위 클래스 사이에 둠으로써, 자신의 변화에 대해서는 폐쇄적이지만, 인터페이스를 통한 외부의 변화에 대해서는 개방적임

 

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

하위 클래스는 언제나 상위 클래스의 타입으로도 교체될 수 있어야 함

 

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

클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안됨

(프로젝트의 요구 사항에 따라 SRP / ISP 둘 중 하나를 택함)

 

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

자신의 클래스보다 변하기 쉬운 것에 의존하면 안됨

 

# POJO JAVA

POJO (Plain Old Java Object) : 순수한 자바 오브젝트를 뜻함

 

1. 특정 규약에 종속되지 않음

외부의 의존성을 두지 않고 순수한 JAVA로 구성이 가능해야 함

 

2. 특정 환경에 종속되지 않음

 

3. Spring, Hibernate

이 두 프레임워크는 객체지향적인 설계를 하고 있고 POJO를 지향하고 있음

 

# 디자인 패턴

알고리즘과 유사하지만 다르며, 자주 쓰는 설계 패턴을 프로젝트 상황에 맞추어 적용 가능하게 한 설계 패턴

 

- Gof 디자인 패턴

사람들의 다양한 경험 지식을 공유하기 위해 나온 것, 총 23개의 패턴이 있음

 

- 장점 : 개발자간의 원활한 소통, 프로그램 구조 파악 용이, 재사용을 통한 개발 시간 단축, 설계 변경 요청에 대한 유연한 대처

- 단점 : 객체지향 설계 및 구현(모든 개발자가 객체지향에 대해 선행학습이 필요함) , 초기 투자 비용 부담

 

1. 생성 패턴

객체를 생성화는 것과 관련된 패턴, 객체의 생성과 변경이 전체 시스템에 미치는 영향을 최소화하고 코드의 유연성을 높여줌

- Factory Method

- Singleton

- Prototype

- Builder

- Abstract Factory

- Chaining

 

2. 구조 패턴

프로그램 내의 자료구조, 인터페이스 구조 등 구조를 설계하는데 활용되는 패턴, 큰 규모에서의 각 클래스 간의 복잡한 관계를 개발하기 쉽게 만들어주고 유지 보수성이 좋게 만듬

- Adapter

- Composite

- Bridge

- Decorator

- Facade

- Flyweight

- Proxy

 

3. 행위 패턴

반복적으로 사용되는 객체들의 상호작용을 패턴화한 것, 행위와 관련된 패턴을 사용하여 독립적으로 일을 처리하고자할 때 사용

- Template Method

- Interpreter

- Iterator

- Observer

- Strategy

- Visitor

- Chain of responsibility

- Command

- Mediator

- State

- Memento

 

# Web

World Wide Web, WWW, W3

 

# Web의 용도

1. Web Site

google, naver, facebook 등 HTML로 구성된 여러 사이트

 

2. API (Application Programming Interface) - Web Service

Kakao Open API, Google Open API 등

 

3. User Interface

Chrome, Safari, Explorer 등

 

# Web의 기본 3가지 요소

1. URI (Uniform Resource Identifier)

리소스 식별자

 

2. HTTP (Hypertext Transfer Protocol)

어플리케이션 컨트롤

 

3. HTML (Hyper Text Markup Language)

하이퍼미디어 포맷

 

# REST (Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처

1. Client & Server : 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 함

2. Stateless : 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않아야 함

3. Cache : 클라이언트는 서버의 응답을 Cache(임시저장)할 수 있어야 함

4. 계층화 : 클라이언트와 서버 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성 가능해야 함

5. 인터페이스 일관성 : 인터페이스는 일관성을 지키고, 클라이언트와 서버는 각각 독립적으로 개선될 수 있어야 함

6. Code on Demand(선택적임) : 특정 기능을 서버로부터 클라이언트가 전달받아서 코드를 실행할 수 있어야 함

 

※ REST FULL 하기 위한 인터페이스 일관성

1. URI에 자원을 식별할 수 있는 정보가 담겨야 함

2. 리소스의 조작을 위해서 데이터 전체를 전달하는 것이 아닌, 메시지의 형태로 데이터를 전달해야 함

3. 요청하는 데이터가 어떻게 처리되어야 하는지 충분한 데이터(자기서술적 메시지)를 포함해 전달해야 함

4. 클라이언트의 요청에 대한 데이터만 전달해주는 것이 아닌, 관련된 리소스에 대한 Link 정보까지 전달해야 함(선택적임)

 

# URI (Uniform Resource Identifier)

인터넷에서 특정 자원을 나타내는 주소 값으로 유일한 값

 

# URL (Uniform Resource Locator)

인터넷에서 자원, 특정 파일이 어디에 위치하는지 식별하는 주소

 

※ URL은 URI의 하위 개념임

 

# URI 설계 원칙 (RFC-3986)

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용

2. URI 마지막 문자로(/)는 포함하지 않음

3. 하이픈(-)은 URI 가독성을 높이는데 사용

4. 밑줄(_)은 사용하지 않음

5. URI 경로에는 소문자가 적합

6. URI에 파일 확장자는 포함하지 않음

7. 프로그래밍 언어에 의존적인 확장자를 사용하지 않음

8. 구현에 의존적인 경로를 사용하지 않음

9. 세션 ID를 포함하지 않음

10. 프로그래밍 언어의 Method명을 이용하지 않음

11. 명사에 단수형보다는 복수형을 사용, 컬렉션에 대한 표현은 복수로 사용

12. 컨트롤러 이름으로는 동사나 동사구를 사용

13. 경로 부분 중 변하는 부분은 유일한 값으로 대체

14. CRUD 기능을 나타내는 것은 URI에 사용하지 않음

15. URI Query Parameter 디자인 사용

16. URI Query는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용

17. API에 있어서 서브 도메인은 일관성 있게 사용

18. 클라이언트 개발자 포탈 서브 도메인도 일관성 있게 사용

 

※ 원칙일 뿐, 이걸 꼭 안지킨다고 해서 잘못된 주소고 요청이 안되는 건 아님

 

# HTTP (Hyper Text Transfer Protocol)

메시지를 주고(Request) 받는(Response) 형태의 통신 방법

 

HTTP의 통신 방식

 

# HTTP의 요청을 특정하는 Method*

- GET

- POST

- PUT

- DELETE

- HEAD

- OPTIONS

- TRACE

- CONNECT

 

# HTTP Status Code

1XX : 처리중인 상태

2XX : 성공

3XX : 리다이렉트

4XX : 클라이언트 에러

5XX : 서버 에러