2주차 과제 리뷰 (4팀)

[Integerous]

2주차 과제 수고하셨습니다!

전반적으로 핵심답변의 내용이 명료하고 핵심을 잘 찌르고 있습니다!
다른 팀들보다 답변 수준이 높아서, 제가 피드백 드릴게 많지 않네요ㅎ

정리한 내용들 퀄리티가 좋아서, 스터디 기간이 끝나도 저도 이 저장소에 계속 머물고 싶을 정도에요ㅎ
정리하느라 고생하셨겠어요. 훌륭합니다!

POJO

예상 추가질문

1. POJO와 Java bean, Spring bean는 같은 것들인가요?

DI/IoC

예상 추가질문

1. IoC가 무엇인지는 아시는 것 같은데, IoC가 필요한 이유는 무엇인가요? 왜 외부에서 제어 흐름을 관리해야하죠?
2. BeanFactory와 ApplicationContext는 각각 무엇인가요?

MVC - 프론트 컨트롤러 패턴

피드백

• 프론트 컨트롤러 패턴은 신입 개발자 면접에서 나올만한 질문은 아닙니다. 프론트 컨트롤러 패턴은 디자인 패턴이라기보다 아키텍쳐 패턴에 가깝기 때문입니다.
• 실무에서는 프론트 컨트롤러 패턴에 대해 고려하기 보다 디자인 패턴인 Facade Pattern을 주로 사용합니다.
• 하지만 이 질문은 매우 중요한 내용이니 반드시 숙지하셔야합니다.

MVC - Dispatcher Servlet 동작 원리

피드백

• Dispatcher Servlet 앞, 뒤에서 동작하는 Filter와 Interceptor의 차이와 활용에 대해서도 준비하시는 것이 좋습니다. 면접 단골 질문이에요-!
  밑에서 제대로 해주셨네요ㅋㅋ

예상 추가질문

1. Dispatcher Servlet은 어느 시점에 생성되나요?
2. Dispatcher Servlet이 Controller 객체를 직접 메모리에 생성하나요?
   • 직접 생성하지 않는다면 무엇이 그 역할을 수행하나요?
3. DispatcherServlet이 생성된 이후의 과정은 잘 알고 계신 것 같은데, 웹 어플리케이션이 실행된 이후부터 DispatcherServlet이 생성되기전까지 Spring framework가 어떤 준비를 하는지 설명해주실 수 있나요?
4. Filter와 Interceptor의 공통적인 용도는 무엇인가요?
5. Filter와 Interceptor는 Web Application과 Spring Context중 각각 어디에 등록될까요?
6. Filter와 Interceptor에서 예외가 발생하면 Web Application과 Spring Context중 각각 어디에서 처리되나요?
7. View를 렌더링하기 전에 추가작업을 할 수 있는 것은 Filter인가요? 아니면 Interceptor인가요?
8. 웹 어플리케이션의 API를 개발할 때 Interceptor를 활용하기 적합한 기능을 생각나는대로 말해주세요.

AOP

피드백

• AOP는 JointPoint, PointCut 같은 세세한 기능의 활용에 대한 질문보다는 AOP의 기본적인 개념과 Spring에서 AOP를 어떻게 응용하고 활용하는지에 대한 질문이 주로 나오는 편입니다.

예상 추가질문

1. 프로젝트에서 AOP를 활용한 부분이 있으실까요?
   • 사용자 인증과 로깅을 구현하셨던데 이건 AOP를 활용한 것이 아닌가요?
   • 그럼 @transactional 어노테이션은 AOP를 활용한 기능인가요?
2. 만약 프로젝트의 모든 Entity에서 Entity 생성시간과 수정시간 필드를 사용한다면, 이 필드를 한 곳에서 관리할 수 있는 방법이 있을까요? Spring framework를 사용하는 환경입니다.

Spring에서 CORS 에러를 해결하는 방법

피드백

• 저도 이 문제는 닥치면 구글링해서 해결하고 새까맣게 잊는 편인데 잘 정리하셨네요ㅎ 저도 배워갑니다ㅎ

Bean

예상 추가질문

