1. 스프링의 핵심

• 스프링은 자바 기반의 프레임워크
• 자바의 가장 큰 특징 : 객체 지향 언어
• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크임

그럼 객체 지향의 특징이 뭔데?

2. 객체 지향 특징

객체지향에는 4가지가 있다.

• 추상화
• 캡슐화
• 상속
• 다형성

3. 객체 지향 프로그래밍

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

객체들의 모임 + 객체는 데이터를 주고받고 처리할 수 있음

유연하고 변경이 용이?

• 컴퓨터 부품 갈아 끼우듯, 키보드,마우스를 갈아 끼우듯

• 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법

  => 다형성 (Polymorphism)

4. 다형성

운전자 - 자동차

• 운전자는 k3를 타다가, 아반떼로 차를 바꿨다.
• 운전할 수 있는가? -> Yes

->

• 자동차가 바뀌어도 운전자에게는 영향을 주지 않는다.
• 운전자는 자동차만 있으면 운전을 할 수 있다.
• 운전자(클라이언트)에게 영향을 주지 않고 차종이 추가될 수 있다.

다형성을 비유하자면...

• 운전자 - 자동차
• 공연 무대 남자주연을 원빈 -> 강동원
• 키보드, 마우스, 세상의 모든 인터페이스들
• 정렬 알고리즘
  • 실제 코드 상에서 정렬 알고리즘이 기능만 같으면, 성능이 더 나은 알고리즘으로 교체
• 할인 정책

역할과 구현을 분리하자!

역할과 구현으로 구분하면 클라이언트는

• 대상의 역할(인터페이스)만 알면 된다.
• 구현 대상의 내부 구조를 몰라도 된다.
  • 자동차의 바퀴가 어떤 건지? 엑셀을 얼마나 밟는지? 몰라도 된다.
• 구현 대상 자체를 변경해도 영향을 받지 않는다.
  • 자동차가 전기차로 바뀌어도 그냥 엑셀만 밟으면 된다.

역할과 구현을 분리하자! - 자바

• 자바 언어의 다형성을 활용하자
  • 역할 = 인터페이스
  • 구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때, 역할과 구현을 명확히 분리해서 설계한다.
• 객쳬 설계 시, 역할(인터페이스)를 먼저 설계해서 부여한 후, 그 역할을 수행하는 구현 객체 만들기

꼭 인터페이스가 아니고, 일반 상속관계도 다형성이 가능하다.

가급적이면 인터페이스를 하는 게 나음

• 인터페이스는 다중으로 상속-구현할 수 있음
• 일반 상속 관계는 단일 상속밖에 안 됨

핵심은 구현보다 인터페이스가 먼저이다.

객체의 협력과 관계

• 혼자 있는 객체는 없다.
• 클라이언트 = 요청하는 사람
• 서버 = 그 요청을 받아서 응답하는 사람
• 수많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.
• 단순하게 객체끼리 요청-응답부터 ~ 서버끼리, 시스템끼리 요청을 주고 받을 수 있음

• 클라이언트는 서버에게 요청
• 클라이언트는 동시에 서버가 될 수 있다.
• 클라이언트가 서버에게 요청하고, 서버가 또 클라이언트가 되어 다른 서버들에게 요청
• 응답의 형태는 꼭 데이터가 아닐 수도 있다.
  • 내부적으로 프린트를 할 수도 있고, 리턴값이 void가 될 수도 있다.

자바 언어의 다형성

• MemberService가 인터페이스 MemberRepository의 save()를 호출

• 누가 호출될까?

• MemoryMemberRepository가 들어있으면 이 레파지토리의 save()가 호출

• JdbcMemberRepository가 들어있으면 이 레파지토리의 save()가 호출

  => 오버라이딩

• 오버로딩 : 메서드를 여러 개 정의
• 오버라이딩 : 기능을 재정의
• 자바 언어의 다형성은 오버라이딩으로 동작한다
• 오버라이딩은 자바의 기본 문법이다.
  • 결과적으로 오버라이딩 된 메서드가 실행된다.

다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있는 것이
java 언어가 가진 다형성의 장점

• 여기서는 MemberService가 클라이언트이다.
• 클라이언트는 MemberRepository에 의존한다.
• 의존한다는 것은? MemberService는 MemberRepository를 알고있다.
• MemberRespository에 이 인터페이스를 구현한
  • MemoryMemberRepository와 JdbcMemberRepository를 할당할 수 있을까?

public class MemberService {
    private MemberRepository memberRepository = new MemoryMemberRepository();
}

• MemberService가 인터페이스 MemberRepository 를 선언
• 여기에 대해서 new MemoryMemberRepository() 로 값 대입

