백엔드 개발자, 나단

스프링 프레임워크는 대부분의 빈을 싱글톤으로 관리합니다. 이번 편에서는 왜 싱글톤을 사용하는지, 직접 구현한 싱글톤 패턴과의 차이점은 무엇인지, 그리고 싱글톤 설계 시 주의할 점은 무엇인지에 대해 하나하나 짚어보겠습니다. 1. 웹 애플리케이션과 객체 생성의 문제 웹 애플리케이션에서는 수많은 사용자가 동시에 요청을 보냅니다. 예를 들어 A, B, C 사용자가 동시에 요청을 보내면 객체가 3개 생성되는 상황이 발생합니다. 이런 구조는 성능과 메모리 측면에서 매우 비효율적입니다. 객체를 매번 생성하는 것은 메모리 낭비와 GC 오버헤드로 이어지며, 결국 서버의 응답 속도까지 느려집니다.2. 해결책: 싱글톤 패턴객체를 매번 생성하지 않고 하나의 인스턴스를 공유하면 어떨까요? 이를 해결하는 방식이 바로 싱글톤 패턴..

이전 포스팅에서는 할인 정책을 교체하기 어려운 구조로 인해 OCP와 DIP를 위반하게 되는 문제를 살펴봤다.이번에는 그 문제를 해결하기 위해 등장한 AppConfig라는 설정 클래스를 중심으로 관심사의 분리와 의존 관계 주입 구조를 적용해보자.객체 생성을 외부로 분리하자서비스 클래스는 자신의 역할(로직 구현)에만 집중하고,필요한 객체의 생성과 연결은 AppConfig가 담당하도록 한다.public class AppConfig { public MemberService memberService() { return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService() { ..

이번 편에서는 이전에 만들었던 회원/주문 예제에 객체 지향 원칙을 적용하면서 구조적으로 어떤 문제가 있었는지를 확인해본다.특히 DIP(의존 역전 원칙) 과 OCP(개방-폐쇄 원칙)을 위반한 부분을 짚고, 이후 개선 방향까지 함께 살펴본다.할인 정책 교체 시 발생하는 문제기존 구조에서는 할인 정책을 다음과 같이 고정해서 사용하고 있었다.private final DiscountPolicy discountPolicy = new FixDiscountPolicy();이 경우 새로운 할인 정책(RateDiscountPolicy)으로 교체하려면 코드를 직접 수정해야 한다.private final DiscountPolicy discountPolicy = new RateDiscountPolicy();이는 OCP 위반이다..

스프링의 핵심 개념을 체득하기 위해 순수 자바 기반의 예제를 만들어보며 객체 지향 설계 원칙이 실제 개발에서 어떤 의미를 가지는지 확인해보는 시간이다.이번 포스팅에서는 회원 가입과 조회 기능을 중심으로 도메인 설계 → 구현 → 테스트까지 하나하나 살펴본다. 회원 도메인 요구사항 정리회원은 가입할 수 있어야 하고, 가입한 회원을 조회할 수 있어야 한다.회원은 일반과 VIP 두 가지 등급이 있다.회원 정보는 자체 DB나 외부 시스템과 연동하여 저장할 수 있다. (아직 미확정)저장소 구현이 미정인 상태이므로 개발 초기에는 메모리 기반 저장소를 사용한다.이후 구현체만 바꿔 끼우는 구조로 설계하면 된다. 역할과 구현 분리 전략요구사항 중에서 회원 저장 방식과 할인 정책은 변경 가능성이 크다.그래서 다음의 객체 지..

1. 스프링 프레임워크란?스프링은 자바 플랫폼을 위한 경량 애플리케이션 프레임워크입니다. 복잡했던 과거의 엔터프라이즈 개발을 단순하게, 효율적으로 만들어 주는 핵심 철학을 바탕으로 만들어졌습니다.핵심 철학은 바로 “POJO 기반 개발” 과 “의존성 주입(DI)”, “관점 지향 프로그래밍(AOP)”입니다.2. 스프링의 핵심 구성 요소스프링 컨테이너: 객체를 생성하고 관리하는 중심 역할 (IoC Container)DI (Dependency Injection): 객체 간의 의존 관계를 외부에서 주입AOP (Aspect Oriented Programming): 공통 기능(로깅, 트랜잭션 등)을 핵심 로직과 분리트랜잭션 처리: 선언적 방식으로 쉽게 트랜잭션을 제어스프링 MVC: 웹 애플리케이션의 요청 흐름을 처리..

1. 자바 진영의 과거: EJB의 등장과 한계과거 자바 진영에서는 엔터프라이즈 애플리케이션 개발 시 EJB (Enterprise JavaBeans) 가 표준처럼 사용되었습니다. 하지만 이 기술은 너무 복잡했습니다.비즈니스 로직을 작성하려면 EJB 인터페이스, 홈 인터페이스, 실제 구현 클래스를 각각 만들어야 했고배포 시에도 ejb-jar.xml 등의 복잡한 설정 파일이 필요했으며개발 속도는 느리고 테스트도 어려웠습니다.즉, 개발자 입장에서 생산성과 유지보수성이 모두 떨어지는 구조였던 셈입니다.2. 경량 컨테이너와 POJO 기반 개발의 등장이러한 문제에 대한 반발로 등장한 개념이 경량 컨테이너와 POJO (Plain Old Java Object) 기반 개발입니다.특별한 규약 없이, 단순한 자바 객체로 로직..