소프트웨어에 배움은 끝이 없다고 생각합니다.


그렇기 때문에 지식 들에도 무한한 발전이 가능하며 포스팅 들에 대한 피드백을 지속적으로 받아 업데이트할 예정입니다.


건강한 토론은 언제든 환영합니다.


많은 피드백 부탁드립니다. :)



Spring 을 공부하다보면 빠지지않고 등장하는 개념이 바로 POJO(Plain Old Java Object) 이다.


이는 정말 단순한 개념이지만, 개인적으로 Spring Framework 라는 훌륭한 프레임워크를 만들게 되는 철학의 가장 밑바탕을 구성하고 있다고 생각하는


핵심적인 개념이다. 개인적으로 공부하고자 이 글을 보게되었다면 이해하고 넘어가야한다고 생각한다.



POJO 의 개념 : 주로 특정 자바 모델이나 기능, 프레임워크를 따르지  않는 Java Object를 지칭한다.


거창해보이지만 다음 예제를 보면 간단해진다.

 


public class MyPojo {
private int name;
private int value;

public int getName() {
return name;
}
public int getValue() {
return value;
}
public void setName(int name) {
this.name = name;
}
public void setValue(int value) {
this.value = value;
}
}



그렇다 위와 같은 가장 기본적인 형태의 Java 객체를 POJO라 한다.


좀 더 자세히 명시하자면...


EJB 등에서 사용되는 Java Bean 이 아닌 Getter 와 Setter 로 구성된 가장 순수한 형태의 기본 클래스를 POJO라 하며, 이는 Spring에서 고안된 철학의 핵심적인 부분을 구성하는 요소로 사용된다



향후 포스트를 통해 언급하게 되겠지만 Spring 에서 고안된 중요한 철학은 바로 "복잡성의 해결 을 통한 생산성의 향상" 이다. 


이를 위해서 POJO 는 EJB 의 Bean 에 비해 훌륭한 객체의 단위가 될 수 있다.


그 이유로 먼저 POJO는 그 자체로 객체지향 철학이 반영된 가장 기본적인 단위의 객체이다. 


객체의 상태와 동작을 정의하는 Member variable 과 Method 를 독자적으로 가질 수 있으며 그 자체로 하나의 객체를 묘사할 수 있다. 


또한, 상속성, Interface 등의 여러가지 기술에 의해 종속되지 않는 객체이기 때문이다.  


Java가 급격히 발전해가는 비즈니스 요구를 효과적으로 만족시키고자 Enterprise Java 로 진화하면서 생겨난 EJB는 

오히려 과도한 Over engineering 때문에 객체지향 철학 자체를 효과적으로 구현할 수 없었던 아이러니를 가졌으며, 

이는 개발자들의 시선을 다시 POJO로 향하게 만들었다. 


POJO 의 단순한 구조는 Over engineering 으로 인한 복잡성을 해결하고 모듈화시킬 수 있는 부분에서 큰 이점을 가진 보다 나은 형태의 구조 였고, 이후 개발된 Spring과 같은 POJO 기반의 프레임워크 들은 이러한 이점을 살려 보다 효과적인 기술 스택으로 자리잡을 수 있었다.




블로그 시작을 알리는 첫글 입니다 ^^


개인적으로 경험하고 배웠던 많은 것들을 공유하고 싶습니다.


저에게도 방문해주시는 분들에게도 큰 도움이 되길 바랍니다.

+ Recent posts