Java Spring, 객체 지향 프로그래밍

RESTful 한 API를 설계하는 장점

 

http 프로토콜을 기반으로 하며

웹에서 사용되는 기술과 규약을 그대로 활용

웹 어플리케이션 또는 서비스 간에 정보를 쉽게 주고받을 수 있다

 

Rest의 설계규칙을 잘 지켜서 개발한 api가 Restful한 api라고 할 수 있습니다.

 

Rest의 설계규직은 URI는 정보의 자원만 표현해야하고

자원의 상태는 HTTP 메서드를 사용해서 명시해야합니다.

 

 

핵심원칙

1. 자원의 식별

2. 메시지를 통한 자원의 조작

3. 자기 서술적 메세지,

4. 애플리케이션 상태의 엔진으로써의 하이퍼미디어

5. 독립적 플랫폼언어 독립적인 인터페이스를 제공다양한 환경에서의 상호 운용성이 보장

 

설계 원칙

1. 자원의 식별

모든 자원은 고유한 URI를 가지며

이를 통해 자원을 식별합니다.

URI == 인터넷상에서 자원을 고유하게 식별하고 위치를 지정하는 표준 방법

 

2. 자원에 대한 행위

HTTP 메서드(POST, GET, PUT, DELETE)를 통해 표현

HTTP 프로토콜의 기본 메서드를 활용하여 자원에 대한

CRUD(Create, Read, Update, Delete) 연산을 명확하게 표현할 수 있다.

 

3. 메시지는 자기 서술적

메시지 포맷과 HTTP 메서드 등을 통해 요청의 의도를 명확하게 할 수 있어야 한다.

 

4. 애플리케이션의 상태는 Hypermedia를 통해 관리된다.

클라이언트는 하이퍼미디어 링크를 통해 애플리케이션의 상태를 전화할 수 있어야 한다.

 

이러한 원칙을 준수함으로써 RESTful API는 확장성, 유지보수성, 재사용성 등을 높일 수 있다.

 

장점

1. HTTP 프로토콜을 기반으로 하기 때문에 웹에서 널리 사용되는 기술과 호환이 된다.

웹의 기본 표준을 그대로 활용하기 때문에 개발자가 쉽게 접근을 할 수 있고, 기존 웹 인프라를 활용할 수 있다.

 

Rest는 HTTP 프로토콜을 기반으로 하기 때문에 웹에서 널리 사용되는 기술과 호환이 되고

개발자들이 쉽게 접근을 할 수 있게됩니다.

 

 

2. 플랫폼과 언어에 독립적

JSON, XML 같은 표준 포맷을 사용하여 데이터를 교환

다양한 플랫폼과 프로그래밍 언어에서 사용가능

 

3. 간단하고 이해하기 쉬운 인터페이스를 제공 URI로 자원을 식별하고,

HTTP 메서드로 해당 자원에 대한 행위를 정의 api의 구조를 쉽게 이해 가능

 

4. 확장성과 재사용성이 뛰어나다

상태를 클라이언트에 저장하지 않는

Stateless 아키텍처를 따르기 때문 서버와 클라이언트가 독립적을 확장 가능

 

적절한 관심사 분리의 필요한 이유

 

관심사의 분리는 애플리케이션의 다양한 기능과 요소를 명확하게

분리하여 독립적으로 관리할 수 있도록 하는 개념

코드의 가독성을 높이고, 오류를 줄이며, 다른 개발자와의 협업을 용이하게 한다.

 

기능과 요소가 서로 독립적으로 분리되어 있기 때문에

한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있다.

 

관심사 분리의 구현 가장 일반적인 방법 중 하나

== 모델-뷰-컨트롤러(MVC) == 모델(데이터 관리)- 뷰(UI 화면) - 컨트롤러(비즈니스 로직) 세 부분으로 분리

 

또 다른 접근 방식모델-뷰-뷰모델(MVVM) 패턴==

데이터 바인딩을 통해 뷰와 모델 사이의 동기화를 자동화하며,

뷰모델이 뷰와 모델 사이의 중재자 역할

 

위와 같은 패턴을 사용함으로써 개발자는 UI와 비즈니스 로직을 명확히 분리할 수 있고,

각각의 컴포넌트를 독립적으로 관리하고 재사용할 수 있다.

데이터 바인딩

앱 UI와 해당 UI가 표시하는 데이터를 연결하는 프로세스

 

컴포넌트

프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈

 

애플리케이션의 복잡성을 관리하고, 테스트와 유지보수를 용이하게 한다.

 

Setter를 무분별하게 사용하면 안 되는 이유

 

Getter와 Setter를 사용하는 이유객체 지향의 원칙 중 하나는 정보 은닉이다.

객체의 구체적인 정보를 외부에 노출하지 마라

자바에서는 클래스를 작성할 때 모든 필드를 private으로 숨기고

public 메서드를 통해 간접적으로 필드를 다루게 된다.

 

필드를 private으로 숨기고 public으로 외부에서 열어서 사용하는 것은

정보 은닉효과로 볼 수 없다.

 

