PSA란 환경의 변화와 관계없이 일관된 방식의 기술로의 접근 환경을 제공하는 추상화 구조를 말한다. POJO원칙을 철저히 따른 Spring의 기능으로 Spring에서 동작할 수 있는 Library들은 POJO원칙을 지키게끔 PSA형태의 추상화가 되어있음을 의미한다. 추상화 계층을 사용하여 어떤 기술을 내부에 숨기고 개발자에게 편의성을 제공해주는 것이 서비스 추상화(Service Abstraction)이다. 하나의 추상화로 여러 서비스를 묶어둔 것을 Spring에서 Portable Service Abstraction이라고 한다. PSA 예시 Spring Web MVC 원래 Servlet을 사용하려면 HttpServlet을 상속받은 클래스를 만들고 Get, Post 등에 대한 메소드를 오버라이딩하여 사용해야 한다.

@Bean @Bean은 메소드 레벨에서 선언하며, 반환되는 객체(인스턴스)를 개발자가 수동으로 빈으로 등록하는 애노테이션이다. 1 2 3 4 5 6 7 @Configuration public class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(); } } @Component @Component는 클래스 레벨에서 선언함으로써 스프링이 런타임시에 컴포넌트스캔을 하여 자동으로 빈을 찾고(detect) 등록하는 애노테이션이다. 1 2 3 4 @Component public class Utility { // ... } @Bean vs @Component @Bean의 경우 개발자가 컨트롤이 불가능한 외부 라이브러리들을 Bean으로 등록하고 싶은 경우에 사용된다.

@RequestBody 클라이언트가 body에 JSON 또는 XML 형태로 값(보통 객체)을 담아 전송하면, body의 내용을 다시 Java Object(객체)로 변환해주는 역할을 수행한다. 이 데이터는 Spring에서 관리하는 MessageConverter들 중 하나인 Jackson2HttpMessageConverter를 통해 Java 객체로 변환된다. DTO에 기본 생성자가 필요한 이유 RestController에서 @RequestBody의 바인딩은 Jackson라이브러리의 ObjectMapper가 해준다. ObjectMapper는 @RequestBody가 Property로 구현되어 있거나 생성을 위임한 경우가 아니라면 기본 생성자로 생성한다. 따라서 두 상황이 아니라면 기본 생성자는 꼭 필요하다. Setter가 필요없는 이유 ObjectMapper는 Setter 또는 Getter로 DTO의 필드를 가져온다.

Resizable Array Array는 static하다(길이 고정). Array 객체를 생성한 후에는 Array의 길이를 마음대로 변경할 수 없다. 따라서, 정해진 길이의 배열을 모두 채우면, 새로운 데이터를 추가하고 싶을 경우 새로운 배열을 만들어주어야 한다. ArrayList ArrayList는 사이즈가 dynamic하다. 하지만 내부적으론 배열로 구성되어 있다. ArrayList는 Default로 10개의 공간을 가진 배열로 시작한다. 하지만 최적화(지연 초기화)로 인해 막 생성하면 0개의 사이즈로 시작된다. 각각의 ArrayList Object는 ArrayList의 size를 나타내는 capacity 인스턴스 변수를 가지고 있다. ArrayList에 요소들이 더해지면 ArrayList의 capacity 또한 자동적으로 늘어난다.

Bean은 스프링에서 사용하는 POJO 기반 객체다. 상황과 필요에 따라 Bean을 사용할 때 하나만 만들어야 할 수도 있고, 여러개가 필요할 때도 있고, 어떤 한 시점에서만 사용해야할 때가 있을 수 있다. 이를 위해 Scope를 설정해서 Bean의 사용 범위를 개발자가 설정할 수 있다. 우선 따로 설정을 해주지 않으면, Spring에서 Bean은 Singleton으로 생성된다. 특정 타입의 Bean을 딱 하나만 만들고 모두 공유해서 사용하기 위함이다. 보통은 Bean을 이렇게 하나만 만들어 사용하는 경우가 대부분이지만, 요구사항이나 구현에 따라 아닐 수도 있을 것이다.

싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. 하지만 싱글톤 패턴은 다음과 같은 문제점들을 가지고 있다. 싱글톤 패턴 문제점 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다. 테스트하기 어렵다. 내부 속성을 변경하거나 초기화 하기 어렵다.