Spring boot/Spring 개념

Spring과 POJO

eunnnn 2023. 5. 1. 19:43

POJO란

상속/implements 받아 메서드가 추가된 클래스가 아닌 일반적으로 우리가 알고 있는 getter, setter 같이 기본적인 기능만 가진 자바 객체를 말한다. 즉, 특정 기술에 종속되지 않는 순수한 자바 객체를 말한다. 

public class User {
    private int id;
    private String name;
    private String email;
    
    public int getId() {
    	return id;
    }
    public String getName() {
    	return name;
    }
    public String getEmail() {
    	return email;
    }
    
    public void setId(int id) {
    	this.id = id;
    }
    public void setName(String name) {
    	this.name = name;
    }
    public void setEmail(String email) {
    	this.email = email;
    }
}

 

반대로 POJO 개념을 사용하지 않은 예시를 확인해보자.

import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class OrdersService implements SessionBean {

    private SessionContext ctx;

    public Orders placeOrder(String menuName) {
        Orders orders = new Orders(menuName);
        orders.init()
        return orders;
    }

    @Override
    public void setSessionContext(SessionContext ctx) throws EJBException {
        this.ctx = ctx;
    }

    @Override
    public void ejbRemove() throws EJBException {

    }

    @Override
    public void ejbActivate() throws EJBException {

    }

    @Override
    public void ejbPassivate() throws EJBException {

    }
}

이는 Spring 등장 이전에 자바 애플리케이션 시장을 독점하고 있던 EJB 기술 기반으로 작성 된 코드다. 코드를 확인 해 보면 특정 서비스 계층에 EJB라는 기술이 마구 침투하는 모습을 확인할 수 있다. import 선언문부터 implenets, 인스턴스 변수까지 코드가 EJB에 완전히 종속되어 있음을 확인할 수 있다.

EJB의 사용과 프로그램의 규모 증가로 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 생기게 되고 또한, 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지며 점점 객체지향성을 잃어갔다.
그래서 개발자들은 옛날 순수한 객체지향성이 컸던 시절로 돌아가자는 취지로 POJO를 개발하게 되었다.

 

POJO의 조건

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

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

 

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

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

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

 

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

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

 

스프링과 POJO

 POJO 프레임워크란 POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크이다. 스프링 프레임워크와 하이버네이트를 대표적인 POJO 프레임워크로 꼽을 수 있다.

 

Spring은 엔터프라이즈 서비스들을 POJO 기반으로 만든 비즈니스 오브젝트에서 사용할 수 있게 해준다.

스프링의 주요 기술인 Ioc/DI, AOP, PSA는 애플리케이션을 POJO로 개발할 수 있게 해주는 가능 기술들이며, 이것들은 모두 스프링이 있기 전에도 여러 가지 형태로 시도됐고 발전하던 기술이었다.

IoC 컨테이너를 제공해서, 인스턴스들의 라이프 사이클을 관리하고, 특정 인터페이스를 구현하거나 상속할 필요가 없고 라이브러리를 지원하기에 용이하며 객체 또한 가볍게 만들 수 있다. 

또한 OOP를 더 OOP답게 쓸 수 있게 해주는 AOP 기술을 적용해서 공통기능을 상속/위임 없이 개발할 수 있어  POJO 개발을 더 쉽게 만들었다.

 

 

 

출처