Setter를 사용하면 객체의 속성이 갖는 값을 바꾼 이유를 명확하게 알 수 없다.

데이터를 변경하려고 하는데 이때 setter를 사용해서 코드를 작성을 하게 되면

setter를 나열한 것만으로 어떤 의도로 데이터를 변경하는지 명확히 알 수 없다.

 

객체의 일관성을 유지하기 어렵다.

setter는 public으로 되어있기 때문에 변경 메서드뿐만 아니라 모든 곳에서 정보를 변경할 수 있는 상태가 된다.

해당 객체가 해야 할 일을 다른 객체가 해야할 수도 있다.

다른 객체가 대신 일을 해주고 있는데 객체의 구조가 변경된다면

그 객체의 일을 대신해주는 모든 코드를 수정해야 한다.

 

setter 대신 다른 것을 사용

생성자 오버로딩 ==

멤버변수가 많고 다양한 생성자를 가져야 한다면 코드가 길어지고, 가독성이 떨어진다.

 

이를 해결 -> Builder 패턴

요구사항에 맞게 필요한 데이터만을 이용하여 유연한 클래스 생성이 가능

다양한 생성자들이 사라지고 전체 생성자 하나 만들 가지고 있는 형태로 변경

-> 유지보수 및 가독성이 향상 또한 객체를 생성할 때 값의 순서가 상관이 없다.

 

정적 팩토리 메서드

정적 팩토리 메서드를 사용하면 이름을 가질 수 있어 반환될 데이터를 추측할 수 있다.

 

getter 지양 이유

캡슐화의 의미가 없어진다.

private으로 필드를 선언하고 public으로 아무 곳에서나 값을 꺼내올 수 있다면 상태정보가 그대로 노출이 된다.

이러면 필드를 private으로 선언하는 의미가 없다.

 

getter를 사용하지 말고

특정 값이 객체의 상태값과 같은 지 확인을 하려면

객체에 특정 값을 넘겨주고 값이 같은지 안 같은지 여부만을 응답받는 식으로 설계

 

로직을 객체에 존재하게 하여 메서드가 상태값을 모른 채로 객체에게 질문을 하도록 한다.

 

NoSQL과 RDBMS에 대해

 

RDBMS ==

DBMS앞에 R(Relataion)이 추가되어 관계형 데이터베이스 관리 시스템이다.

 

RDB를 관리하는 시스템 RDB는 관계형 데이터베이스 모델을 기초로 두고

모든 데이터를 2차원 테이블 형태로 표현하는 데이터 베이스

 

관계형 데이터베이스를 생성하고, 수정, 삭제 관리할 수 있는 소프트웨어라고 정의한다.

관계형 데이터베이스에서 이러한 관계를 나타내기 위해 외래키를 사용한다.

테이블 간의 관계에서 외래키를 이용한 테이블 간 join이 가능하다는 게 RDBMS의 가장 큰 특징이다.

 

특징

Data를 Column과 Row 형태로 저장한다.

데이터의 분류, 정렬, 탐색 속도가 비교적 빠르다.

SQL이라는 정교한 query를 통해 데이터를 다룬다.

Transaction(작업의 완정성을 보장)

반드시 Schema규격에 맞춰야 한다.(유연한 데이터 저장 X)

부하의 분산이 어렵다.(수직 확장만 가능)

대표적으로 MySQL, SQLite, PostgreSQL, Oracle 등이 있다

 

장점

정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장한다.

또한 관계는 각 데이터를 중복 없이 한 번만 저장할 수 있다.

 

단점

테이블 간 테이블 간 관계를 맺고 있어 시스템이 커질 경우 join문이 많은 복잡한 쿼리가 만들어질 수 있다.

성능 향상을 위해서는 서버의 성능을 향상해야 하는 Scale-up만을 지원한다.

이로 인해 비용이 기하급수적으로 늘어날 수 있다.

스키마로 인해 데이터가 유연하지 못하다. NoSQL(Not Only SQL) 테이블 간 과나 계를 정의하지 않는다.

 

데이터 테이블은 그냥 하나의 테이블이고 테이블 간 관계를 정의하지 않아

일반적으로 테이블 간 join이 불가능하다.

 

RDBMS와 달리 데이터 일관성은 포기하되 여러 대의 데이터베이스에 분산하여 저장하는 Scale-out을 목표로 등장했다.

 

수평적 확장성을 쉽게 할 수 있다는 장점을 가지고 있다.

Scale-Out을 쉽게 할 수 있다.

 

특징

유연성 : 스키마 선언 없이 필드의 추가 및 삭제가 자유로운 Schema-less

구조확장성 : 스케일 아웃 ( 수평 확장 )에 의한 서버 확장이 용이

고성능 : 대용량 데이터를 처리하는 성능이 뛰어나다

가용성 : 여러 대의 백업 서버 구성이 가능 ( 수평 확장 ) 하여 장애 발생 시에도

무중단 서비스가 가능데이터 간의 관계를 정의하지 않는다. (Table 간의 join 도 불가능)

RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼

RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다.

 

