소소한 지식 저장소

1. BeanFactory스프링 컨테이너의 최상위 인터페이스주요 역할: 스프링 빈을 관리하고 조회하는 기본 기능을 담당핵심 메서드: getBean()을 제공특징: 지금까지 사용했던 빈 조회와 관리의 대부분은 사실 BeanFactory가 제공하는 기능.2. ApplicationContextBeanFactory의 기능을 모두 상속받아 제공하는 인터페이스핵심 기능: 빈 관리 및 검색 기능에 더해, 실제 애플리케이션 개발에 필요한 여러 부가기능을 제공ApplicationContext는 BeanFactory + 부가 기능ApplicationContext가 제공하는 부가기능메시지소스를 활용한 국제화 기능:접속 지역에 따라 한국어, 영어 등 언어를 구분하여 출력예를 들어, 한국어 들어오면 한국어로, 영어권에서 들어오..

1. 스프링 빈 조회 - 기본스프링 컨테이너에서 빈을 찾는 가장 기본적인 방법조회 방법ac.getBean(빈이름, 타입)ac.getBean(타입)특이 사항구체 타입 조회: 인터페이스가 아닌 구현체 타입(예: MemberServiceImpl)으로도 조회가 가능하지만, 변경 시 유연성이 떨어짐.예외 발생: 조회 대상 스프링 빈이 없으면 NoSuchBeanDefinitionException이 발생. (assertThrows로 검증)package com.example.spring_study.spring_study.beanfind;import com.example.spring_study.spring_study.AppConfig;import com.example.spring_study.spring_study.mem..

1. 스프링 컨테이너 생성// Spring Container 생성ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);ApplicationContext를 스프링 컨테이너라고 하며, 이는 인터페이스임.AnnotationConfigApplicationContext는 이 인터페이스의 구현체 중 하나로, 자바 설정 클래스(AppConfig.class)를 기반으로 컨테이너를 생성합니다.즉, 선언할 때, public class AnnotationConfigApplicationContext implements ApplicationContext 임컨테이너가 생성될 때 내부에는 비어있는 스프링 빈 저장소..

스프링 전환의 핵심 로직 요약1. 설정 정보의 변화 (AppConfig)기존: 단순한 자바 클래스. 개발자가 직접 메서드를 호출해 객체를 생성함.스프링: @Configuration이 붙어 스프링의 **'설정 지도'**가 됨. 메서드 위의 @Bean은 "이 객체를 관리해줘!"라는 등록 마크임.2. 관리 주체의 변화 (IoC 컨테이너 등장)ApplicationContext: 우리가 만든 AppConfig를 읽어서 객체들을 담아두는 **'거대한 창고'**입니다.스프링 빈(Bean): 창고에 보관된 객체들입니다. 기본적으로 메서드 이름(예: memberService)이 이름표가 됩니다.package com.example.spring_study.spring_study;import com.example.spring..

1. 결정적인 차이: 제어의 흐름 (Inversion of Control)라이브러리: '나'가 주체가 됩니다. 내가 필요할 때 라이브러리를 직접 호출해서 사용합니다. (내가 도구를 골라 쓰는 것) - 제어의 흐름을 개발자가 가짐프레임워크: '프레임워크'가 주체가 됩니다. 프레임워크가 정해준 규칙대로 코드를 작성하면, 프레임워크가 내 코드를 대신 실행 (틀 안에 내가 들어가는 것) - 제어의 흐름을 프레임워크가 가짐비유로 이해하기라이브러리는 '연장'. 내가 집을 짓다가 망치가 필요하면 망치를 꺼내 쓰고, 드릴이 필요하면 드릴을 꺼내 씁니다. 언제 어떤 도구를 쓸지는 전적으로 내가 결정합니다.프레임워크는 '모델하우스'. 이미 거실, 안방, 주방의 위치(틀)가 정해져 있습니다. 나는 그 안에서 벽지의 색깔을 ..

1. SRP: 단일 책임 원칙 (Single Responsibility Principle)핵심: 한 클래스는 하나의 책임만 가져야 한다.판단 기준: 가장 중요한 기준은 변경이다. 변경이 발생했을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.예시: UI 변경, 객체의 생성과 사용을 분리하는 것 등.2. OCP: 개방-폐쇄 원칙 (Open/Closed Principle)핵심: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀(변경하지 않아도 된다) 있어야 한다.방법: 다형성을 활용하여 인터페이스를 구현한 새로운 클래스를 만들어 기능을 확장한다.문제점: MemberService가 구현 클래스를 직접 선택하는 경우(예: new MemoryMemberRepository()), 구현 객체 변경 시 ..