항해99 3기

[WIL] 항해99 3기 4주차 / POJO / Singletone Pattern / JPA

na_o 2021. 10. 10. 23:41
728x90

[POJO(Plain Old Java Object)]   

https://siyoon210.tistory.com/120

 

POJO - (Plain Old Java Object)란 뭘까?

POJO 자바나 스프링 프레임워크를 조금이라도 공부 해본 개발자 (혹은 학생)이라면 POJO 라는 단어를 한번쯤 듣게됩니다. POJO의 정의는 사실 그렇게 어렵지 않습니다. 아래 내용은 위키 백과에 나

siyoon210.tistory.com

위키백과에서 설명하는 POJO:

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서
Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. [1]
우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.
- 마틴 파울러

 

 

 

오래된 방식의 간단한 오브젝트 : 특정 기술종속되어 동작하는 것이 아닌 순수한 자바 객체를 말함

 

ORM(Object Relationship Mapping)이 새롭게 등장했을 때 ORM을 사용하고 싶다면 ORM을 지원하는 ORM 프레임워크를 사용해야 한다.(대표적으로 Hibernate 프레임워크가 있음)

만약 자바 객체가 ORM 기술을 사용하기 위해서 Hibernate 프레임워크를 직접 의존하는 순간 POJO라고 할 수 없다.

특정 기술에 종속되었기 때문이다.

 

 

 

[POJO를 지향하는 이유]

스프링 프레임워크 이전에는 원하는 엔터프라이즈 기술이 있다면 그 기술을 직접적으로 사용하는 객체를 생성해야 했으며, 이러한 개발 방식이 만연하고 있었다.

특정 기술과 환경에 종속되어 의존하게된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생겼다.

또한, 특정 기술의 클래스를 상속받거나 직접 의존하게 되어 확장성이 매우 떨어지는 단점이 있었다.

이 말은 객체지향의 화신인 자바가 객체지향 설계의 장점들을 잃어버리게 된 것이다.

 

그래서 본래의 자바 장점을 살리는 '오래된' 방식의 '순수한' 자바 객체, POJO라는 개념이 등장했다.

 

 

 

[특정 기술을 사용하고 싶다면? (스프링이 POJO를 유지하면서 Hibernate를 사용할 수 있는 이유 - PSA)]

특정 기술에 종속적이면 POJO가 아니라면서 스프링에서는 가능한 이유는?!!

스프링에서 정한 표준 인터페이스가 있기 때문이다.

스프링 개발자들은 ORM을 사용하기 위해 JPA라는 표준 인터페이스를 정해두었다.

이젠 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래 구현되어 실행된다.

이것이 스프링이 새로운 엔터프라이즈 기술을 도입하면서도 POJO를 유지하는 방법이다.

이런 방법을 스프링의 PSA라고 한다.

 

 

 

[진정한 POJO?]

토비의 스프링에서는 진정한 POJO를 아래와 같이 정의했다.

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가?
많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. ...(중략)...
진정한 POJO란 객체지향적인 원리에 충실하면서,
환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

 

 

 


[싱글톤 패턴(Singleton pattern)]

https://velog.io/@jaeeunxo1/spring-singleton

 

스프링 핵심원리 - 싱글톤패턴

웹 애플리케이션과 싱글턴 1. 싱글턴 패턴(Singleton pattern) > 소프트웨어 디자인 패턴에서 싱글턴 패턴을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최

velog.io

 

소프트웨어 디자인 패턴에서 싱글톤 패턴을 따르는 클래스는, 

생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 

최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.

 

 

 

[싱글톤 패턴을 사용하는 이유]

만약 우리가 만들었던 DI 컨테이너는 요청을 할 때마다 새로운 객체를 생성한다. 

요청이 엄청나게 많은 트래픽 사이트에서는 계속 객체를 생성하게 되면 메모리 낭비가 심하기 때문이다.

 

 

 

[싱글톤 패턴 구현]

- 순수한 DI 컨테이너

1. 객체를 생성하면 매번 새로운 객체가 생성된다.

2. 많은 객체를 생성해야 하는 서비스(ex: 배달어플 등)에서는 메모리 낭비가 많아진다.

 

 

- 싱글톤 패턴 구현

이 세 가지를 같이 적어줘야 한다

(난 처음에 다양한 방법이 있다는 뜻으로 이해해서 다양한 방법 중 세 개의 방법을 가져온 줄 알았다..ㅎ)

1. static 객체를 통해서 해당 객체를 1개만 생성할 수 있도록 지정한다.

2. static 메소드를 통해서 외부에서 생성할 수 있도록 제한한다.

3. new 연산자를 통해서 객체를 만드는 것을 private 생성자를 통해서 제한한다.

 

 

 

[싱글톤 패턴의 문제점]

1. 싱글톤 패턴을 구현하는 코드 자체가 많다.
2. 의존관계상 클라이언트가 구체 클래스에 의존한다.
3. 테스트하기 어렵다.
4. 내부 속성을 변경하거나 초기화 하기 어렵다.
5. private 생성자로 자식 클래스를 만들기 어렵다.
6. 싱글톤 컨테이너

 

스프링에서 위에 단점들을 모두 해결해준다.

 

 

 

[스프링의 싱글톤 패턴]

- 스프링 컨테이너

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리한다.

이러한 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하고 객체를 싱글톤으로 유지할 수 있다.

1. 스프링에서 싱글톤 관련 코드는 작성하지 않아도 스프링의 기능으로 빈에다가 객체를 1개 설정한다.
2. 위와 마찬가지로 객체를 새롭게 생성했지만 같은 객체를 생성한 결과를 볼 수 있다.

 

 

 

[싱글턴 방식의 주의점]

싱글톤 패턴이든, 스프링에서 객체 인스턴스를 하나만 생성해서 공유하는 상황에서 

객체 인스턴스를 공유하기 때문에 객체 상태를 유지(stateful)하게 설계하면 안된다.
price는 공유되는 필드이기 때문에 특정 클라이언트가 값을 변경한다.

 

 

 


[JPA(Java Persistence API)]

https://velog.io/@adam2/JPA%EB%8A%94-%EB%8F%84%EB%8D%B0%EC%B2%B4-%EB%AD%98%EA%B9%8C-orm-%EC%98%81%EC%86%8D%EC%84%B1-hibernate-spring-data-jpa

자세하게 적혀있으니 읽어보길..!!

 

JPA는 도대체 뭘까? (orm, 영속성, hibernate, spring-data-jpa)

JPA는 도대체 무엇일까요? orm, jdbc, 영속성, hibernate, ... 관련 지식까지 모두 파해쳐봅니다.

velog.io

자바 ORM 기술에 대한 표준 명세로, JAVA에서 제공하는 API이다.

스프링에서 제공하는 것이 아님!!!

 

자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다.


여기서 중요하게 여겨야 할 부분은, JPA는 말 그대로 인터페이스라는 점이다.

JPA는 특정 기능을 하는 라이브러리가 아니다.

스프링의 PSA에 의해서(POJO를 사용하면서 특정 기술을 사용하기 위해서)표준 인터페이스를 정해두었는데,

그중 ORM을 사용하기 위해 만든 인터페이스가 바로 JPA이다.
기존 EJB에서 제공되던 엔티티 빈을 대체하는 기술이다.
ORM이기 때문에 자바 클래스와 DB테이블을 매핑한다.(SQL을 매핑하지 않는다)