[2025 1학기 스프링부트 스터디] 여민호 #5주차

<전강의>

appconfig를 통해 의존 관계 중복으로 인한 DIP위반을 해결했다.

서로 하는 역할을 달리하는 코드 및 도메인을 통해 서로가 하는 일끼리의 충돌을 막았다.

 

즉)

1.객체를 생성하고 연결하는 역할

2.구체 클래스를 실행하는 역할

을 명확하게 분리!!!

---

#섹션4-5 ~ 4-9

할인 정책 적용

-> Appconfig를 통해 

return new FixDiscountPolicy   //정액 할인

return new RateDiscountPolicy //정률 할인

 

!!장점!!

다른 코드를 만지지 않고 Appconfig를 통해 바꾸는게 가능하다

이전!! 오더 서비스 인플에 들어있는 코드(클라이언트 코드)들을 변경해야했음

 

[좋은 객체 지향 설계의 5가지 원칙 적용]

위에서는 3가지 원칙이 적용됨

1. SRP 단일 책임 원칙 

"한클래스는 하나의 책임만 가져야한다."

---> 관심사 분리

 

2. DIP 의존관계 역전 원칙

"프로그래머는 추상황에 의존해야지,구체와에 의존하면 안된다"

새로운 할인 정책의 개발이 다른 클라이언트 코드를 변경하게 만듦

--->App config 가 새로운 할인 정책의 객체 인스턴스를 클라이어트 코드 대신 생성해 의존관계를 추가적으로 주입함

 

3. OCP

"소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야한다"

FixDiscountPolicy --->  RateDiscountPolicy

 

**IoC**

=제어의 역전 

간단한 설명

기존 프로그램 #1 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성,연결,실행함 #2 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다

제어의 역전 #1 AppConfig와 같은 도메인이 설계 된 후 구현 객체는 자신의 로직만 실행함 #2 프로그램에 대한 제어 흐름은 구현 객체가 아닌 AppConfig와 같은 도메인이 제어한다

 

위 설명과 같이 프로그램의 제어흐름을 직접 제어하는것이 아닌 외부에서 관리하는 것이 IoC이다.

 

**DI**

=의존 관계 주입

일단 ) 정적인 클래스와 (실행되는) 동적인 클래스가 분리되어야한다

 

프로그래머가 직접 코드 작성이 아닌 , 스프링 컨테이너를 통해 대신 작성해주는 방식

EX)

@ExtendWith(MockitoExtension.class) #
class UserServiceTest {

    @Mock #구현 객체
    private UserRepository userRepository;

    @InjectMocks #의존관계 주입
    private UserService userService;

    @Test  #테스트 코드 필수
    void testGetUser() {
        when(userRepository.findById(1L)).thenReturn(Optional.of(new User()));
        User user = userService.getUserById(1L);
        assertNotNull(user);
    }
}

 

**컨테이너** 

AppConfig 와 같이 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 컨테이너라고 한다

 

---

스프링으로 전환하기!!!

1."스프링 컨테이너"

기존에는 개발자가 AppConfig를 사용해 직접 객체를 생성하지만, 스프링 컨테이너는 다름

@Bean

이라 불린 메서드를 모두 호출해서 반환되 객체가 스프링 컨테이너이다.

 

즉) 기존에는 개발자가 코드를 모두 제작하고 만들었지만 

스프링을 사용하면 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아 사용하도록 변경되었다