본문 바로가기
IT/Spring boot

[Spring boot] POJO (Plain Old Java Object)

by kyu-nahc 2024. 8. 10.
반응형

POJO (Plain Old Java Object)

위 이미지는 Spring 삼각형이라는 이미지로 Spring의 핵심 개념들을 표현하고 있다.

POJOIoC / DI, AOP, PSA를 통해서 달성할 수 있다는 것을 의미한다.

 

POJO란 Plain Old Java Object의 약자로,  Java로 생성하는 순수한 객체를 뜻한다.

 

이를 해석하면 POJO는 객체 지향적인 원리에 충실하면서 환경과 기술에 종속되지 않고,

필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 의미한다.

이러한 POJO에 애플리케이션의 핵심 로직과 기능을 담아 설계하고 개발하는 방법을

POJO 프로그래밍이라고 한다.

 

 

POJO 프로그래밍

POJO 프로그래밍은 POJO를 이용하여 프로그래밍 코드를 작성하는 것이다.

그러나 순수 자바 객체만을 사용한다고 해서 POJO 프로그래밍이라고 볼 수는 없다.

POJO 프로그래밍으로 작성한 코드가 되기 위해서는 기본적인 규칙들을 지켜야 한다.

 

 

Java나 Java의 스펙에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.

다음 코드는 getter와 setter만 가지고 있는 코드의 에제이다.

아래 객체는 기본적인 자바 기능인 getter, setter 기능만 가지고 있다.

특정 기술에 종속되어 있지 않은 순수 자바 객체이기 때문에 위 객체는 POJO라고 할 수 있다.

public class User {

    private String id;
    private String password;

    public String getId() {
        return id;
    }

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

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
}

 

다음은 특정 기술에 종속되어 있는 예제이다.

public class WindowExam extends WindowAdapter {

	@Override
	public void windowClosing(WindowEvent e) {
		System.exit(0);
	}
}

 

위의 코드는 Window의 기능을 사용하기 위해

WindowAdapter 클래스를 상속받은 코드이다.

하지만 이렇게 되면 다른 솔루션을 사용하게 될 때, 많은 양의 코드를 리팩토링 해야 한다.

 

이처럼 특정 기술과 환경에 종속되어 의존하게 되면,

코드 가독성뿐만 아니라 유지보수, 확장성에도 어려움이 생긴다.

 

 

특정 환경에 종속적이지 않아야 한다.

이는 특정한 프레임워크에서만 동작이 가능하면 안 된다는 의미를 가진다.

POJO는 환경에 독립적이어야 한다.  특히, 비즈니스 로직을 담고 있는 POJO 클래스는

웹 기반의 환경 정보나 웹 기술을 담고 있는 클래스 또는 인터페이스를 사용하면 안 된다.

 

웹 컨트롤러와 연결하여 사용하더라도,

직접적으로 사용 환경을 웹으로 제한하거나 웹에서만 동작하는 API를 직접 사용하지 말아야 한다.

이러한 이유는 웹 이외의 클라이언트는 해당 기능을 요청할 수 없기 때문이다.

따라서 비즈니스 로직을 담는 코드에 HTTPServletRequest, HttpSession, 캐시 등에

관련된 API를 사용하게 된다면 POJO라 할 수 없다.

 

서블릿(Servlet) 기반의 웹 애플리케이션을 실행시키는

서블릿 컨테이너(Servlet Contatiner)인 아파치 톰캣(Apache Tomcat)을 순수 Java로 작성한

애플리케이션 코드 내에서 Tomcat이 지원하는 API직접 가져다가 사용한다고 가정한다.

이후 시스템의 요구 사항이 변경되어 톰캣에서 Zetty라는 다른 서블릿 컨테이너를 사용하게 된다면,

애플리케이션 코드에서 사용하고 있는 Tomcat API 코드들을 모두 제거하고 Zetty로 수정해야 한다.

최악의 경우 애플리케이션을 전부 수정해야 하는 상황에 직면할 수도 있다.

 

따라서, Java 이외의 다른 기술에 얽매이지 않으며,

특정 환경에 종속적이지 않아야 POJO 프로그래밍이라고 할 수 있다.

 

 

POJO 프로그래밍이 필요한 이유

  1. 특정 환경이나 기술에 종속적이지 않으면 재사용이 가능하고,
     확장 가능한 유연한 코드를 작성할 수 있다.
  2. 저수준 레벨의 기술과 환경에 종속적인 코드를 제거하여
     코드를 간결해지며 디버깅하기에도 상대적으로 쉬워진다.
  3. 특정 기술이나 환경에 종속적이지 않기 때문에 테스트가 단순해진다.
  4. 객체지향적인 설계를 제한 없이 적용할 수 있다.

 

POJO와 Spring의 관계

SpringPOJO 프로그래밍을 지향하는 프레임워크이다.

POJO 프로그래밍 코드를 작성하기 위해 Spring 프레임워크에서는 IoC/DI, AOP, PSA를 지원하고 있다.

IoC, DI, AOP와 같은 개념들이 모두

결합력을 느슨하게 하여 의존성을 낮추어 종속성을 낮게 해주는 것이다.

Spring의 POJO 개념을 지킨 코드를 보면 다음과 같다.

public class SpringPOJOClass{

    @Autowired
    UserRepository userRepository;
   
    public List<User> findAllUser(){
        userRepository.findAll();
    }
}

 

다음과 같이 @Autowired를 활용하여 의존성 주입을 하여 느슨한 결합력을 갖게 되면서, 

직접적으로 extendsimplements를 하지 않아도 해당 클래스의 메소드에 접근할 수 있게 된다. 

이렇게 되면 당연히 POJO를 무시한 코드에 비해 많은 장점이 존재하는데, 

extends를 하여 직접 메소드를 Override 하여 작성하지 않아도 되면서

UserRepository 코드에 변경이 생겨도 같이 변하는 장점이 있다.

 

 

참고자료

https://ittrue.tistory.com/211

반응형

loading