@Configuration과 @Bean을 이용해도 되지만 점점 많아지게되면 힘들고 파일 하나에 엄청난 @Bean이 생겨날 수 있다.
이걸 깔끔하게 만드는 법이 컴포넌트 스캔이다. 컴포넌트 스캔은 @Component가 붙은 정보를 Bean으로 등록하게 된다.
컴포넌트 스캔
@Configuration
@ComponentScan(
excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class))
public class AutoAppConfig {
}
컴포넌트
@Component
public class MemoryMemberRepository implements MemberRepository {}
이렇게 되면 @Component가 붙은 MemoryMemberRepository를 Bean으로 등록할 수 있다.
📝@Bean vs @Component
@Bean은 이제 더이상 쓸모 없는 행동일까? 어떤 상황에 @Bean을 쓰고 어떤 상황에 @Component를 쓰는지 알아보자
Bean 등록 방식 (@Bean, @Component)
// 이전 방식 사용
@Configuration
public class AppConfig {
@Bean
public MyService myService() {
return new MyService(); // MyService를 빈으로 등록
}
@Bean
public MyComponent myComponent() {
// MyComponent가 MyService를 필요로 한다고 명시적으로 주입
return new MyComponent(myService());
}
}
//이후 방식 사용
@Component
public class MyService {
// 빈으로 등록될 클래스
}
@Component
public class MyComponent {
private final MyService myService;
// @Autowired를 통해 Spring이 자동으로 MyService 빈을 주입함
@Autowired
public MyComponent(MyService myService) {
this.myService = myService;
}
}
비교하기 위해 동일한 빈 등록하는 방식을 Bean과 Component로 보여줬다.
@Bean
@Configuration이 필요하다
메소드 단위에 붙이게 된다. 해당 메소드는 클래스를 반환해야한다 (Component에서 해당 클래스가 @Component가 된다)
의존관계 주입을 직접 Inject을 하기 때문에 Autowired를 통해 Injection할 필요가 없다
MyComponent에 myService()를 매개변수로 직접 넣어주고 있다.
@Component
클래스 단위에 붙이게 된다. 해당 클래스는 빈으로 등록되게 된다.
의존관계 주입시 @Autowired를 사용한다
일반적으로 @Component를 많이 사용한다. @Bean 방식하고 비교하면 코드수도 확연히 줄어들게 된다. 하지만 @Bean도 필요할 때가 있다.
@Configuration
public class DataSourceConfig {
@Bean
public DataSource dataSource() {
HikariDataSource dataSource = new HikariDataSource(); // 외부 라이브러리 클래스 인스턴스 생성
dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
dataSource.setUsername("username");
dataSource.setPassword("password");
return dataSource;
}
}
HikariDataSource의 경우 외부 라이브러리이기 때문에 내가 직접 @Component를 붙일 수가 없다. 스프링에서 관리가 필요한데 이럴 경우 위 코드와 같이 직접 HikariDataSource의 객체를 만들고 return시킨 이후에 해당 것을 빈객체로 등록하게 되면 된다. 이럴 경우 HikariDataSource를 new해서 사용하면 안 되고 내가 Bean으로 등록한 DataSourceConfig의 dataSource()를 사용해야한다.
스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다 그래서 초당 100의 요청이 오면 100개의 객체가 생성되고 소멸되어 메모리 낭비가 심해진다. 해결방안으로는 딱 1개만 생성되고 공유하도록 설계하면 된다.
📝싱글톤 패턴
1개만 생성되고 그것을 공유하도록 하는 패턴이다. 즉, 클래스의 인스턴스가 딱 1개만 생성되는 걸 보장해준다. 그래서 2개 이상 생성이 안 된다. 주의점으로 private으로 만들어서 임의로 new 키워드로 만들 수 없게 해야한다.
싱글톤 패턴 적용
public class SingletonService {
//1. static 영역에 객체를 딱 1개만 생성해둔다.
private static final SingletonService instance = new SingletonService();
//2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
public static SingletonService getInstance() {
return instance;
}
//3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
private SingletonService() {
}
public void logic() {
System.out.println("싱글톤 객체 로직 호출");
}
}
테스트 코드
@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
public void singletonServiceTest() {
//private으로 생성자를 막아두었다. 컴파일 오류가 발생한다.
// new SingletonService();
//1. 조회: 호출할 때 마다 같은 객체를 반환
SingletonService singletonService1 = SingletonService.getInstance();
//2. 조회: 호출할 때 마다 같은 객체를 반환
SingletonService singletonService2 = SingletonService.getInstance();
//참조값이 같은 것을 확인
System.out.println("singletonService1 = " + singletonService1);
System.out.println("singletonService2 = " + singletonService2);
// singletonService1 == singletonService2
assertThat(singletonService1).isSameAs(singletonService2);
singletonService1.logic();
}
하지만 이상적이지만은 않다. 싱글톤 패턴을 사용할 때 문제점이 있는데 아래와 같다.
싱글톤 패턴 문제점
싱글톤 패턴은 구현 코드 자체가 많이들어간다.
클라이언트가 구체 클래스를 의존해 DIP를 위반한다.
구체 클래스 의존으로 인해 OCP 위반 가능성이 높다.
테스트가 어렵다.
내부 속성 변경이나 초기화가 어렵다.
내부 속성 변경하게끔하면 공유해서 쓰기 때문에 여러곳에서 쓰일 경우 각종 문제들이 터질 가능성이 매우 높다. 즉, 무상태로 설계해야한다.
private 생성으로 자식 클래스 만들기가 어렵다.
위와 같은 이유로 유연성이 떨어져 안티패턴으로 불린다.
📝싱글톤 컨테이너
우리가 직접 싱글톤을 구현해서 사용할 때는 이러한 문제점들이 있다. 그러면 스프링의 경우는 어떨까? 스프링은 싱글톤의 문제점들을 다 해결하면서 싱글톤의 장점만 취한다.
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
// memberRepository 호출
return new MemberServiceImpl(memberRepository());
}
@Bean
public OrderService orderService() {
// memberRepository 호출
return new OrderServiceImpl(
memberRepository(),
discountPolicy());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
}
memberService빈을 만드는 코드를 보면 memberRepository()를 호출한다
orderService빈을 만드는 코드를 보면 memberRepository()를 호출한다
결과적으로 2개의 MemoryMemberRepository가 생성되면서 싱글톤이 깨진 것처럼 보인다. 이러한 스프링 컨테이너의 문제점을 어떻게 해결할까?
기본적으로 특정 Reader가 존재해 Bean 설정 정보를 읽고 메타 정보를 만들어 사용하게 된다. BeanDefinition에는 Bean의 메타정보들이 들어있다. 직접 Reader와 Definition을 Bean의 작성방식을 내 임의대로 커스텀해서 만들 수도 있지만 거의 사용되진 않는다.
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
}
@Configuration
해당 설정을 Spring Container로 사용하겠다는 의미이다.
@Bean
Spring Container에 등록하겠다는 의미로 해당 정보를 다른 곳에서 꺼내서 쓸 수 있게 도와준다. 기본적으로 메서드의 명을 스프링 빈의 이름으로 사용한다. (물론 변경 가능)
주의점으로 Bean이름이 겹치면 안 된다. (유일해야 함)
public class MemberApp {
public static void main(String[] args) {
/** AppConfig설정이 들어간 Spring Container를 사용하겠다 **/
ApplicationContext applicationContext = new
AnnotationConfigApplicationContext(AppConfig.class);
/** Spring Container에 등록된 Bean에서 MemberService를 가져오겠다. **/
MemberService memberService =
applicationContext.getBean("memberService", MemberService.class);
/** 회원가입 **/
Member member = new Member(1L, "memberA", Grade.VIP);
memberService.join(member);
/** 회원찾기 **/
Member findMember = memberService.findMember(1L);
System.out.println("new member = " + member.getName());
System.out.println("find Member = " + findMember.getName());
}
}
📝Spring Bean 조회해보기
부모타입으로 조회하면 자식 타입도 함께 조회한다. 그래서 Object 타입으로 조회하면 모든 스프링 빈을 조회하게 된다.
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository = new
MemoryMemberRepository();
public void join(Member member) {
memberRepository.save(member);
}
public Member findMember(Long memberId) {
return memberRepository.findById(memberId);
}
}
MemberService
public interface MemberService {
void join(Member member);
Member findMember(Long memberId);
}
위 코드는 회원가입하고 회원을 찾는 로직들이 들어간 코드들이다. MemberServiceImple에서 new MemoryMemberRepository()를 통해 Repository를 어떤 걸 쓸지 직접 정해주고 있어서 OCP/DIP를 위반하고 있다.
📝스프링의 핵심 기능 사용하기 후
AppConfig
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(new MemoryMemberRepository());
}
}
MembmerServiceImpl
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
public MemberServiceImpl(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
public void join(Member member) {
memberRepository.save(member);
}
public Member findMember(Long memberId) {
return memberRepository.findById(memberId);
}
}
MembmerService
public interface MemberService {
void join(Member member);
Member findMember(Long memberId);
}
AppConfig에서 New해서 관리하기 때문에 더이상 MemberServiceImpl에서 MemberRepository를 New로 넣을 필요 없고 코드 수정도 필요가없다. 이렇게 함으로 OCP/DIP를 MemberServiceImpl은 지킬 수 있고 그 책임을 AppConfig에서 하게 된다.
📝IoC / DI 컨테이너
프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 한다. 위에 코드로 이야기하자면 AppConfig에서 모두 관리하기 때문에 이걸IoC 컨테이너 또는 DI(의존 주입) 컨테이너라고 한다.
위 예시로 설명하면 MemberService에 대한 Repository 제어를 MemberService에서 하는 게 아니라 AppConfig에서 하기 때문에 제어가 역전되었다라고 이야기하고 DI 즉, 의존을 주입하는 역할을 해서 DI 컨테이너라고 불리는 것이다.
Junit은 Java에서 가장 많이 사용되는 테스트 프레임워크로 단위 테스트를 작성하고 실행하는데 사용됩니다.
📝테스트 코드 작성팁
일반적으로 테스트 코드를 작성할 때에는 순수 자바코드로만 실행 가능하게끔 만드는 게 좋다. (스프링에 종속되거나 하지 않게끔)
given, when, then의 원칙을 지키면서 작성하면 좋다.
테스트가 실패하는 경우도 테스트를 만들어야한다.
📝Junit5 예제 코드
package com.spring.core.member;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
public class MemberServiceTest {
MemberService memberService = new MemberServiceImpl();
@Test
void join() {
// given
Member member = new Member (1L, "memberA", Grade.VIP);
// when
memberService.join(member);
Member findMemmber = memberService.findMember(1L);
// then
Assertions.assertThat(member).isEqualTo(findMemmber);
}
}
@Test로 단위테스트 실행 단위를 설정한다.
package com.spring.core.discount;
import static org.assertj.core.api.Assertions.assertThat;
import com.spring.core.member.Grade;
import com.spring.core.member.Member;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
class RateDiscountPolicyTest {
RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
@Test
@DisplayName("VIP는 10% 할인이 적용되어야 한다.")
void vip_o() {
//given
Member member = new Member(1L, "memberVIP", Grade.VIP);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(1000);
}
@Test
@DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
void vip_x() {
//given
Member member = new Member(2L, "memberBASIC", Grade.BASIC);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(0);
}
}
@DisplayName으로 Test 명명이 가능하다. (실패케이스와 성공케이스 두개 다 설정)
class MemberServiceTest {
MemberService memberService;
@BeforeEach
public void beforeEach() {
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
}
@AfterEach
void afterEach() {
memberRepository.clearStore();
}
}
옛날에는 EJB라는 프레임워크가 있었지만 너무 사용하기 어렵고 비용도 많이 들고 느리기 때문에 POJO(Plain한 상태)로 생각하자 해서 나온 게 Spring의 근간이 되는 부분이다. 그리고 EJB에서 사용했던 Entity Bean의 경우는 Hibernate가 대체하게 되었고 표준안이 된 게 JPA이다.
스프링 변경 순서
EJB Entity Bean → Hibernate → JPA
EJB → Spring
📝Spring Framework
Spring Framework는 스프링에 들어가는 핵심기술이 다 들어간 프레임워크이다.
📝Spring Boot
Spring Boot는 Spring Framework를 쉽게 사용할 수 있게 도와준다.
스프링 설정이 편해졌다.
내장 서버를 지원해 따로 서버를 깔 필요가 없다. (예를 들면 톰캣)
외부라이브러리 버전 호환성을 알아서 잘 처리해준다.
모니터링도 지원한다.
📝 좋은 객체지향이란?
다형성
"다양한 형태를 가질 수 있다" 라는 의미로 예를 들면 마우스가 고장나면 다른 마우스를 꽂아도 똑같이 동작하는 것처럼 USB포트의 설계만 동일하면 변경에 유연하고 용이하다.
객체 설계시에는 역할과 구현을 명확히 분리해야한다. 자바로 따지면 역할은 인터페이스이고 구현은 인터페이스를 이용한 클래스를 의미한다. 즉, 클라이언트는 인터페이스만 알면 된다. (엑셀을 밟으면 움직인다 / 브레이크를 밟으면 멈춘다)
인터페이스를 잘 설계했으면 클라이언트에서 따로 변경하지 않더라도 인터페이스를 이용한 클래스만 바꾸면 된다. 그래서 인터페이스 변화가 없게 설계하는게 정말 중요하다
📝 SOLID원칙
클린코드로 유명한 로버트 마틴이라는 사람이 좋은 객체 지향 설계를 위해 5가지 원칙을 정리한 것이다.
SRP (단일 책임 원칙)
하나의 클래스는 하나의 책임만 가져야한다. 즉, 변경이 있을 때 파급 효과가 적으면 해당 원칙을 잘 따른 것이다. 예를 들면 UI 변경시 모든 코드를 다 바꿔야하면 해당 원칙을 잘못 활용한 것이다.
OCP (개방 폐쇄 원칙)
확장에는 열려있지만 변경에는 닫혀있어야한다.
// 기존 코드
public class MemberService {
private MemberRepository memberRepository = new MemoryMemberRepository();
}
// 변경 코드
public class MemberService {
// private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JdbcMemberRepository();
}
위 코드를 보면 직접 코드를 변경해야하는 문제점이 있다. 즉, 다형성을 사용했지만 직접 주입 클래스를 바꿔야하기 때문에 OCP 원칙을 지킬 수 없다. 이럴 경우 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다
LSP (리스코프 치환 원칙)
다형성에서 하위 클래스는 인터페이스 규약을 지켜야한다. 예를 들면 엑셀을 밟으면 앞으로 나가는 게 일반적이지만 뒤로 가게도 만들 수 있는데 뒤로 가게끔 만들면 해당 원칙을 위반한 것이다.
ISP 인터페이스 분리 원칙
범용 인터페이스 하나보단 여러개의 인터페이스가 좋다. 예를 들면 자동차 인터페이스를 운전, 정비 인터페이스를 분리시키면 정비 인터페이스가 바뀌더라도 운전 인터페이스에 영향을 끼치지 않는다.
DIP 의존관계 역전 원칙
프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 즉, 인터페이스에 의존해야지 클래스에 의존하면 안 된다. 예를 들면 로미오라는 배역이라는 역할 자체가 바뀌면 안 되지 로미오를 연기하는 사람은 바뀌어도 괜찮다.
📝 SOLID 문제점
다형성 만으로는 OCP와 DIP 즉, 직접 코드를 프로그래머가 바꿔줘야하는 문제점을 해결할 수 없다. 이걸 해결하기 위해 스프링이 나오게 되었다.
margin-left: auto, margin-right:auto의 경우 부모 크기 - 자식 크기에 뺀 크기를 여백이라고 하는데 여백이 있어야 정렬이 가능합니다. 400px이 부모 크기고 자식 크기가 200px일 때 200px의 여백이 있으니 100px 100px 왼쪽 오른쪽 이렇게 두개로 여백을 가지게 됩니다.
