소소한 지식 저장소

1. @Configuration과 싱글톤의 의문점AppConfig 코드를 보면 memberRepository()가 여러 번 호출되는 구조로 인해 싱글톤이 깨질 것처럼 보임[코드] 의문이 발생하는 AppConfig@Configurationpublic class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberRepository()); // memberRepository() 호출 } @Bean public OrderService orderService() { return new OrderServiceImpl(memberRepository(),..

1. 웹 애플리케이션과 싱글톤배경: 스프링은 본래 기업용 온라인 서비스 기술을 지원하기 위해 탄생했으며, 대부분의 스프링 앱은 웹 앱입니다.특징: 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 합니다.문제점: 우리가 만들었던 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성합니다.고객 트래픽이 초당 100이면, 초당 100개의 객체가 생성되고 소멸됩니다. → 메모리 낭비가 심함.해결방안: 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하는 싱글톤 패턴을 사용합니다.[테스트 코드] 스프링 없는 순수한 DI 컨테이너package com.example.spring_study.singleton;import com.example.spring_study.AppConfig;impor..

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. Before: 다형성만 사용 (OCP, DIP 위반)인터페이스를 썼지만, 서비스 내부에서 직접 구현체를 선택하고 있는 상태입니다.package com.example.spring_study.spring_study.member;public class MemberSeviceImpl implements MemberSevice{ private final MemberRepository memberRepository = new MemoryMemberRepository(); @Override public void join(Member member) { memberRepository.save(member); } @Override public Member findMembe..

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

1. AOP가 필요한 상황 (Before AOP)기존의 MemberService는 아래와 같이 핵심 로직보다 시간 측정 로직이 더 비대해진 상태였습니다.// MemberService의 기존 모습 (핵심 로직과 공통 로직의 혼재)public Long join(Member member) { long start = System.currentTimeMillis(); // 공통 관심 사항 try { validateDuplicateMember(member); // 핵심 관심 사항 memberRepository.save(member); // 핵심 관심 사항 return member.getId(); } finally { long fi..