1. Spring framework로 웹 어플리케이션을 개발할 때 Bean Scope 중 프로토타입 스코프는 어떤 경우에 활용하면 좋을까요?

Getter, Setter

피드백

• Setter를 데이터 무결성과 연결하시면 면접관들이 읭?하실 가능성이 있습니다. 물론 추가 설명하시면 이해하시겠지만, Setter보다는 Builder 패턴이나 SOLID 개방폐쇄원칙에 더 적합한 주제입니다.

DTO

피드백

• 단순히 데이터를 객체 형식으로 넘기기 위해서만 사용하는 것은 아닙니다.
• 실무에서 API 개발시에도 DTO는 정말 자주 활용됩니다. 때문에 면접에서는 DTO의 개념에 대해 묻는 것에 그치지 않고, DTO를 실제로 활용할 때 Serialize/Deserialize와 ObjectMapper가 중요한 이슈이기 때문에 이 점에 대해 질문이 들어올 수 있습니다. 만약 개인/팀 프로젝트에서 DTO를 사용하셨다면 더더욱 준비하셔야 합니다.
• DTO로 넘긴 데이터가 어떻게 JSON 형식으로 변환되고, JSON 데이턱 어떻게 객체에 매핑되는지, 그 과정에서 어떤 라이브러리가 관여하는지, Serialize/Deserialize를 하는 이유는 무엇인지 등을 학습해두세요-!

Spring 에서의 예외 처리

피드백

• 신입 개발자에게 이 내용을 자세하게 물어볼 가능성은 낮습니다.
• 경력 개발자 이직 면접에서 예외 처리는 어떻게 하셨어요~?라고 시작되는 질문의 꼬리물기 질문에서 자주 나오는 내용입니다.
• ExceptionHandler는 나중에는 실무에서도 결국 사용할 가능성이 높고, 경력 개발자로 이직할 때 과제 전형이 있는 경우, ExceptionHandler를 활용해서 예외 처리를 공통적으로 처리하면 좋은 평가를 받을 가능성이 높기 때문에 미리 알아두시는 것은 정말 좋습니다.

JPA

피드백

• 3주차 내용으로 옮겨주세요-!

[KKHoon210417]

POJO

• POJO와 Java bean, Spring bean는 같은 것들인가요?

  → 아닙니다. java bean 과 spring bean은 pojo의 대상이 될 수 있지만 같지는 않습니다.

  • pojo는 특정 환경이나 규약에 종속받지않는 순수 자바 객체입니다.

  • java bean은 이 pojo에서 특정 조건이 더해진 자바 객체를 의미합니다.

    • Fields는 접근 제어자가 private, getter와 setter로만 접근 되어야만 한다.
      • 캡슐화를 위해서다.
    • Constructor는 argument를 가지면 안된다.
      • Class 내의 인자가 있는 생성자를 추가학 되면, 컴파일러는 default 생성자를 생성하지 않게 되기 때문이다.
    • Serializable 인터페이스를 상속받아야 한다.
      • Java Bean이 네트워크를 통해 전송되거나 파일에 저장되는 일이 잦기 때문이다.

  • spring bean 은 스프링 컨테이너가 관리하는 자바객체를 말합니다. 그 자바 객체가 POJO가 될 수 도 있고, 아닐 수 도 있습니다.

Bean

예상 추가질문

1. Spring framework로 웹 어플리케이션을 개발할 때 Bean Scope 중 프로토타입 스코프는 어떤 경우에 활용하면 좋을까요?

→ spring scope를 prototype으로 설정해준다면, bean으로 의존성을 주입할때마다, 새로운 객체가 반환되므로,

→ 만들어진 객체 각각의 상태를 개별적으로 기억해야하는 Stateful한 상황에 쓰이면 좋을거 같습니다.

→ 예컨대 여러 사람이 같은 객체를 사용해야 하는 경우 요청시마다 Bean 객체가 생성되기 때문에 데이터 변경이나 충돌 현상을 방지할 수 있습니다.

DI/IoC

