23.03.02

<오늘의 복습>

 

- spring

 

🟧 객체 지향 원리 적용

---

AppConfig 리팩터링

 

- 문제점과 더 나은 방향으로의 리펙터링

- 현재까지 AppConfig 코드를 보면 중복이 있고, 역할에 따른 구현이 잘 안보임

 

리팩토링

• 구체 클래스를 누르면 x ➡️ '인터페이스'를 선택!

- AppConfig 리팩토링

public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    private MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(), discountPolicy());
    }

    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

 

• MemberService 역할, MemberRepository역할, OrderService역할이 다들어난다
• DiscountPolicy역할 추가!
• 장점 : 각 역할을 알 수 있음(메서드명을 봐도), 변경에 용이
• new MemoryMemberRepository() → 이 부분의 중복이 제거됨
• MemoryMemberRepository → 다른 구현체로 변경할 때 한 부분만 변경하면 됨
• AppConfig를 보면 역할과 구현 클래스가 한눈에 들어옮, 어플리케이션 전체 구성이 어떻게 되어있는지는 빠르게 파악가능

새로운 구조와 할인 정책 적용

 

- 처음으로 돌아가 정액 할인 정책을 정률(%) 할인 정책으로 변경해보기

- FixDiscountPolicy ➡️ RateDiscountPolicy

- AppConfig만 변경하면 된다 : 어플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었음

사용, 구성의 분리

• 할인 정책을 수정하면 AppConfig부분만 고치면 된다
• FixDiscountPolicy → RateDiscountPolicy로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않음

public DiscountPolicy discountPolicy() {
    return new RateDiscountPolicy();
}

• RateDiscountPolicy(); 만 수정!

수정 코드 테스트

• 성공하는 것을 확인

OrderApp

• OrderApp에 main() 테스트 시 값이 잘 나오는 것을 확인할 수 있음

❇️ 이제 할인 정책을 변경해도, 어플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다, 클라이언트 코드인 OrderServiceImpl를 포함해서 사용영역의 어떤 코드도 변경할 필요가 없음

❇️ 구성 영역은 당연히 변경됨 - 구성 역할을 담당하는 AppConfig를 어플리케이션이라는 공연의 기획자로 생각하면된다, 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 함

❇️ DIP, OCP 모두 지켜졌음

💠 전체 흐름 정리

🔹새로운 할인 정책 개발
- 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없다

🔹새로운 할인 정책 적용과 문제점?
- 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야 함
- 주문 서비스 클라이언트가 인터페이스인 DisCountPolicy뿐만 아니라, 구체 클래스인 FixDisCountPolicy도 함께 의존  → DIP 위반 
➡️ 주문 서비스 클라이언트가 너무 많은 일을 하고 있었음 

🔹관심사의 분리
- 기존에는 → 클라이언트가 의존하는 서버 구현체를 직접 생성, 실행함
- 기획자 : AppConfig 등장
- AppConfig 는 어플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현객체를 생성하고 연결하는 책임
- 이제부터 클라이언트 객체는 자신의 역할을 실행하는 것만 집중, 권한이 줄어듬(책임이 명확해짐)

🔹AppConfig 리팩터링
- 구성 정보에서 역할과 구현을 명확하게 분리
- 역할이 잘 드러남
- 중복 제거 

🔹새로운 구조와 할인 정책 적용
- 정액 할인 정책 → 정률(%)할인 정책으로 변견
- AppConfig의 등장으로 어플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리 
- 할인 정책을 변경해도 → AppConfig가 있는 구성영역만 보면된다, 사용 영역은 변경할 필요 x, 물론 클라이언트 코드인 주문 서비스 코드도 변경하지 않음

 

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

 

➡️ 예제에서  SRP, DIP, OCP 적용

 

- SRP 단일 책임 원칙 (한 클래스는 하나의 책임만)

• 클라이언트 객체(ex. OrderService 등)는 직접 구현 객체를 생성, 연결, 실행하는 다양한 책임을 가지고 있음
• SRP 단일 책임 원칙을 따르면서 관심사를 분리함
• 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당
• 클라이언트 객체는 실행하는 책임만 담

- DIP 의존관계 역전 원칙(추상화에 의존해야지, 구체화에 의존 X - 의존성 주입은 이 원칙을 따르는 방법 중 하나)

• 새로운 할인 정책을 개발, 적용하려고 하니 클라이언트 코드도 함께 변경 → 기존 클라이언트 코드(OrderServiceImpl)는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는 것 같았지만 FixDiscountPolicy 구체화 구현 클래스에도 함께 의존함
• 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경 → 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없음
• AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입 → DIP 원칙을 준수, 문제해결

- OCP (소프트웨어 요소는 확장엔 열려 있으나 변경엔 닫혀 있어야 함)

• 다형성 사용, 클라이언트가 DIP를 지킴
• 어플리케이션을 사용 영역과 구성 영역으로 나눔
• AppConfig가 의존관계를 FixDiscountPolicy  ➡️ RateDiscountPolicy 로 변경, 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 된다
• 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있다! → 변경이 닫혀있다 : 변경할 필요가 없다

IoC, DI, 컨테이너

 

- 제어의 역전IoC(Inversion of Control)

- 기존 프로그램 → 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행함
- 구현객체가 프로그램의 제어 흐름을 스스로 조종 - 개발자 입장에서는 자연스러운 흐름

🔹AppConfig의 등장
- 구현 객체는 자신의 로직을 실행하는 역할만 담당 → 프로그램의 제어 흐름은 AppConfig가 가져감
(OrderServiceImpl은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모름 - 프로그램에 대한 제어 흐름에 대한 권한 : AppConfig가 가지고 있음)
- OrderServiceImpl 도 AppConfig가 생성
- AppConfig는 OrderServiceImpl 이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 도 있음➡️ 이런 사실을 OrderServiceImpl 는 모름, 본인 로직만 수행
- 프로그램의 제어 흐름을 직접 제어 하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라고 함

