Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5주차 모의 면접 질문 정리 (Spring 1~8) #22

Open
kyeong-hyeok opened this issue Feb 10, 2024 · 0 comments
Open

5주차 모의 면접 질문 정리 (Spring 1~8) #22

kyeong-hyeok opened this issue Feb 10, 2024 · 0 comments
Assignees
Labels

Comments

@kyeong-hyeok
Copy link
Contributor

kyeong-hyeok commented Feb 10, 2024

POJO란 무엇인가요? Spring Framework에서 POJO는 무엇이 될 수 있을까요?

  • POJO는 프레임워크 인터페이스, 클래스를 구현하거나 확장하지 않은 단순한 클래스로 Java에서 제공하는 API 외에 종속되지 않습니다. 특정 환경에 종속되지 않아 코드가 간결하고 테스트 자동화에 유리합니다.
  • 스프링에서는 도메인 객체와 비즈니스 로직을 수행하는 클래스가 POJO대상이 될 수 있습니다.

Autowired 주입의 3가지 방법에 대해 설명해주세요

  • Field Injection
    • Field Injection 이 편리하고 코드가 간결하다는 장점이 있지만, 외부에서 수정이 불가능하고 테스트 코드 작성 시 객체 수정할 수 없음
  • Setter Injection
    • Setter를 public으로 구현할 경우 관계 주입 받는 객체의 변경 가능성이 열려있음. 변경 가능성을 열어두면 다른 곳에서 임의로 객체 변경 할 수있기에 에러 발생 할 수 있음
  • Constructor Injection (Best!)
    • 생성자 주입의 장점
      • 순환 참조 방지
        • 필드 주입과 수정자 주입은 빈이 생성된 후 참조하기에 애플리케이션이 아무 오류, 경고 없이 구동 → 실제 코드가 호출될 때까지 문제를 알 수 없음
      • 불변성
        • 생성자로 의존성 주입시 final 선언할 수 있고 이를 통해 런타임에서 의존성 주입받은 객체가 변할 일이 없어짐.
        • 변경 가능성 배제, 불변성 보장
      • 테스트에 용이함
        • 독립적 인스턴스가 가능한 POJO를 사용하면 DI 컨테이너 없이도 의존성 주입해 사용 가능
        • 코드의 가독성이 높아지며 유지보수에 용이

AOP란?

  • AOP는 관점 지향 프로그래밍의 약자
  • 기존의 OOP에서 기능별로 클래스를 분리했음에도 불구하고, 공통적으로 반복되는 중복코드가 발생하는데 이를 해결할 수 있도록 실행시 비즈니스 로직의 앞과 뒤에서 원하는 지점에 해당 공통 관심사를 수행할 수 있게 함.

Spring IoC/DI는 어떻게 동작하나요?

  • IoC(제어의 역전)은 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것으로 코드의 최종호출은 개발자가 제어하는 것이 아닌 프레임워크의 내부에서 결정된 대로 이루어집니다.
  • DI(의존관계 주입)은 Spring 프레임워크에서 지원하는 IoC의 형태로, 객체간의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해줍니다.

IoC 컨테이너의 역할은 무엇이 있을까요?

  • 애플리케이션 실행 시점에 빈 객체를 인스턴스화하고 DI 한 후에 최초로 애플리케이션을 기동할 빈 하나를 제공해준다
  • IoC 컨테이너는 객체의 생명 주기를 관리해주므로 개발자는 객체 관리 대신 다른 부분에 더 집중할 수 있음

ApplicationContext 의 역할

  • 스프링 컨테이너
  • BeanFactory 인터페이스의 하위 인터페이스로 부가 기능을 추가한 것

Spring Web MVC의 Dispatcher Servlet 동작원리

  1. 클라이언트의 요청을 Dispatcher Servlet에 전달
  2. 요청한 url에 맞는 controller 검색하여 Handler Mapping에 전달
  3. HandlerMapping에서 해당 controller에 처리 요청
  4. controller에서 처리 결과를 Handler Adapter에서 ModelAndView 객체로 변환하여 Dispatcher Servlet에 전달
  5. Dispatcher Servlet에서 전달받은 ModelAndView 객체를 이용하여 매핑되는 View를 검색
  6. viewResolver에서 처리 결과를 view에 전달
  7. 처리결과가 포함된 view를 Dispatcher Servlet에 전달
  8. Dispatcher Servlet에서 최종 응답 결과를 클라이언트에게 반환