• IoC가 무엇인지는 아시는 것 같은데, IoC가 필요한 이유는 무엇인가요? 왜 외부에서 제어 흐름을 관리해야하죠?

  → 객체 지향 원칙을 잘 지키기 위해 IoC가 필요합니다. 객체를 관리하는 프레임워크와 개발자가 개발해야 하는 필수 비즈니스 로직을 분리하여 결합도는 낮추고 응집도를 높여줄 수 있기 때문입니다.

  → 클래스내부에서 클래스를 직접 생성하게 되어 두 클래스간의 변경 사항이 생길 경우 서로에게 많은 영향이 끼치겠지만,

  외부에서 제어 흐름을 통해 클래스에 주입해주게 되면 사용하면 두 클래스 간의 의존성이 줄어들게 됩니다.

• BeanFactory와 ApplicationContext는 각각 무엇인가요?

→ 스프링 컨테이너로 BeanFactory와 ApplicationContext를 사용합니다.

• BeanFactory는 Bean을 등록, 생성, 조회, 반환 관리를 합니다.일반적으로는 BeanFactory를 사용하는 경우보다 BeanFactory를 확장해 만들어진 ApplicationContext를 주로 사용합니다.

• ApplicationContext는 BeanFactory의 특징을 그대로 가지고 있으면서, 동시에 스프링 AOP 통합과 국제화 지원, 이벤트 기반 애플리케이션이나 웹 애플리케이션을 위한 기능을 제공합니다.

• 둘의 다른 차이 - 빈 로딩 시점

  • ApplicationContext 인터페이스를 구현한 컨테이너들은 실행 시점에 모든 빈을 로딩하기 때문에 무거운 컨테이너라고 이야기 합니다.
  • 이 뿐만 아니라, BeanFactory에 비해 다양한 편의 기능들을 가지고 있으니 더 무겁습니다.
  • 반면, BeanFactory만을 구현한 컨테이너들은 DI 관점만 가지고 있고, 빈을 필요할 때 로딩해주기 때문에 가벼운 경량 컨테이너라고 이야기 합니다.

MVC - Dispatcher Servlet 동작 원리

피드백

예상 추가질문

• Dispatcher Servlet은 어느 시점에 생성되나요?

  → Spring 앱이 실행되어 내부 tomcat이 실행되면서, 서블릿 컨텍스트를 초기화할때 옵션에 따라 lazy loading 혹은 pre loading 방식으로 생성됩니다

  • lazy loading의 경우 처음에는 서블릿 컨테이너에 디스패처 서블릿 인스턴스가 존재하지 않으며, 최초의 요청을 받을 때, 객체를 생성하고 이후에는 싱글톤으로 활용합니다.
  • Pre loading의 경우 서블릿 컨텍스트를 초기화하는 시점에 미리 디스패처 서블릿 인스턴스를 생성합니다.

• Dispatcher Servlet이 Controller 객체를 직접 메모리에 생성하나요?

  • → 아닙니다. Controller 객체는 Bean으로써 Spring IoC컨테이너에 담겨있고,

    • Front-Controller 역할을 하는 DispatcherServelt이 request를 받으면 요청에 맞는 url을 가지는 controller를 선택하는 일을 HandlerMapping에게 요청합니다.
    • HandlerMapping은 적합한 Controller를 선택합니다.

  • (튜터님께 질문) - 직접 생성하지 않는다면 무엇이 그 역할을 수행하나요?

• DispatcherServlet이 생성된 이후의 과정은 잘 알고 계신 것 같은데, 웹 어플리케이션이 실행된 이후부터 DispatcherServlet이 생성되기전까지 Spring framework가 어떤 준비를 하는지 설명해주실 수 있나요?

  1. 웹 어플리케이션이 실행되면, Tomcat에 의해 web.xml이 Loading됩니다.

  2. web.xml에 등록되어 있는 ContextLoaderListener (Java Class) 생성됩니다.

     • ContextLoaderListener 클래스는 ServletContextListener 인터페이스를 구현하고 있으며, ApplicationContext를 생성하는 역할을 수행합니다. Servlet의 생명주기를 관리해줍니다.

  3. 생성된 ContextLoaderListener는 root-context.xml을 Loading합니다.

     • ContextLoaderListener 객체는 src/main/resources 소스 폴더에 있는 applicationContext.xml 파일을 로딩하여 스프링 컨테이너를 구동하는데 이를 Root 컨테이너라고 합니다.

  4. root-context.xml에 등록되어 있는 Spring Container가 구동됩니다.

     • root-context.xml에는 주로 view 지원을 제외한 공통 bean을 설정합니다.
     • 예) spring properties 파일을 로컬과 서버용으로 구분지을 때 여기서 propery value를 설정해줍니다.

  5. 클러이언트로부터 최초의 웹 어플리케이션 요청이 오면, DispatcherServlet이 생성됩니다.

     

AOP

피드백

예상 추가질문

• 프로젝트에서 AOP를 활용한 부분이 있으실까요?

  → 에러 처리를 위해 @RestControllerAdvice 어노테이션과 @ExceptionHandler를 이용해 AOP방식으로 전역 처리에 사용하였습니다.

  • 사용자 인증과 로깅을 구현하셨던데 이건 AOP를 활용한 것이 아닌가요?

    → AOP를 사용하면 인증, 로깅, 트랜잭션 등의 횡단 관심사를 핵심 로직으로부터 분리해 공통적으로 필요한 부분에 적용할 수 있습니다. 하지만 프로젝트에서는 SpringSecurity를 이용해 인증을 진행 하였습니다. SpringSecurity는 Spring MVC에 포함되는 않는 Filter의 영역이므로 AOP를 활용한 것은 아닙니다.

    하지만 만약 AOP 방식을 활용한다면, AOP pointcut 기능을 이용해서 모든 요청이 서블릿으로 들어올 때 before pointcut을 걸어두고 사용자 인증을 진행할 수 있을 것 입니다.

  → 로깅은 기존 서비스 로직에 로깅하는 코드(cross-cutting)를 제거하고, 핵심 로직에서 분리하여 핵심 로직은 수정하지 않고도 원하는 곳에 적용할 수 있도록 하였습니다.

  • 그럼 @transactional 어노테이션은 AOP를 활용한 기능인가요?

    → 맞습니다. @transactional은 어노테이션 기반 AOP를 통해 구현되었기 때문에 아래와 같은 특징이 있습니다.

    • 클래스, 메소드에 @transactional이 선언되면 해당 클래스에 트랜잭션이 적용된 프록시 객체 생성
    • 프록시 객체는 @transactional이 포함된 메서드가 호출될 경우, 트랜잭션을 시작하고 Commit or Rollback을 수행
    • CheckedException or 예외가 없을 때는 Commit
    • UncheckedException이 발생하면 Rollback

    → 한편, Spring에는 AOP를 구현하는 두가지 프록시 구현체가 있는데, 하나는 Dynamic Proxy(JDK Proxy) 그리고 다른 하나는 CGLIB입니다. 비즈니스 로직을 구현할 때 클래스보다 인터페이스로 유연하게 설계할 것을 권장하고 있으므로 인터페이스와 구현체로 이루어진 구성에서는 Dynamic Proxy를 이용합니다. 하지만 Spring Boot에서는 CGLIB가 예외를 덜 발생시키는 장점이 있어 CGLIB를 기본으로 적용하여 사용하는 것으로 알고 있습니다.

• 만약 프로젝트의 모든 Entity에서 Entity 생성시간과 수정시간 필드를 사용한다면, 이 필드를 한 곳에서 관리할 수 있는 방법이 있을까요? Spring framework를 사용하는 환경입니다.

  → JPA Auditing을 사용하여 생성시간과 수정 시간을 자동화 할 수 있습니다. 
  

  1. Domain 패키지에 TimestampEntity 클래스를 작성하고,

  2. 생성 및 수정 시간을 자동화 하고 싶은 Entity 클래스에 상속시킨 후

  3)스프링 부트의 Main함수 클래스에 @EnableJpaAudting을 선언해 주면 됩니다.

  /*Timestampe Entity*/
  @MappedSuperclass // 상속했을 때, 컬럼으로 인식하게 합니다.
  @EntityListeners(AuditingEntityListener.class) // 생성/수정 시간을 자동으로 반영하도록 설정
  public class Timestamped {
      @CreatedDate // 생성일자임을 나타냅니다.
      private LocalDateTime createdAt;
  
      @LastModifiedDate // 마지막 수정일자임을 나타냅니다.
      private LocalDateTime modifiedAt;
  }
  
  /*Spring Application*/
  @SpringBootApplication
  @EnableJpaAuditing
  public class MaruMaruSpartaVerSpringApplication {
     public static void main(String[] args) {
        SpringApplication.run(MaruMaruSpartaVerSpringApplication.class, args);
     }
  }

