일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- null 병합 연산자
- AWS
- 단축 평가
- 자바스크립트
- Kubernetes
- prometheus
- docker swarm
- 온프레미스
- transit gateway
- elasticsearch
- On-Premise
- Proxy Resource
- DynamoDB
- grafana
- CloudFormation
- 옵셔널 체이닝
- Service
- api gateway
- optional chaining
- 구조분해 할당
- Custom Resource
- 비구조화 할당
- cognito
- Endpoints
- VPC
- JavaScript
- Site-to-Site VPN
- docker
- vgw
- Await
- Today
- Total
만자의 개발일지
[Spring] POJO란? 본문
자바를 조금이라도 공부해본 사람은 POJO 라는 단어를 한번쯤을 들어봤을텐데, 이번에는 이 POJO에 대해서 포스팅하도록 하겠습니다.
POJO(Plain Old Java Object)
아래는 위키백과에 있는 POJO의 정의 입니다.
https://ko.wikipedia.org/wiki/Plain_Old_Java_Object
Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다.
“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.”
— 마틴 파울러 —
POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다.
POJO, 오래된 방식의 간단한 자바 오브젝트라고 하는데 오래된 방식의 간단한 자바 오브젝트가 무엇일까요?
POJO란 특정 기술에 종속되지 않는 순수한 자바 객체를 의미합니다.
예를들어, 특정 기술을 사용하기 위해 특정 프레임워크를 의존하게되면 그것은 POJO라고 할 수 없습니다.
특정 기술에 종속되어있기 때문입니다.
예시를 들어봅시다.
public class UserDTO {
private String userName;
private String userId;
private String userPassword;
public String getUserName() {
return userName;
}
public void setUserName(String userName) {
this.userName = userName;
}
public String getUserId() {
return userId;
}
public void setUserId(String userId) {
this.userId = userId;
}
public String getUserPassword() {
return userPassword;
}
public void setUserPassword(String userPassword) {
this.userPassword = userPassword;
}
}
위 객체는 기본적인 자바 기능인 getter, setter 기능만 가지고 있습니다.
특정 기술에 종속되어 있지 않은 순수 자바 객체이기 때문에 위 객체는 POJO라고 할 수 있습니다.
반대의 예시를 들어봅시다.
public class WinExam extends WindowAdapter {
@Override
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
이처럼 Window의 기능을 사용하기 위해 WindowAdapter 클래스를 상속받을 것을 보실 수 있습니다.
이렇게 되면 다른 솔루션을 사용하고자 할 때 많은 양의 코드를 리팩토링해야하는 문제가 있습니다.
이처럼 특정 기술과 환경에 종속되어 의존하게 되면, 코드 가독성 뿐만아니라 유지보수, 확장성에도 어려움이 생깁니다.
이러한 객체지향의 장점을 잃어버린 자바를 되살리기 위해 POJO라는 개념이 등장한 것입니다.
토비의 스프링에서는 POJO를 다음과 같이 정의하였습니다.
그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가? 많은 개발자가 크게 오해하는 것 중의 하나가 바로 이것이다. ...(중략)...
진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.
"진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트이다"
참고
- https://siyoon210.tistory.com/120
- https://velog.io/@galaxy/Spring%EC%9D%98-%EA%B8%B0%EB%B3%B8-%ED%8A%B9%EC%A7%95-POJO
'Java > Spring' 카테고리의 다른 글
[Spring] IoC와 DI (1) | 2022.02.11 |
---|---|
[Spring] 이클립스 Spring 프로젝트 생성 (1) | 2022.01.18 |