public class MemberService {
    //private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}

• 또 new JdbcMemberRepository() 로도 값을 대입할 수 있다.

반대로, 인터페이스 MemberRepository or 부모 클래스와는 관계없는 클래스는 할당할 수 없다.

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
• 다형성의 본질을 이해하려면, 협력이라는 객체 사이의 관계에서 시작해야 한다.
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있어야 한다.
  • MemberService가 바라보는 인터페이스 MemberRepository의 save()를
    • MemoryMemberRepository의 save() 일 수도 있고
    • JdbcMemberRepository의 save() 일 수도 있다.

정리 - 다형성은...

• 유연하고 변경에 용이하다.
• 확장 가능한 설계가 가능
  • MemoryMemberRepository가 아닌 JdbMemberRepository로 바꿔도 MemoryMemberRepository에는 영향이 없음
• 클라이언트에 영향을 주지 않는 변경이 가능하다.
• 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.

한계점

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

스프링과 객체지향

• 다형성이 제일 중요
• 스프링에서의 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용하여 역할/구현을 편리하게 다룰 수 있도록 지원

6. SOLID 원칙

• SRP : 단일 책임 원칙 (Single Responsibl)

  • 하나의 클래스는 하나의 책임만 가져야 한다.
  • 하나의 책임은 클 수도 있고, 작을 수도 있음.
  • 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
    • ex) UI 하나 변경하는데 SQL 코드부터 앱까지 다 변경해야 함 -> 잘못 설계됨
  • 계층이 잘 나뉘어져 있음. 그렇다고 기능이 작게 쪼개지거나/너무 크면 단일 책임 원칙이 깨진다.

• OCP : 개방-폐쇄 원칙 (Open/Closed Principle)

  • s/w 요소는 확장에는 열려있으나, 변경에는 닫혀있어야 한다.
  • 기능을 확장하려면 코드가 변경되어야 하는데, 변경을 안 해도 된다?
  • java 언어는 다형성을 활용해서 개방-폐쇄 원칙을 지킬 수 있음
  • 인터페이스를 구현한 새로운 클래스를 하나 만드는 것은 기존 코드를 변경시키지 않음(변경x 확장o)

    public class MemberService {
        //private MemberRepository memberRepository = new MemoryMemberRepository();
        private MemberRepository memberRepository = new JdbcMemberRepository();
    }

    • 문제점
      • MemoryMemberRepository가 아닌, JdbcMemberRepository로 바꾸고 싶음
      • MemberService의 코드를 바꿔야 함. (Memory...를 주석처리하고 Jdbc..로 변경)
        • OCP랑 다른데??
        • 변경에 닫혀 있어야 되는데, 변경에 안 닫혀 있음
        • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
        • 다형성을 사용했지만 OCP 원칙을 지킬 수 없음
  • 객체를 생산, 객체 관계를 맺어주는 설정자가 별도로 필요함. <- 스프링 컨테이너가 해줌
  • OCP 원칙을 지키기 위해서는 DI, IOC 컨테이너가 필요함

• LSP : 리스코프 치환 원칙 (Liskov Substitution Principle)

  • ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 하려면 LSP 위반, 느리더라도 앞으로 가야함
  • 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스를 바꿀 수 있어야 한다.
  • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
  • 단순히 컴파일에 성공하는 것을 넘어서는 이야기. 컴파일 오류는 안 나지만 인터페이스 규약을 맞춰야 한다.

• ISP : 인터페이스 분리 원칙 (Interface Segregation Principle)

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

• DIP : 의존관계 역전 원칙 (Dependency Inversion Principle)

  • 프로그래머는 구체화에 의존하는 게 아닌, 추상화에 의존해야 한다.
  • 의존성 주입은 위의 원칙을 따르는 방법 중 하나
    • 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다.
  • 역할(Role)에 의존하게 해야 한다는 것과 같다.
    • 클라이언트가 인터페이스에 의존해야 객체에서도 유연하게 구현체를 변경할 수 있음.
    • 구현체에 의존하게 되면 변경이 어려워짐
  • MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존함 (의존 = 내가 저 코드를 알아)
  • MemberService 클라이언트가 구현 클래스를 직접 선택한다.
    • MemberRepository memberRepository = new MemoryMemberRepository();
    • 다른 걸 바꾸려면 코드를 변경해야 함
      • 추상화에도 의존(MemberRepository), 구체화에에도 의존(MemoryMemberRepository)
      • DIP 위반
  • 클래스 레벨에서 설계 시, MemberService는 MemberRepository 인터페이스에만 의존하도록 설계해야 한다.

7. 정리

• 객체 지향의 핵심은 다형성이다.
• 그러나 다형성만으로는 구현 객체 변경 시, 클라이언트 코드도 함께 변경된다.
• 다형성만으로는 OCP, DIP 를 지킬 수 없다.

8. 스프링

• 스프링은 다음 기술로 다형성 + OCP, DIP 를 가능하게 지원한다.
  • DI(Dependency Injection) : 의존관계, 의존성 주입
  • DI 컨테이너 제공
  • java의 객체들을 어떤 컨테이너 안에 넣고, 이 안에서 의존관계를 서로 연결해주고 주입해주는 기능 제공
• 클라이언트 코드 변경 없이 기능 확장이 가능해짐
• 쉽게 부품을 교체하듯이 개발할 수 있다!