Getter, Setter

피드백

• Setter가 무결성을 지켜준다고 했는데, 그럼 Setter를 사용하는게 바람직하다고 볼 수 있을까요?
  바람직하지 않다면 어떤 방식을 사용하는게 바람직하다고 볼 수 있을까요?

  네 무분별하게 Setter를 사용하는 것은 바람직하지 않다고 생각합니다.

  그 이유로는 첫번째로 Setter 메소드는 의도를 갖기 힘듭니다.

  두번째로 Setter가 있으면 객체를 언제든지 변경할 수 있는 상태가 되어서 객체의 안전성이 보장받기 힘들기 때문입니다.

  객체를 생성할 때, Setter 대신 Builder 기반으로 생성하는 방법이 있습니다. Builder 패턴을 사용하면 다음과 같은 장점이 있습니다.

  public static class SignUpReq {
  
  	private com.cheese.springjpa.Account.model.Email email;
  	private Address address;
  
  	@Builder
  	public SignUpReq(Email email, String fistName, String lastName, String password, Address address) {
          this.email = email;
          this.address = address;
  	}
  
  	public Account toEntity() {
          return Account.builder()
              .email(this.email)
              .address(this.address)
              .build();
  	}
  }
  
  public Account create(AccountDto.SignUpReq dto) {
      return accountRepository.save(dto.toEntity());
  }

  • 인자가 많을 경우 쉽고 안전하게 객체를 생성할 수 있습니다.
  • 인자의 순서와 상관없이 객체를 생성할 수 있습니다.
  • 적절한 책임을 이름에 부여하여 가독성을 높일 수 있습니다.

  @Builder
      public Order(Address address, List<Product> products) {
    	    // Assert.notNull을 사용하여, 객체가 null이거나 empty인 경우에는 객체 생성 못하게 막을 수 있다
  	    Assert.notNull(address, "address must not be null"); 
          Assert.notNull(products, "products must not be null");
          Assert.notEmpty(products, "products must not be empty");
  
          this.address = address;
          this.products = products;
      }
  	// 객체가 null 이거나 empty인 경우에는 exception을 발생시켜 흐름을 종료할 수 있습니다.
      @Test(expected = IllegalArgumentException.class)
      public void Account_accountNumber_비어있으면_exception() {
          Account.builder()
            .accountHolder("홍길동")
            .accountNumber("")
            .bankName("신한은행")
            .build();
    }

DTO

피드백

🤔  DTO를 사용하는 이유

1. 첫번째는 Entity의 내부 구현을 캡슐화할 수 있습니다.

   Entity를 통해 데이터를 통신하면, 외부 사용자에게 데이터베이스의 스키마 형태, 데이터베이스의 구조, 서비스 내부 로직을 유출 될 수 있습니다.

   이때 DTO를 사용하여, 변수의 접근자를 private로 설정하고
   public한 getter함수를 만들어 캡슐화 할 수 있습니다.

2. 화면에 필요한 데이터를 선별할 수 있습니다.

   단순히 사용자의 이름만 보여주면 되는 상황에서 요청과 응답으로 Entity를 사용한다면
   필요 이상으로 사용자가 가지고 있는 다른 속성들까지 항상 데이터 전송에 참여하게 됩니다.

   하지만 특정 API에 필요한 데이터를 포함한 DTO를 별도로 만들면,
   화면에서 요구하는 필요한 데이터들만 선별하여 요청과 응답을 할 수 있는 장점이 있습니다.

3. 순환참조 문제를 예방할 수 있습니다.

   양방향 참조된 Entity를 Controller에서 response로 return하게 되면,
   Entity가 참조하고 있는 객체는 지연 로딩 되고,
   로딩된 객체는 또 다시 본인이 참조하고 있는 객체를 호출하는 순환 참조의 문제를 낳습니다.
   따라서 이를 방지하기 위해 return으로 DTO를 두는 것이 더 안전합니다.

4. Validation 코드와 모델링 코드를 분리할 수 있습니다.

   Entity 클래스는 DB의 테이블과 매칭되는 필드가 속성으로 선언되어 있고,
   복잡한 비즈니스 로직이 작성되어 있기 때문에
   속성에는 @column과 같은 모델링을 위한 코드가 추가됩니다.

   여기서 만약, @NotNull과 같은 요청에 대한 값의 validation 코드가 들어간다면
   Entity 클래스는 더 복잡해지고 가독성이 저하됩니다.

   각각의 요청에 필요한 validation을 DTO에서 정의한다면,
   Entity 클래스를 좀 더 모델링과 비즈니스 로직에만 집중되도록 만들 수 있습니다.

🤔  Serialize, Deserialize, ObjectMapper가 무엇인가요?

Serialize는 자바 시스템 내부에서 사용되는 객체 또는 데이터를
외부 자바 시스템에서도 사용할 수 있도록 byte형태로 데이터를 변환하는 기술을 말합니다.

Deserialize는 바이트로 변환된 데이터를 다시 객체로 변환하는 기술을 말합니다.

ObjectMapper는 JSON 컨텐츠를 Java 객체로 Deserialize를 하거나,
Java 객체를 JSON으로 Serialize할 때, 사용하는 Jackson 라이브러리 클래스 입니다.

🤔  Serialize/Deserialize를 하는 이유는 무엇인가요?

대부분 OS의 프로세스 구현은 서로 다른 가상메모리 주소공간을 갖기 때문에
Object 타입의 참조값(주소값) 데이터 인스턴스를 전달할 수 없습니다.
전달해도 서로 다른 메모리 공간에서는 전달된 참조값이 무의미합니다.

때문에 서로 다른 메모리 공간 사이의 데이터 전달을 위해서는 메모리 공간의 주소값이 아닌 Byte 형태로 직렬화된 객체 데이터를 전달하면,
사용하는 쪽에서 역직렬화하여 사용할 수 있게 됩니다.

🤔  DTO로 넘긴 데이터가 어떻게 JSON 형식으로 변환되고, JSON 데이터가 어떻게 객체에 매핑되나요?
그 과정에서 어떤 라이브러리가 관여하나요?

Jackson 라이브러리 중  ObjectMapper가 관여합니다.

• 컨트롤러의 리턴 방식이 @RequestBody 형식이라면,

  Spring은 MessageConverter API 를 통해, 컨트롤러가 리턴하는 객체를 가로챌 수 있습니다.

• Jackson은 JSON데이터를 출력하기 위한 MappingJacksonHttpMessageConverter를 제공합니다.

• 만약 스프링 MessageConverter를 위의 MappingJacksonHttpMessageConverter으로 등록한다면,
  컨트롤러가 리턴하는 객체를 Jackson의 ObjectMapper API로 JSON 객체를 만들고 난 후, 출력하여 JSON 데이터를 완성합니다.

🤔  Serialize가 사용되는 상황은 언제인가요?

1. Servlet Session에서 사용됩니다.

   Servlet 기반의 WAS들은 대부분 세션의 Java 직렬화를 지원합니다.

   파일로 저장, 세션 클러스터링, DB를 저장하는 옵션 등을 선택하면 세션 자체가 직렬화되어 저장 및 전달됩니다.

2. Cache

   캐시할 부분을 직렬화된 데이터를 저장해서 사용합니다.

   자바 직렬화를 이용해서만 캐시를 저장하지 않지만 가장 간편하기 때문에 많이 사용됩니다.

🤔  Serialize/Deserialize를 할 때, 주의할 사항이 있을까요?

1. 외부(DB, 캐시 서버, NoSQL 서버 등)에 장기간 저장될 정보는 Java 직렬화 사용을 지양해야합니다.

   클래스 변경을 예측할 수 없어 생각지도 못한 예외사항들이 발생할 가능성이 높기 때문입니다.