내가 제어하고 호출하는게 아니라 프레임워크가 대신 호출하는 것
제어권이 뒤바뀐다 → 제어의 역전
AppConfig가 Impl(구현체)를 쓸 것이라고 결정한다 

🔹프레임워크 vs 라이브러리 
내가 작성한 코드를 제어, 대신 실행 → 프레임워크 ok(JUnit)  ➡️ 프레임워크
내가 작성한 코드가 직접 제어의 흐름을 담당 ➡️ 라이브러리

 

- 의존관계 주입(Dependency Injection)

- OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존 → 실제 어떤 구현체가 사용될지 모름
- 의존관계 : 정적인 클래스 의존관계 / 실행 시점에 결정되는 동적인 객체(인스턴스)의존 관계 둘을 분리해서 생각

- 정적인 클래스 의존관계 : 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있음, 어플리케이션을 실행하지 않아도 분석할 수 있음 → 클래스 코드만 열어서 사용할 수 있는 
- OrderServiceImpl은 MemberRepository, DiscountPolicy에 의존한다는 것을 알 수 있음 
➡️ 이러한 의존관계만으로는 실제 어떤 객체가 OrderServiceImpl 에 주입될 지 알 수 없음

클래스 다이어그램

의존 관계 다이어그램

show Dependencies

의존관계

• 의존관계를 확인할 수 있다

동적인 객체 인스턴스 의존 관계
- 어플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계

- 의존관계 주입(DI) : 어플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계거 연결 되는 것

- 객체 인스턴스를 생성하고 그 참조값을 전달해서 연결됨

- 의존관계 주입을 사용 → 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있음/ 정적인 클래스 의존관계를 변경하지 않고(어플리케이션 코드를 수정 x), 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있음

 

💠IoC 컨테이너, DI 컨테이너

- (AppConfig처럼) 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것 : IoC 컨테이너 or DI 컨테이너
- 의존관계 주입에 초점을 맞추어 최근에는 DI 컨테이너라 함/ or 어셈블러, 오브젝트 팩토리 등으로 불리기도 함 

---

스프링으로 전환하기

 

- 지금까지 순수한 자바 코드만으로 DI를 적용했는데 이제부터는 스프링을 사용!

 

- AppConfig 스프링 기반으로 수정

import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(), discountPolicy());
    }
    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

• @Configuration 어노테이션 추가 - 설정정보, 구성정보를 담당하는 것 
• 항상 본인이 쓰는 import가 정확한 것인지 확인해야된다
• 모든 메서드들이 스프링 컨테이너에 등록이 된다

- MemberApp에 스프링 컨테이너 적용

public class MemberApp {

    public static void main(String[] args) {

        ApplicationContext applicationContext =
                new AnnotationConfigApplicationContext(AppConfig.class);
        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은 모든게 ApplicationContext로 시작한다 
• ApplicationContext : 스프링컨테이너 - 모든(객체 - @Bean )걸 관리해준다 

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

• 어노테이션을 기반으로 Config를 하고 있음
• 파라미터로 AppConfig를 넣는다 ➡️ AppConfig에 있는 환경설정 정보를 가지고 스프링이 @Bean에 속해 있는 메서드를 스프링 컨테이너에 등록해 관리해 준다 

applicationContext.getBean("memberService", MemberService.class);

• ("name", type)
• AppConfig에서 무엇을 꺼내 사용할 것인지 
• 두번째는 타입!
• 기본적으로 메서드 이름으로 등록되어 있음

main() 실행

• 위에 5개는 스프링 내부적으로 등록
• 밑에 5개는 ➡️ @Bean으로 등록해 놨던 것들이 스프링 컨테이너에 등록됨  
• name = key, value = return 값
• ex. memberService = key / new MemberServiceImpl() - 객체 인스턴 = value

- OrderApp에 스프링 컨테이너 적용

public class OrderApp {

    public static void main(String[] args) {

        ApplicationContext applicationContext =
                new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);


        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(
                memberId, "itemA", 20000);

        System.out.println("order = " + order);
//        System.out.println("order.calculatePrice = " + order.calculatePrice());

    }
}

• MemberApp와 같이 코드를 변경한다

• 잘 돌아가는 걸 확인할 수 있다

- 스프링 컨테이너?

- ApplicationContext = 스프링 컨테이너
- 기존에는 개발자가 AppConfig를 사용해 직접 객체를 생성, DI했으나 → 스프링 컨테이너를 통해서 사용
- @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용
➡️ @Bean이라 적인 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록 → 이렇게 스프링 컨테이너에 등록된 객체 = 스프링 빈
- @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용(memberService , orderService)
- 이전에는 개발자가 필요한 객체를 AppConfig를 사용해 직접 조회 → 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 됨
- 스프링 빈 ➡️ applicationContext.getBean() 메서드를 사용해서 찾을 수 있음
- 직접 자바코드로 모든 것을 했음 ➡️ 스프링 컨테이너에 객체를 빈으로 등록 → 스프링 컨테이너에서 스프링 빈을 찾아 사용하도록 변경! (@Autowired도 같음) 

→ 코드가 더 복잡해진 것 같은데, 도데체 어떤 장점이 있는걸까? 

 

 

 

 

 

 

---

<출처 - 인프런(스프링 핵심 원리 - 기본편) , 김영한 >

- https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

- (스프링 핵심 원리 - 기본편) 강의를 듣고 학습을 위해 작성했습니다.