분산형 구조 : 데이터를 여러 대의 서버에 분산해 저장고정되지 않은 Table Schema (Schema가 없어 다루기 쉬움)

Key에 대한 입/출력만 지원한다.

Schema가 없다 보니 Data에 대한 규격화된 결과 값을 얻기 힘들다.

 

 

스키마

RDBMS

- 명확한 데이터 구조를 보장

- 스키마로 인해 데이터가 유연하지 못한다.

- 스키마가 변경될 경우 번거롭고 어렵다.

NoSQL

- 스키마가 없어 유연하며 자유로운 데이터 구조를 가진다.

- 언제든 저장된 데이터를 조정하고 새로운 필드를 추가가능.

- 명확한 데이터 구조를 보장 X  

데이터 구조 결정이 어렵다.

 

 

확장성

RDBMSScale-up만을 지원 ( 비용이 많이 든다. )

 

NoSQL

Saclue-up과 Scale-out 지원 ( 데이터 분산이 용이 )

 

테이블 간 관계성

RDBMS

- 각 데이터를 중복 없이 한 번만 저장 ( 데이터의 일관성을 보증 )

- 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어진다.

 

NoSQL

- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 경우 수정을 모든 컬렉션에서 수정해야 한다

.- 테이블 간 관계를 맺지 않아 복잡한 JOIN문이 사용되지 않는다.

 

 

데이터 처리

RDBMS

부하 발생 시, 처리가 어렵지만 데이터의 UPDATE가 빠르다.

 

NoSQL

많은 양의 데이터를 처리, 저장할 수 지만 데이터를 UPDATE 하는데 비교적 느리다.

 

언제 사용

RDBMS

데이터 구조가 명확하며 변경될 여지가 없으며 명확한 스키마가 중요한 경우 사용하는 것이 좋다.

또한 중복된 데이터가 없어(데이터 무결성) 변경이 용이하기 때문에

관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합하다.

 

NoSQL

정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 것이 좋다.

또한 단점에서도 명확하듯이 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 시에는

모든 컬렉션에서 수정을 해야 합니다.

이러한 특징들을 기반으로 Update가 많이 이루어지지 않는 시스템이 좋으며

또한 Scale-out이 가능하다는 장점을 활용해 막대한 데이터를 저장해야 해서

Database를 Scale-Out를 해야 되는 시스템에 적합

 

객체지향 프로그래밍이란

소프트웨어 개발에서 사용되는 프로그래밍 패러다임 중 하나로,

현실 세계의 사물을 모델링하여 소프트웨어를 개발하는 방법

 

객체 지향 프로그래밍은 다양한 객체들이 협력하여 하나의 애플리케이션으로 동작하는 프로그래밍 방법

 

장점

상대 객체의 세부 정보를 알 필요 없이 그저 객체에 무언가를 요청만 하면 된다는 점이 있다.

 

핵심 개념

클래스와 객체

클래스 == 객체를 생성하기 위한 템플릿

객체 == 클래스의 인스턴스, 데이터와 해당 데이터를 처리하기 위한 메서드를 포함한다.

 

추상화

공통성과 본질을 모아 추출

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

 

자동차와 오토바이라는 클래스가 있으면 

그 클래스들의 공통적인 부분은 전진과 후진,.. 등으로 볼 수 있다.

이때 이 공통적인 부분을 가진 추상 클래스 또는 인터페이스를 만들어서 사용을 할 수 있다.

 

 

상속

상속 == 하위 클래스가 상위 클래스의 특성과 필드, 메서드를 상속받는 개념이다.

코드의 재사용성을 높일 수 있다.

 

위의 추상화 부분에서 만들어진 추상클래스, 인터페이스의 기능들을

사용할 클래스에 extends, implements를 사용해서 상속을 받을 수 있다.

이렇게 하면 각 클래스에서 추상클래스, 인터페이스의 기능들을 사용할 수 있게 된다.

 

다형성

같은 이름의 메서드가 다양한 형태로 작동할 수 있는 능력

상위 클래스에 정의된 메서드가 하위 클래스에서 다르게 구현될 수 있다.

 

공통적인 부분을 상속받은 자동차, 오토바이에서

상위클래스의 메서드를 사용할 수 있는데

이를 각 클래스에서 상위클래스의 메서드를 가지고 내용을 바꿀 수 있다.

 

or

 

메서드를 정의를 할 때 매개변수가 중복이 되지 않으면 메서드의 이름은

중복이 되어도 문제가 없다.

 

 

캡슐화

객체의 데이터와 메서드를 하나로 묶는 개념

 

해당 클래스의 필드들을 외부에서 건드리지 못하게 private으로 

해당 클래스 내에서만 사용이 가능하게 막아둘 수 있다.

외부에서 사용할 일이 있으면 public으로 메서드를 만들어서 사용이 가능하다.

 

객체지향 프로그래밍을 사용을 하면

상속을 통해 코드를 재사용할 수 있다.

 

다형성을 통해 유연하고 확장 가능한 코드를 작성,

새로운 기능을 쉽게 추가할 수 있다.

 

캡슐화를 통해 데이터를 보호할 수 있다.