2. 프레임워크 또는 라이브러리에서 제공하는 클래스와 같은 개발자가 직접 컨트롤할 수 없는 클래스는
   직렬화 사용을 지양해야합니다.

3. 역직렬화에 실패하는 상황에 대한 예외처리 필수적으로 해야 합니다.

4. 자주 변경되는 비즈니스적인 데이터를 자바 직렬화 사용하지 않는 것이 좋습니다.

5. 직렬화된 데이터를 메모리 서버에 저장하는 환경에서는 트래픽에 따라
   네트워크 비용과 캐시 서버 비용이 급증할 수 있으므로, JSON 포맷으로의 변경을 고려해야 합니다.

   직렬화된 데이터는 직렬화 타입 정보등의 클래스 메타정보를 포함하기 때문에
   JSON 포맷에 비해 약 2~10배 더 사이즈가 크기 때문입니다.

🤔  Serialize/Deserialize를 할 때, 여러 라이브러리 중 ObjectMapper를 사용한 이유는 무엇인가요?

ObjectMapper는 Java Object를 JSON으로 간편하게 바꿀 수 있는 라이브러리 입니다.

서버의 예외 처리의 메세지를 프론트 단에 제공해주고 싶어 해당 라이브러리를 사용했습니다.

ResponseDTO에 예외처리 메세지와, HTTP StatusCode를 담았고,

이를 Json으로 바꿔주어 클라이언트에게 응답으로 보내주었습니다.

[Integerous]

와 정말 제대로 공부하고 계신게 느껴집니다!
이 느낌을 면접관도 답변으로 느낄 수 있으면 4팀분들은 무조건 합격하실거에요!

새로 답변하신 것 하나하나 다 읽어봤구요,
대부분 제가 정답으로 생각한 답변 내용들, 혹은 그보다 더 자세하게 답변을 새롭게 작성하셔서,
저도 오랜만에 면접 준비 공부를 한 기분이네요ㅎㅎ

1. 객체 지향 원칙을 잘 지키기 위해 IoC가 필요합니다. 객체를 관리하는 프레임워크와 개발자가 개발해야 하는 필수 비즈니스 로직을 분리하여 결합도는 낮추고 응집도를 높여줄 수 있기 때문입니다.
   • 객체지향원칙을 지키기 위해서 IoC가 필요하다는 답변은 공격당할 여지가 많습니다. 뒷 문장을 답변하시는 것을 추천드립니다. 객체지향원칙이 무조건 옳다고 생각하지 않는 시니어 개발자분들도 많으셔서 객체지향만능주의 느낌의 답변은 위험합니다-!
2. (튜터님께 질문) - 직접 생성하지 않는다면 무엇이 그 역할을 수행하나요?
   • 새로운 답변에 정리하신대로 Spring IoC 컨테이너가 Controller 객체를 메모리에 생성합니다-! 이 질문은 제가 신입 개발자로 취업할 때 어떤 회사에서 들었던 질문인데요, Dispatcher Servlet의 역할을 블로그에 흔하게 나오는 도식으로만 익히고 실제 동작은 모르는 경우에 Dispatcher Servlet이 Controller를 생성한다고 착각하는 경우가 있어서 나오는 질문인 것 같아요.

혹시 이 팀에 경력 개발자분이 계신건가요?ㄷㄷ
새로 정리한 답변들 중에 몇몇은, 이미 실무를 해본 분이 작성한 것 같은 수준의 내용들이네요..! 👍 👍

이미 좋은 회사에 합격한 분들도 계실 것 같은 느낌이지만..ㅎㅎ
이 정도로 준비하셨으면 취업하고 싶은 회사들 목록화 해두시고, 우선순위 정하셔서 우선순위 낮은 회사들부터 지원하시고 면접 보시는 것을 추천드립니다! 준비만 계속하는 것보다, 우선순위 낮은 회사들에서 면접 여러 번 보면서 준비하시는게 훨씬 효율적이에요ㅎ

취업에 관해 궁금하신 점 언제든 질문주세요! 화이팅입니다 :)