[Spring] POJO

📌 POJO 

1. 스프링이 지향하는 목적 정의 ? POJO 프로그래밍
 - 스프링은 POJO기반의 구성, 자바의 객체지향적인 특징을 살려 비지니스 로직에 충실한 개발이 가능하도록 한다
2. POJO 란 ?
3. 스프링에서의 POJO? IOC/DI, AOP, PSA
4. POJO와 Java Bean의 차이

1. POJO의 정의

POJO ?

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. 

• 객체 지향적인 원리에 충실하면서 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 그러한 POJO에 애플리케이션의 핵심로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다.

public class MyPojo {

    private String name;
    private int age;
    
    public String getName() {
	return name;    
    }
    public String getAge() {
    	return age;    
    }
    public void setName(String name) {
    	this.name = name;    
    }
    public void setAge(int age) {
    	this.age = age;    
    }
}

 

• EJB등에서 사용되는 Java Bean이 아닌 Getter와 Setter로 구성된 가장 기본적인 형태의 자바 객체
• Spring은 POJO 방식을 기반으로 한 웹 프레임워크

EJB(Enterprise JavaBeans)란 자바 개발에 있어 트랜잭션, 보안 등 로우레벨의 로직을 신경쓰지않고 어플리케이션을 쉽게 만들어 준 기술이다. 하지만, EJB는 객체지향성을 감소시키는 단점이 있었다.

 

---

 

2. POJO의 조건

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

 

  자바언어와 꼭 필요한 API외에는 종속되지 말아야한다. EJB2와 같이 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구한다. 그럴 경우 자바의 단일 상속 제한 때문에 더이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생긴다.

 

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

 

  특정 기업의 프레임워크나 서버에서만 동작가능한 코드라면 POJO라 할 수 없다. POJO는 환경에 독립적이여야한다. 특히 비지니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경 정보나 웹 기술을 담고 있는 클래스나 인터페이스를 사용해서는 안된다. 설령 나중에는 웹 컨트롤러와 연결되서 사용될 것이 분명하더라도 직접적으로 웹이라는 환경으로 제한해버리는 오브젝트나 API에 의존해서는 안된다. 그렇게 되면 웹 외의 클라이언트가 사용하지 못하기 때문이다.

  기술적인 내용을 담은 웹 정보가 비즈니스 로직과 얽혀있으니 이해하기도 어렵다. 때문에 비지니스 로직을 담은 코드에 HTTPServletRequest, HttpSession, 캐시에 관련된 API가 등장한다면 진정한 POJO라고 할 수 없다.

 

3. 객체 지향적 원리에 충실해야한다.

 

  POJO는 객체지향적인 자바언어의 기본에 충실하게 만들어져야한다. 자바 언어 문법을 사용했다고해서 자동적으로 객체지향 프로그래밍과 객체지향 설계가 적용됬다고 볼 수는 없다. 책임과 역할이 각기 다른 코드를 한 클래스에 몰아넣어 덩치 큰 만능 클래스를 만들고 상속과 다형성의 적용이 아닌 if/switch문으로 가득 설계된 오브젝트라면 POJO라고 부르기 힘들다.

 

// 미리 지정된 클래스를 extends 하지 않기 

public class Foo extends javax.servlet.http.HttpServlet { ... }

// 미리 정의된 인터페이스를 implement 하지 않기
public class Bar implements javax.ejb.EntityBean { ... }

// 미리 정의된 어노테이션 포함하지 않기
@javax.persistence.Entity public class Baz { ... }

 

---

3. POJO의 장점 

• 깔끔한 코드
• 간편한 테스트
• 객체지향적인 설계를 자유롭게 적용

// POJO 사용하지 않은 예제
// JMS 라는 기능을 사용하기 위해서 MessageListener 인터페이스를 상속받음 

public class ExampleListener implements MessageListener {

  public void onMessage(Message message) {
    if (message instanceof TextMessage) {
      try {
        System.out.println(((TextMessage) message).getText());
      }
      catch (JMSException ex) {
        throw new RuntimeException(ex);
      }
    }
    else {
      throw new IllegalArgumentException("Message must be of type TextMessage");
    }
  }

}

// POJO기반으로 작성한 예제
// 상속받지 않고 어노테이션을 통해 객체를 주입받음

@Component
public class ExampleListener {

  @JmsListener(destination = "myDestination")
  public void processOrder(String message) {
    System.out.println(message);
  }
}

---

4. POJO 프레임워크

• POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크
• 스프링 프레임워크와 하이버네이트는 대표적인 POJO 프레임워크
•  스프링을 이용하면 POJO 프로그래밍의 장점을 그대로 살려서 엔터프라이즈 애플리케이션의 핵심로직을 객체지향적인 POJO를 기반으로 깔끔하게 구현하고, 동시에 엔터프라이즈 환경의 각종 서비스와 기술적인 필요를 POJO방식으로 만들어진 코드에 적용할 수 있다.

---

5. POJO : 스프링의 핵심

•   스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드여서 POJO가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계 정보로 구분
• 일반적인 J2EE 프레임워크에 비해 특정한 인터페이스를 구현, 상속 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다.
•   스프링의 주요기술인 IoC/DI, AOP, PSA는 애플리케이션을 POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 기술이다. DI는 유연하게 확장가능한 오브젝트를 만들어두고 그 관계는 외부에서 다이내믹하게 설정해준다. 이런 DI의 개념을 스프링은 애플리케이션 전반에 걸쳐 적용한다. 

 

---

6. POJO 기반의 코드인지 확인하는 기준

POJO 프레임워크를 사용하는 것이 아닌 아래의 기준을 준수해야한다.

 

1. 객체지향적인 설계원칙에 충실하기

• 반복적인 템플릿 코드와 테스트하기 힘든 구조, 확장 및 재활용의 어려움이 남아있다면 EJB의 문제점을 여전히 안고 있는 것

 

  2. 테스트 코드를 잘 작성하기

• 잘 만들어진 POJO는 자동화된 테스트 코드 작성이 편리
• 코드 작성이 편리하면 좀 더 꼼꼼하게 만들게 되고, 코드 검증과 품질 향상에 유리해집니다.

---

7. POJO와 Java Bean의 차이

• Java Bean은 POJO이다.
• POJO는 Java Bean 이 아니다.
• POJO 는 Java bean 보다 범주가 더 넓은 개념이다.

삭제하는 방법 알려주세요 ..

// Serializable(직렬화) 인터페이스 상속 받아야한다 -> 네트워크를 통해 전송되거나 파일에 저장되는 일이
잦기 때문

public class NoPojo implements Serializable {

// 클래스의 모든 속성은 비공개     
    private static final serialVersionUID = 1;
    private String id;
    private String name;

// 인자가 없는 public 생성자가 있어야한다.
    public NoPojo() {
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

 

[Spring] POJO(Plain Old Java Object)란?

 

[Spring] POJO란?

 

Spring의 기본 특징-POJO