여러 요청이 들어온다고 가정할 때, DispatcherServlet은 한번에 여러 요청을 모두 받을 수 있나요?

  • DispatcherServlet은 요청이 들어올 때마다 서블릿 컨테이너에 의해 새로운 스레드가 생성되어 해당 요청을 처리합니다. 따라서 동시에 여러 요청이 도착할 경우 각 요청은 별도의 스레드에서 처리됩니다.

프론트 컨트롤러 패턴이란 무엇인가요? Front Controller 패턴을 사용하는 장점은 무엇일까요?

  • 클라이언트의 다양한 요청마다 서블릿을 만들어서 사용한다고 하면 개발과 유지보수의 효율이 떨어질 수 밖에 없습니다. 프론트 컨트롤러 패턴을 사용함으로써 각 요청을 적절한 곳으로 위임해줌으로써 개발과 유지보수의 효율성이 증가하고 모든 요청에 대해 보안, 국제화, 라우팅 및 로그와 같은 일반적인 기능을 한 곳에서 캡슐화할 수 있습니다.

Spring 과 Spring Boot의 차이

  • Spring Boot 는 starter 가 대부분의 dependency 버전 호환 관리를 해줌.
  • Spring Boot는 AutoConfiguration이 있음. @SpringBootApplication 덕분에 많은 외부 라이브러리, 내장 톰캣 서버 등이 실행될 수 있음
  • Spring Boot는 내장 tomcat WAS가 있어 jar 파일로 간편하게 배포 가능

Spring Web MVC에서 요청 마다 Thread가 생성되어 Controller를 통해 요청을 수행할텐데, 어떻게 1개의 Controller만 생성될 수 있을까요?

  • @controller 어노테이션을 타고 들어가보면 @component라는 어노테이션이 붙어 있습니다. 따라서 컨트롤러는 IoC컨테이너에 등록되어 Spring bean으로 관리됩니다. Spring의 빈 생성 전략의 기본은 싱글턴입니다. IoC컨테이너에 Controller Bean은 싱글턴 전략에 의해 1개만 존재하고 Application이 Init 되는 시점에 초기화됩니다. 그리고 실제 사용되는 시점에 의존성 주입을 통해서 사용됩니다. 요청시마다 새로 Bean을 생성해서 사용하는 것이 아닌 이미 생성되어있는 Bean을 가져다 쓰게됨으로써 여러개의 Thread에서 Controller를 사용해도 1개의 동일한 컨트롤러인 것입니다. 만약 요청이 올때마다 새로운 컨트롤러가 생기길 바란다면 Bean scope를 Singleton 이 아닌, request 등으로 설정하면 요청이 들어올 때 혹은 지정한 전략마다 새로운 컨트롤러 Bean이 생기도록 할 수 있습니다.

Spring Bean이란 무엇인가요?

  • Spring IoC 컨테이너가 관리하는 자바 객체
  • IoC 컨테이너 안에 들어있는 객체로 필요할 때 IoC 컨테이너에서 가져와서 사용합니다. @bean 을 사용하거나 xml설정을 통해 일반 객체를 Bean으로 등록할 수 있습니다.

스프링 Bean의 생성 과정을 설명해주세요.

  • 객체 생성 → 의존 설정 → 초기화 → 사용 → 소멸 과정의 생명주기를 가지고 있습니다. Bean은 스프링 컨테이너에 의해 생명주기를 관리하며 빈 초기화방법은 @PostConstruct를 빈 소멸에서는 @PreDestroy를 사용합니다.
  • 생성한 스프링 빈을 등록할 때는 ComponentScan을 이용하거나 @configuration@bean 을 사용하여 빈 설정파일에 직접 빈을 등록할 수 있습니다.

특정 기능을 하는 클래스가 딱 한 개하면, 구체 클래스를 그냥 사용해도 되지 않나요? 그럼에도 불구하고 왜 Spring에선 Bean을 사용 할까요?

  • 의존성 주입, 생명 주기 관리, AOP 지원, 편리한 테스트
  • 빈을 통해 객체를 관리하고 관련된 기능들을 제공하여 애플리케이션의 유지보수성, 확장성, 테스트 용이성 등을 향상

@controller vs @RestController

  • @controller: View 반환과 Data 반환에 사용
  • @RestController: 모든 메서드에서는 @ResponseBody 어노테이션이 기본으로 작동, Json 형태로 객체 데이터 반환

@SpringBootApplication 내부 구성

  • @SpringBootConfiguration: @configuration과 동일한 역할을 수행
  • @EnableAutoConfiguration: 빈들을 자동으로 설정해주는 자동 설정 기능을 활성화
  • @componentscan: ****빈을 등록하기 위한 어노테이션(@component)들을 탐색하는 위치를 지정
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants