DO MY BEST

대부분의 의존관계는 애플리케이션이 끝날 때 까지 변하면 안된다. 불변함을 유지해야 한다. 이를 생성자 주입이 한다. 수정자 주입을 사용하면 setXxx 메서드를 public 으로 열어두어야 하므로 누군가가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

만약에 수정자 의존관계를 쓴다고 해보자.

결과는 

NPE 이 난다. 실제로 OrderServiceImpl 에 어떤 의존관계 주입이 되어야 하는지 한눈에 알지 못하고 코드를 까봐야 알 수 있다. 그러나 생성자 주입을 사용하면 

이렇게 바로 문제점이 표시되면서 실행 시켜보면 컴파일 오류뜬다. 생성자가 지정하면 필수값이 들어가야하기 때문에 바로 필요한 값을 인지할 수 있다. 컴파일 오류는 세상에서 가장 빠르고, 좋은 오류이다.

생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다. 그래서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아준다.

참고: 수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되므로, 필드에 final 키워드를 사용할 수 없다. 오직 생성자 주입 방식만 final 키워드를 사용할 수 있다.

정리

• 생성자 주입 방식을 선택하는 이유는 여러가지가 ㅇ지만, 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이기도 하다.
• 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.
• 항상 생성자 주입을 선택해라. 그리고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 않는게 좋다.

의존관계 주입은 크게 4가지 방법이 있다.

1. 생성자 주입

2. 수정자 주입(setter 주입)

3. 필드 주입

4. 일반 메서드 주입

1. 생성자 주입

생성자에 @Autowired 가 된 것을 볼 수 있다. 첫번째로 스프링 컨테이너가 컴포넌트 스캔을 하고 OrderServiceImpl 이 @Component 가 붙어있어서 스프링 빈에 등록이 될 때, 등록이 되면 생성자가 호출 되어야 하니까, 생성자를 호출할 때 @Autowired 가 있는지 찾는다. 있으면 생성자가 요구하는 파라메터들의 타입들(여기서는 MemberRepository, DiscountPolicy) 를 가지고 있는 스프링 빈을 스프링 컨테이너가 꺼내서 주입을 시켜준다. 

• 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다.
• 지금까지 우리가 진행했던 방법이 바로 생성자 주입이다.
• 특징
  • 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
  • 불변, 필수 의존관계에 사용

여기서 불변은 누군가가 수정하는 메서드를 만들지 않는 이상 딱 한번만 호출되기 때문에 변하지 않는다. 개발에서 불변이라는 것이 정말 중요하다. 개발 습관에서 한계점, 제약이 있어야 한다. 다 퍼블릭으로 열어두면 뭐가 수정이 되었는지 어디서 수정되었는지 알 수 없어진다. 생성자를 통해서만 의존관계가 주입이 되고 어디서도 생성자에서 설정 된 인스턴스들이 수정되는 메서드가 있어서는 안된다. 왜냐하면 개발자의 의도는 처음에 AppConfig 로 스프링 컨테이너에 빌딩되어서 올라갈 때 연관관계를 다 만들고 더이상의 수정 없이 끝내고 싶어 한것이다. 예를 들어, 공연 도중에 배우들을 바꿀 일이 없고, 공연이 시작하기 전에 배우들을 다 정해놓고 끝내고 싶은 것이다. 결론적으로 값을 세팅하고 더이상 값을 바꾸면 안될때, 가급적으로 생성자 에다가 값을 넣고 수정자 메서드(setter 메서드) 를 만들지 않으면 된다. 이렇게 하면 버그도 줄일 수 있다. 

여기서 필수는 필드에 변수들이 final 로 정의를 해야한다는 의미이다. final 로 변수를 정의 하면 꼭 그 변수에 할당되는 값이 있어야 한다. 값이 무조건 있어야 할 때를 가리킨다.(특히 생성자에 들어가는 값들) 

중요: 생성자가 하나만 있으면 @Autowired 가 안붙어 있어도 인식을 해서 의존관계 주입이 일어난다.

2. 수정자 주입

• setter 라 불리는 필드의 값을 변경하는 수정자(setter) 메서드를 통해서 의존관계를 주입하는 방법이다.
• 특징
  • 선택, 변경 가능성이 있는 의존관계에 사용
  • 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.

이렇게 각 타입별로 setter 들을 만들고 각각에 @Autowired 를 붙여도 의존관계 주입이 된다. 그러나 @Autowired가 없으면 안된다. 

여기서 스프링 컨테이너의 라이프사이클을 말해보면, OrderServiceImpl 을 스프링 컨테이너에 등록을 한다. 그 다음에 두 가지로 나뉘는데 첫 번째는 스프링 빈을 등록하고, 의존관계를 자동으로 주입한다.( @Autowired 가 걸린 애들을 연관관계를 주입시킨다 ) 해당 방법(setter 주입)은 스프링 빈을 등록하고 의존관계 주입 준비 단계 에서 일어날 때 일어난다. 생성자 주입은 하나의 인스턴스가 스프링 빈에 등록이 되면서 생성자로 바로 다른 것들도 스프링 빈이 등록되기 때문에 선택적으로 주입하는게 아니라 필수적으로 주입이 된다.

참고: @Autowired 의 기본 동작은 주입할 대상이없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다

생성자 주입이랑 수정자(setter)주입 이 함께 쓰이면 어떻게 될까??

생성자로 부터 인스턴스가 주입이 되고 그 다음 순서 상관없이 수정자 주입으로 인스턴스가 주입된다. 몰론 여기서도 스프링 컨테이너는 싱글톤을 보장해주기 때문에 생성자로 주입된 인스턴스들과 setter 로 주입된 인스턴스들은 모두 같은 객체들이다.

3. 필드 주입

• 이름 그대로 필드에 바로 주입하는 방법이다.
• 특징
  • 코드가 간결하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있다.
  • DI 프레임워크가 없으면 아무것도 할 수 없다.
  • 사용하지 말자!
    • 애플리케이션의 실제 코드와 관계 없는 테스트 코드 에서는 괜찮다.(스프링 강좌 24분에 예시 나옴)
    • 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

이렇게 하면 문제점이 setter 가 필요하다. 필드 주입을 사용할 바에는 setter 주입을 사용하는 것이 나은 형상이다.

4. 일반 메서드 주입

• 일반 메서드를 통해서 주입 받을 수 있다.
• 특징
  • 한번에 여러 필드를 주입 받을 수 있다.
  • 일반적으로 잘 사용하지 않는다.

그냥 메서드 위에 @Autowired 있고 이 메서드를 통해 의존관계 주입을 해준다. 사실상 수정자 주입이랑 같다. 이것을 생성자 주입이랑 수정자 주입에서 다 해결하기 때문에 이것을 사용할 일은 거의 없다.

참고: 어쩌면 당연한 이야기이지만 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다. 스프링 빈이 아닌 Member 같은 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작하지않는다.

코드로 컴포넌트 스캔과 의존관계 자동 주입을 알아보자.

먼저 기존 AppConfig.java 는 과거 코드와 테스트를 유지하기 위해 남겨두고, 새로운 AutoAppConfig.java 를 만들자.

@Component
public class MemoryMemberRepository implements MemberRepository {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
  public class OrderServiceImpl implements OrderService {
      private final MemberRepository memberRepository;
      private final DiscountPolicy discountPolicy;
@Autowired
      public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
  discountPolicy) {
          this.memberRepository = memberRepository;
          this.discountPolicy = discountPolicy;
      }
}

  package hello.core.scan;
  import hello.core.AutoAppConfig;
  import hello.core.member.MemberService;
  import org.junit.jupiter.api.Test;
  import org.springframework.context.ApplicationContext;
  import
  org.springframework.context.annotation.AnnotationConfigApplicationContext;
  import static org.assertj.core.api.Assertions.*;
  public class AutoAppConfigTest {
      @Test
      void basicScan() {
          ApplicationContext ac = new
  AnnotationConfigApplicationContext(AutoAppConfig.class);
          MemberService memberService = ac.getBean(MemberService.class);
          assertThat(memberService).isInstanceOf(MemberService.class);
      }
}

@Configuration 을 알아보기 위해서 이 코드를 살펴보자,

시나리오

1. @Bean memberService 를 호출하면 ➡️ MemoryMemberRepository() 를 한번 호출한다. 

2. @Bean orderService 를 호출하면 ➡️ MemoryMemberRepository() , discountPolicy() 를 호출한다.

이렇게 하면 결과적으로 각각 다른 2개의 MemoryMemberRepository() 가 두 번 호출 되니까 싱글톤이 깨지는게 아닐까요?? 스프링 컨테이너가 싱글톤을 보장해준다고 했는데 과연 그럴까?? 직접 테스트 해보자

✅ 테스트 방법

1. MemoryMemberRepository 를 불러오는 MemberServiceImpl 에서 

테스트 용도로 MemberServiceImpl, OrderServiceImpl 둘 다 각각 생성자로 들어오는 memberRepository 의 값을 확인하는 getMemberRepository 메서드를 만들었다.

2. 각각의 memberRepository 를 테스트 코드를 통해 확인해보자.

밑에는 테스트코드이고

밑에는 테스트 코드의 결과이다.

결과는 세개의 memberRepository가 같은 것을 확인할 수 있다. 분명 세번의 다른 memberRepository의 인스턴스가 호출될 것 같았지만 모두 같은 인스턴스가 공유되어 사용되고 있음을 확인할 수 있었다. 어떻게 된 일일까? 혹시 두 번 호출이 안되는 것일까? 다음 실험을 통해 알아보자. 

이렇게 호출 되는 부분마다 찍어보면서 확인해보았다. 

찍어본 세 개의 메서드 각각 한번씩 호출 되었는 것을 볼 수 있다. 이 비밀이 어디에 있을까?? ➡️ @Configuration 을 적용한 AppConfig 에 있다.

시나리오

1. AppConfig 스프링 빈을 조회해서 클래스 정보를 출력해보자.

순수한 클래스라면 다음과 같이 출력되어야 한다.

class hello.core.AppConfig

그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB 이라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다.

그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다. 아마도 다음과 같이 바이트 코드를 조작해서 작성되어 있을 것이다. (실제로는 CGLIB의 내부 기술은 매우 복잡하다.)

만약 @Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

@Configuration 을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean만 적용하면 어떻게 될까?

@Configuration 을 주석처리 하고 @Bean 만 적용해보고 밑에 테스트 코드를 다시 돌려보았다.

결과로 이렇게 나왔다. 

CGLIB 기술을 사용 하지 않은 순수한 AppConfig 가 나왔다. 그리고

memberRepository가 여러번 호출되는 것을 확인할 수 있듯이 순수한 자바 코드가 나오면서 싱글톤이 깨진다!!

무상태란.

• 특정 클라이언트에 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
• 가급적 읽기만 가능해야 한다.
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

싱글톤 컨테이너

= 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성) 으로 관리한다. 
= 스프링 빈(Bean)이 바로 싱글톤으로 관리되는 빈이다.

1. 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.

• 이전에 설명한 컨테이너 생성 과정을 자세히 보자. 컨테이너는 객체를 하나만 생성해서 관리한다.

• 위 그림에서 보면 빈 객체를 미리 스프링 컨테이너(싱글톤 컨테이너)가 등록해서 관리해준다. 그리고 조회하면 관리되고 있는 객체를 불러온다. 여러개 조회해도 이미 관리되고 있는 객체를 조회한다. 예를 들어 memberService 를 몇번을 불러도 MemberServiceImpl@x01 를 조회해준다.

2. 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.

3. 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
  • 싱글톤 패턴을 위해서 들어가는 지저분한 코드들을 안들어가도 된다. 그리고 " (구체 클래스).getInstance() " 이렇게 해야하기 때문에 DIP 에 위반한다. 스프링이 관리 해주기 때문에 이런 코드가 다 빠져도 된다.
• DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다. ➡️ 스프링이 다 관리 해주는 덕분이다.

이 테스트로 같은 객체를 불러오는 것을 확인할 수 있다.

조회할 때 마다 스프링이 처음에 빈 등록한 것을 계속 반환해주는 것을 확인할 수 있다. ➡️ 싱글톤 맞다~

위 테스트에서 MemberServiceImpl 객체를 불렀는데 이 객체의 코드를 확인해보자. 과연 싱글톤 관련된 코드가 있을까? ⬇️⬇️⬇️

싱글톤 관련된 코드는 없는 것을 확인할 수 있다.

싱글톤 적용 Before After

• Before

• After

이러한 싱글톤 방식에도 주의점이 있다.(매우 중요) 다음 글에서 확인해보자.

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

1. 스프링 컨테이너 생성

• new AnnotationConfigApplicationContext(AppConfig.class)
• 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야 한다.
• 여기서는 AppConfig.class 를 구성 정보로 지정했다.

2. 스프링 빈 등록

• 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다.

빈(Bean) 이름

• 빈 이름은 메서드 이름을 사용한다.
• 빈 이름을 직접 부여할 수 도 있다.
  • Bean(name="memberService2")
  • 주의: 빈 이름은 항상 다른 이름을 부여 해야 한다. 같은 이름을 부여하면, 다른 빈이 무시되거나, 기존 빈을 덮어버리거나 설정에 따라 오류가 발생한다.

3. 스프링 빈 의존관계 설정 - 준비

4. 스프링 빈 의존관계 설정 - 완료

• 스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.
• 단순히 자바 코드를 호출하는 것 같지만, 차이가 있다. 이 차이는 뒤에 싱글톤 컨테이너에서 설명한다.

참고: 스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져 있다. 그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다. 여기서는 이해를 돕기 위해 개념적으로 나누어 설명했다. 자세한 내용은 의존관계 자동 주입에서 다시 설명하겠다.

AppConfig

@Configuration
public class AppConfig {// 모든 객체의 생성과 연결을 담당한다. (이렇게 하므로써 DIP 가 완성된다.)

@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
    }

    @Bean
public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
return new RateDiscountPolicy();
    }

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

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

에서 

@Configuration
public classAppConfig {// 모든 객체의 생성과 연결을 담당한다. (이렇게 하므로써 DIP 가 완성된다.)

@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
    }

    @Bean
public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
return new RateDiscountPolicy();
    }

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

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

로 바뀌었다.

MemberApp

public class MemberApp {

public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        Member member =newMember(1L,"memberA", 25L, Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = "+ member.getName());
        System.out.println("find member = "+ findMember.getName());
        System.out.println("member = "+ member);
    }
}

에서

public class MemberApp {

public static void main(String[] args) {
        ApplicationContext applicationContext =newAnnotationConfigApplicationContext(AppConfig.class);// @Bean 들을 관리해준다.
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);// ( AppConfig 안에 있는 메서드 이름, 타입 )

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

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = "+ member.getName());
        System.out.println("find member = "+ findMember.getName());
        System.out.println("member = "+ member);
    }
}

로 바뀌었다.

실행

이렇게 저장 되기 때문에 꺼낼 때 밑에처럼 타입에 이름을 주고 꺼내면 된다.

스프링 컨테이너

• ApplicationContext 를 스프링 컨테이너라 한다.
• 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.
• 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.
• 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService )
• 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다. 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다.
• 기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.
• 코드가 약간 더 복잡해진 것 같은데, 스프링 컨테이너를 사용하면 어떤 장점이 있을까? ⇒ 어마어마한 장점이 있다. 차근차근 알아보자

스프링 컨테이너가 생성되는 자세한 과정은 다음 글을 참고하면 된다.

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

SRP: 단일 책임 원칙 (single responsibility principle)

OCP: 개방-폐쇄 원칙 (Open/closed principle)

LSP: 리스코프 치환 원칙 (Liskov substitution principle)

ISP: 인터페이스 분리 원칙 (Interface segregation principle)

DIP: 의존관계 역전 원칙 (Dependency inversion principle)

1. SRP 단일 책임 원칙 (single responsibility principle)

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

• 하나의 책임이라는 것은 모호하다.
  • 클 수 있고, 작을 수 있다.
  • 문맥과 상황에 따라 다르다.
• 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
  • 예) UI 변경, 객체의 생성과 사용을 분리

책임이라는 것이 실무에 가보면 모호하다. 어떻게 해야 설계를 잘 하는 것일까를 따져보면 중요한 판단의 기준은 변경 이다. 변경을 했을 때 파급(=하나의 클래스나 하나의 지점만 고치는 것)이 적으면 단일 책임 원칙(SRP)를 잘 따르게 설계 한 것이 된다. 

2. OCP 개방-폐쇄 원칙  (Open/closed principle)

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

• 확장을 하려면 당연히 기존 코드를 변경해야 하는거 아냐? => 다형성을 활용하면 가능하다.
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
• 역할과 구현의 분리를 생각해보자

OCP에 문제점이 있다.

이 그림에 의거해서

이렇게 MemberService 클라이언트가 구현 클래스( 여기에서는 MemoryMemberRepository, JdbcMemberRepository) 를 직접 선택했을 때, 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.

이를 보고 알 수 있듯이, 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.

이 문제를 어떻게 해야하나? => 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.  => 결론적으로 별도의 조립, 설정자들이 스프링 컨테이너가 해주는 역할이다. (DI, IoC 컨테이너) 답은 정리에 나와있다.

3. LSP 리스코프 치환 원칙  (Liskov substitution principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
• 단순히 컴파일에 성공하는 것을 넘어서는 이야기

정리 하자면, 자동차 인터페이스가 있으면 구현체가 구현을 하면 되는 기능들이 있다. "악셀" 이라는 기능이 있으면 무조건 앞으로만 가는 법이 없으니 뒤로 가는 기능을 내가 만들었다고 쳐도 컴파일은 성공적으로 될 것이다. 리스코프 치환 원칙은 컴파일 단계를 단순히 얘기하는 것이 아니다. 인터페이스 규약이 "악셀"은 무조건 앞으로 가야 한다는 규약이 있을 것이다. 이런 규약을 맞춰야 하는 것이 이 원칙이다. (기능적으로 보장을 해줘야 한다)

4. ISP 인터페이스 분리 원칙  (Interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
  • 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
  • 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
• 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

운전 인터페이스와 정비 인터페이스로 분리 하면 클라이언트를 운전자 클라이언트와 정비사 클라이언트로 분리 할 수 있다. 예를 들어 정비에 관련된 문제가 있어서 기능을 바꿔야할 때 정비사 클라이언트에 대한 부분만 바꾸면 된다. 결국에는 기능에 맞게 잘 인터페이스를 쪼개는게 좋다는 뜻이다. 

5. DIP 의존관계 역전 원칙  (Dependency inversion principle)

• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.
• 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
• 앞에서 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 아주 어려워진다.

클라이언트 코드가 구현 클래스를 바라보지 말고 인터페이스만 바라봐라는 뜻 예를 들어 MemberService 가 MemberRepository 인터페이스만 바라보고 구현 클래스 ( MemoryMemberRepository, JdbcMemberRepository )를 바라보지 말라는 얘기이다. 

여기서도 예를 들어 설명하면, 운전자는 자동차 역할 만 알면 되지 K3, 아반떼, 테슬라 모델3 를 알 필요가 없다는 뜻 DIP 이다.

• 위의 OCP에서 설명한 MemberService는 MemberRepository인터페이스에 의존하지만, 구현 클래스에도 동시에 의존한다.
• MemberService 클라이언트가 구현 클래스를 직접 선택
  • MemberRepository m = new MemoryMemberRepository();

MemberService 는 인터페이스인 MemberRepository 를 의존하고 있지만 구현 클래스인 MemoryMemberRepository 도 의존하고 있다. 즉 DIP를 위반하고 있다. 그러면 어떻게 DIP를 지킬 수 있을까? 답은 정리에 나와있다.

정리

• 객체 지향의 핵심은 다형성
• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성 만으로는 OCP, DIP를 지킬 수 없다.
• 뭔가 더 필요하다.
  
  • 스프링은 다음 기술로 다형성 + OCP, DIP 를 가능하게 지원
    • DI(Dependency Injection): 의존관계, 의존성 주입
    • DI 컨테이너 제공
  • 클라이언트 코드의 변경 없이 기능 확장
  • 쉽게 부품을 교체하듯이 개발

권장사항 정리

• 모든 설계에 열할과 구현을 분리하자
• 애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는것이 좋은 객체지향 설계이다
• 이상적으로는 모든 설계에 인터페이스를 부여하자

고민

• 인터페이스를 남발하면 추상화라는 비용이 발생한다. 
• 기능을 확장할 가능성이 없다면, 구현 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 방법이다.

스프링을 배우기 전에 알아둬야 할 제일 중요한 것은 "이 프레임 워크를 왜 만들었을까?"라고 해도 과언이 아니다. 우리가 흔히 웹 프레임 워크를 공부할 때 현실적인 목적은 웹 애플리케이션 만들고, DB 접근 편리하게 해주는 기술이고 웹 서버도 자동으로 띄어주기도 하고 특히 자바 스프링은 전자정부 프레임워크 이기도 해서 스프링의 핵심이 될 수 있을까? 이러한 것들은 단지 결과물일 뿐이고 진짜 핵심은 따로 있다.

"스프링은 자바 언어 기반의 프레임워크이다."  에서 진짜 스프링의 핵심이 있다. 그 이유는 자바 언어가 객체지향 언어이기 때문이다. 즉 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내도록 하는 프레임워크이다. 그리하여 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크이다.

따라서, 좋은 객체 지향이 무엇인지 논해볼 필요가 있다. 먼저 객체 지향 프로그래밍의 정의는 다음과 같다. 

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉"객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.(협력)
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

여기서 유연하고 변경이 용이하다는 것은 무엇일까 생각해 볼 수 있다. 예를 들어 레고 블럭 조립 하듯, 키보드 마우스 갈아끼우듯, 컴퓨터 부품 갈아 끼우듯이 쉽게 끼워맞추고 변경할 수 있는 것으로 생각해볼 수 있고. 조금 더 개발 언어로 말을 해보면 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 것이라고 생각할 수 있다. 이러한 유연함은 "다형성(Polymorphism)"에서 나온다.

다형성(Polymorphism)

위와 같은 예시에서 볼 수 있는 것은 다음과 같다. 운전자의 자동차가 K3 에서 아반떼로 바뀌었는데 운전자는 운전에 영향을 받을까? 그렇지 않다. 즉 자동차가 바뀌어도 운전자에게 영향을 주지 않는다. 이것이 가능한 이유는 모든 자동차는 자동차 라는 인터페이스에 따라서 자동차를 구현했기 때문이다. 운전자는 자동차의 역할(interface)에만 의존하고 있는중이다. 

자동차라는 역할을 만들고 구현을 분리한 이유는 무엇일까? 운전자를 위해서이다. ( 개발적으로 봤을 때 여기서의 운전자랑 클라이언트(client) 는 맥락상 비슷한 의미를 가진다. ) 운전자들은 자동차의 내부 구조를 몰라도 된다. 즉 자동차가 내부적으로 바뀌더라도 자동차의 역할만 제대로 하면 운전자에게 영향을 안준다. 이것은 역할과 구현 으로 세상을 구분했기 때문에 가능한 일이다. 제일 중요한 것은 자동차를 여러개 구현할 수 있는 것이 중요한게 아니라 새로운 자동차가 나와도 운전자들은 새로운 것을 배우지 않아도된다는 것이다.

클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있다.
- 다형성의 본질

다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야한다. 

정리하자면,

역할과 구현을 분리

정리

• 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음
• 유연하고, 변경이 용이
• 확장 가능한 설계
• 클라이언트에 영향을 주지 않는 변경 가능
• 인터페이스를 안정적으로 잘 설계하는 것이 중요

한계

• 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.
  • 예시로
    • 자동차를 비행기로 변경해야 한다면?
    • 대본 자체가 변경된다면?
    • USB 인터페이스가 변경된다면?
• 인터페이스를 안정적으로 잘 설계하는 것이 중요하다

지금까지 다형성에 대해서 얘기해 왔다. 그 이유는 스프링의 꽃은 다형성이라고 말해도 무방할 정도이기 때문이다. 스프링은 다형성을 극대화해서 이용할 수 있도록 도와준다. 무엇으로 도와주느냐면, 스프링은 제어의 역전(IoC), 의존관계 주입(DI)로 역할과 구현을 편리하게 다룰 수 있도록 지원한다.