[Spring 기본] 1. 객체 지향 설계와 스프링

안녕하세요!

HTTP를 다 끝내고 Spring으로 돌아왔습니다!

본격적으로 스프링을 배우려면 스프링의 개념적인 부분부터 알아야겠죠?

고고!

---

1. 스프링이란? (스프링 생태계)

1-1. 스프링의 구성

스프링은 필수적인 기술에 속하는 스프링 프레임워크와 스프링 부트, 그리고 선택적인 기술에 속하는 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 Rest Docs, 스프링 배치, 스프링 클라우드로 구성되어 있습니다.

 

핵심적인 부분인 스프링 프레임워크와 스프링 부트는 뒤에서 더 자세히 설명할거구요.

먼저 선택적인 기술들부터 간단하게 설명하도록 하겠습니다.

스프링 데이터란, CRUD 등을 편리하게 사용하도록 도움을 주는 기술입니다. 제일 많이 쓰는 것은 스프링 데이터 JPA 입니다.

스프링 세션이란, 세션 기능을 편리하게 사용하도록 도움을 주는 기술입니다.

스프링 시큐리티는 보안과 관련된 기술입니다.

스프링 Rest Docs는 API 문서화를 편리하게 해주는 기술입니다.

스프링 배치는 배치 처리에 특화된 기술입니다.

마지막으로, 스프링 클라우드는 클라우드 기술에 특화된 기술입니다.

 

이 외에도 많은 기술들이 있습니다.

 

 

1-2. 스프링 프레임워크

사실 이게 제일 중요할거에요.

• 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹 기술: 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술: 트랜젝션, JDBC, ORM 지원, XML 지원
• 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
• 테스트: 스프링 기반 테스트 지원
• 언어: 코틀린, 그루비

이것들을 다 합해서 스프링 프레임워크라고 합니다.

최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용할 수 있습니다.

 

여기서 스프링 부트가 뭘까요?

또 스프링 부트의 장점은 뭘까요?

그건 밑에서 봐보도록 하겠습니다.

 

 

1-3. 스프링 부트의 개념과 장점

스프링 부트란, 스프링을 편리하게 사용하도록 지원하는 기술을 뜻합니다.

최근에는 기본으로 다 사용하고 있습니다.

 

장점을 자세히 설명해보도록 하겠습니다.

• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성합니다.
  • 예전에는 Tomcat 까는 등.. 과정이 굉장히 복잡했습니다.
    지금은 스프링 부트 몇 줄 치고 끄읕~
• Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하도 않아도 됩니다.
• 손쉬운 빌드 구성을 위한 starter 종속성을 제공합니다.
  • 예전에는 이것저것 모든 라이브러리를 사용해서 굉장히 어려웠습니다.
    지금은 springboot.ooostarter 등 여러개 안 땡겨오고 편리하게 구성할 수 있습니다.
• 스프링과 3rd party(외부) 라이브러리를 자동으로 구성합니다.
  • 예전과 달리 요즘은 스프링부트가 유명한 라이브러리들을 알아서 테스트하고, 버전도 다 직접 지정해서 다운로드 해줍니다.
• 메트릭, 상태 확인, 외부 구성과 같은 프로덕션 준비 기능을 제공합니다.
  • 운영 환경에서 모니터링은 중요한데 그런 것들을 스프링 부트에서는 기본적으로 제공합니다.
• 관례에 의한 설정이 간결합니다.
  • 옛날에 스프링 프레임워크만 사용할 때에는 설정하는 것이 힘들었습니다.
    요즘은 스프링 부트로 간결해졌는데, 스프링 부트는 왠만한 것은 디폴트 설정이 메뉴얼에 나와있습니다. 거기서 보고 필요하면 대부분 관례에 따라 설정하면 되고, 일부는 조금만 변경하면 됩니다.

 

1-4. 스프링 단어?

스프링이라는 단어는 문맥에 따라 다르게 사용됩니다.

먼저, 스프링 DI 컨테이너 기술 (핵심인 bean 관리) 로도 사용되고, 스프링 프레임워크 자체로도 사용됩니다.

또한, 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계로도 사용됩니다.

 

 

1-5. 스프링의 핵심 개념, 컨셉

스프링의 핵심 개념, 컨셉은 뭘까요?

웹 애플리케이션을 만들고, DB 접근을 편리하게 해주는 기술일까요?

전자 정부 프레임워크일까요?

웹 서버도 자동으로 띄워줄까요?

클라우드, 마이크로서비스일까요?

 

다 핵심이 아닙니다. 결과물일 뿐이지...

 

스프링의 진짜 핵심은 이렇게 4가지 입니다.

- 스프링은 자바 언어 기반의 프레임워크
- 자바 언어의 가장 큰 특징인 객체 지향 언어
- 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크입니다.
- 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크입니다.

---

2. 좋은 객체 지향 프로그래밍이란?

우선 객체 지향 특징은 4가지가 있습니다.

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

특징에 대해서 설명하기 전에 객체 지향 프로그래밍이 뭔지 알아야 겠죠?

 

객체 지향 프로그래밍은 "객체"들의 모임으로 파악하고자 하는 것이고, 각각의 객체는 메시지를 주고 받고 데이터를 처리할 수 있습니다. (협력)

또한, 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

 

유연하고, 변경이 용이하다?

이것을 다형성이라고 합니다.

 

지금부터 다형성에 대해 알아보도록 하겠습니다.

---

3. 다형성

3-1. 다형성의 실세계 비유

• 실세계와 객체 지향을 1:1로 매칭할 수는 없지만, 그래도 실세계의 비유로 이해하기에는 좋습니다.
• 역할과 구현으로 세상을 구분합니다.
  • 역할: 인터페이스
    구현: 인터페이스 구현한 객체

예시를 한 번 들어보겠습니다.

운전자 - 자동차

크게 운전자 역할과 자동차 역할이 있고, 자동차 역할 안에 자동차 구현이 있습니다.

자동차 역할을 3개의 다른 자동차가 구현합니다.

그러면 운전자는 K3를 타다가 아반떼로 차를 바꾸면 운전할 수 있을까요?

정답은 Yes!

왜냐하면 자동차 역할에 대한 구현만 바뀌었을 뿐이니까죠~

 

그래서 자동차가 바뀌어도 운전자에게 영향을 주지 않습니다,

유연하고 변경이 용이하다는 것이죠.

이유를 자세히 알아볼까요?

자동차 역할의 인터페이스를 다 따라서 자동차를 구현했기 때문입니다.

운전자는 자동차 인터페이스만 알고 역할에 대해서만 의존합니다.

 

근데 중요한건 자동차 역할을 만들고 구현을 분리한 것은 운전자를 위해서 한 것입니다.

운전자를 클라이언트라고 지정해보겠습니다.

클라이언트가 자동차의 내부 구조를 몰라도 되죠?

그러면 구현이 내부적으로 바뀌더라도 자동차 역할만 제대로 하면 운전자에게 영향을 주지 않습니다.

그래서 클라이언트에게 영향을 주지 않고 새 기능을 구현할 수 있습니다.

이건 구현으로 세상을 구분했기에 가능한 것입니다.

 

다른 예시를 들어보겠습니다.

로미오와 줄리엣 공연 무대가 있습니다.

이 안에는 로미오라는 역할과 줄리엣이란 역할이 있습니다.

로미오란 역할을 변우석이 할 수도 있고 서강준이 할 수도 있고 시월이 데려와서 할 수도 있겠죠.

마찬가지로 줄리엣이란 역할도 김유정이 할 수도 있고 한소희가 할 수도 있고 단역배우가 와서 할 수도 있고 잘 못하는 제가 와서 할 수도 있겠죠.

 

뭐가 됐든 배우는 대체가 가능해야 합니다.

공연은 잘 돼야 하니까!

이것이 바로 유연하고 변경이 용이하다는 것입니다.

 

로미오를 클라이언트, 줄리엣을 서버라고 하면 줄리엣(서버)이 바뀐다고 로미오(클라이언트)에 영향을 주지 않죠.

이것이 다형성 입니다.

 

3-2. 역할과 구현을 분리 - 장점

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해집니다.

<장점>

- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

핵심은 클라이언트!

 

3-3. 역할과 구현을 분리 - 자바 언어

• 자바 언어의 다형성을 활용합니다.
  • 역할 = 인터페이스
  • 구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때 역할과 구현을 명확히 분리힙니다.
• 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만듭니다.
  • 핵심은 구현(객체)보다 인터페이스(역할)가 먼저!
  • 수많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다!

 

3-4. 자바 언어의 다형성

오버라이딩을 떠올려봅시다.

떠올리기 전에 오버라이딩과 오버로딩이 뭔지부터 알아볼까요?

• 오버라이딩: 상속 관계에 있는 클래스에서 상위 클래스의 메서드를 하위 클래스에서 재정의하는 것
• 오버로딩: 메서드를 많이 초과 정의하여 로딩하는 것

이 그림은 오버라이딩 된 메서드가 실행되었습니다.

자바 언어의 다형성 장점을 얘기하자면 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있습니다.

몰론 클래스 상속 관계도 다형성, 오버라이딩 적용이 가능합니다.

 

클라이언트는 MemberRepository를 의존하고 있습니다.

알고 있다는 뜻입니다.

 

다형성이기에 부모 타입으로 할당 가능합니다.

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

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

MemoryMemberRepository와 JdbcMemberRepository는 각각 다른 클래스이지만, MemberRepository라는 동일한 부모 클래스를 갖고 있기 때문에 부모 클래스 타입을 갖도록 선언을 할 수 있습니다.

 

 MemberRepository 인터페이스나 부모와 전혀 관계 없는 클래스는 할당 불가능합니다.

 

MemberService라는 클라이언트에 MemberRepository라는 인터페이스가 있는데 여기에 MemoryMemberRepository를 넣으면 2번째 그림이 되는 거고, JdbcMemberRepository를 넣으면 3번째 그림이 되는 것입니다.

 

3-5. 역할과 구현을 분리 - 한계

• 역할(인터페이스) 자체가 변하면 클라이언트, 서버 모두에 큰 변경이 발생합니다.
• 자동차를 비행기로 변경해야 한다면? 대본 자체가 변경된다면? USB 인터페이스가 변경된다면? 다 뜯어고쳐야하고, 기존 것은 더 이상 못 씁니다.
• 인터페이스를 안정적으로 잘 설계하는 것이 중요합니다!!\
  • 인터페이스가 깨지면 끝..ㄷㄷ

 

3-6. 역할과 구현을 분리 - 정리

• 다형성의 본질
  • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있습니다.
  • 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야 합니다.
  • 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있습니다!!
• 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있습니다.
• 유연하고, 변경이 용이하며 확장 가능한 설계입니다.
• 클라이언트에 영향을 주지 않는 변경이 가능합니다.

 

3-7. 스프링과 객체 지향

• 다형성이 가장 중요!! 객체 지향의 꽃🌸
• 스프링은 다형성을 극대화해서 이용할 수 있게 도와줍니다.
• 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원합니다.
  • 스프링 컨테이너는 다형성을 편리하게 사용할 수 있도록 지원하는 기능입니다.

 

스프링을 제대로 이해하려면 다형성 외에 또 알아야 할 것이 있습니다.

그것은 바로 SOLID!!

---

4. 좋은 객체 지향 설계의 5가지 원칙 (SOLID)

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

이거 되게 면접에도 잘 나와요!! 중요!!

SOLID는 이 5가지 원칙의 앞글자를 딴 것입니다.

• SRP: 단일 책임 원칙 (single responsibility principle)
• OCP: 개방-폐쇄 원칙 (Open/closed principle)
• LSP: 리스코프 치환 원칙 (Liskov substitution principle)
• ISP: 인터페이스 분리 원칙 (Interface segregation principle)
• DIP: 의존관계 역전 원칙 (Dependency inversion principle)

 

4-1. SRP 단일 책임 원칙

Single responsibility principle

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

그런데, 이 하나의 책임이라는 것은 참 모호합니다. 책임이 클 수 있고 작을 수도 있고, 문맥과 상황에 따라 다르기 때문이죠.

결국 중요한 기준은 변경이 됩니다.

변경이 있을 때 파급 효과가 적으면 SRP 단일 책임 원칙을 잘 따른 것입니다.

예를 들어, UI 변경과 객체의 생성과 사용을 분리하는 것이 있습니다.

즉, 하나 바꿀 대 이것 저것 다 변경해야 하는 것이면 잘 못 짠 것입니다.

 

 

4-2. OCP 개방-폐쇄 원칙 (중요!!)

Open/closed principle

OCP의 정의는 "소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다." 입니다.

코드 변경 없이 기능을 추가한다고??

다형성을 활용해보면 됩니다.

 

인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하면 되는데 (기능 추가)

코드 예시로 설명해보겠습니다.

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

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

MemberRepository가 데이터를 저장하는 방식을 Memory에서 Jdbc로 바꾸려고 하는 상황입니다.

위 상황은 MemberService 내에서 주입할 MemberRepository의 구현체를 직접 변경하였는데 이는 OCP 위반입니다.

 

OCP를 위반하지 않으려면 밑의 코드처럼 MemberService가 MemberRepository에 직접적인 구현체를 new로 할당하는 것이 아닌 추상화된 인터페이스를 받아오는 방식을 채택해야 합니다.

public interface MemberRepository {
    void save(Member member);
}

public class MemoryMemberRepository implements MemberRepository {

    private static Map<Long, Member> store = new HashMap<>();

    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }
}

public class JdbcMemberRepository implements MemberRepository {
    @Override
    public void save(Member member) {
        String sql = "insert into member(member_id, name) values(?, ?)";
        Connection con = con = getConnection();
        PreparedStatement pstmt = con.prepareStatement(sql);
        ...
    }
}

위의 코드는 MemberRepository라는 추상화 인터페이스와 구체화된 구현체인 MemoryMemberRepository와 JdbcMemberRepsitory를 구현하는 코드입니다.

public class MemberService {

    private MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

위의 코드는 MemberService를 구현하는 코드입니다.

MemberService memberService = new MemberService(new JdbcMemberRepository());
memberService.save(...);

Memory 기반의 MemberRepository를 사용하던 MemberService가 데이터를 DB에 저장하는 방식으로 바꾸기 위해 기존의 MemoryMemberRepository를 수정하는 것이 아닌 JdbcMemberRepository를 구현하는 방식으로 확장을 했습니다.

이는 OCP를 지켜서 기능을 추가한 방식입니다.

 

 

4-3. LSP 리스코프 치환 원칙

Liskov substitution principle

LSP의 정의는 "프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다." 입니다.

인터페이스에서 해당 메소드가 어떤 기능을 해내야 할지 정해져 있고, 하위 클래스는 인터페이스에서 정한 규약을 무조건 지켜서 구현해야 합니다.

 

예를 들어, 자동차 인터페이스의 엑셀은 '앞으로 가야 한다'하는 규약이 정해져 있습니다.

사실 근데 이 엑셀의 기능을 뒤로 가게 구현해도 컴파일하는 데에는 문제가 없습니다.

근데, 컴파일에 성공하는 것을 넘어서 기존에 있는 규약을 위반하면 LSP 리스코프 치환 원칙을 위반하는 것입니다.

그래서 엑셀의 기능을 느리더라도 무조건 앞으로 가게 해야 LSP를 위반하는 것이 아니게 됩니다.

 

 

4-4. ISP 인터페이스 분리 원칙

Interface segregation principle

ISP의 정의는 "특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다" 입니다.

자동차 인터페이스를 운전 인터페이스와 정비 인터페이스로 분리하면, 사용자 클라이언트도 운전자 클라이언트와 정비사 클라이언트로 분리할 수 있겠죠?

그런데 이렇게 분리해서 정비 인터페이스 자체가 변해도 운전자 클라이언트에는 영향을 주지 않습니다.

 

이렇게 기능이 많은 인터페이스 하나를 분리하면 인터페이스가 명확해지고, 대체 가능성이 높아집니다.

 

 

4-5. DIP 의존관계 역전 원칙 (중요!!)

Dependency inversion principle

"추상화에 의존해야지, 구체화에 의존하면 안 된다." 라는 의존성 주입은 이 원칙을 따르는 방법 중 하나입니다.

쉽게 얘기해서 구현 클래스에 의존하지 말고, 추상적인 인터페이스에 의존하라는 뜻입니다.

그리고, 클라이언트 코드가 구현 클래스를 바라보지 말고 인터페이스만 바라보라는 뜻입니다.

 

위의 예제로 따지면 MemberService가 MemberRepository 인터페이스만 바라보고 MemoryMemberRepository와 JdbcMemberRepository에 대해서는 몰라야 한다는 뜻입니다.

 

위에서 얘기했던 역할에 의존하게 해야 한다는 것과 같으며, 구현에 의존하면 대체가 어려워지고 변경이 어려워지므로 추상적인 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있습니다.

 

코드 예시로 설명해보겠습니다.

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

 

MemberRepository가 데이터를 저장하는 방식을 Memory에서 Jdbc로 바꾸려고 하는 상황입니다.

위 상황은 MemberService 내에서 세부 구현을 담당하는 JdbcMemberRepository를 의존했기 때문에 DIP 위반입니다.

 

DIP를 위반하지 않으려면 밑의 코드처럼 추상화된 인터페이스를 의존하는 방식을 채택해야 합니다.

 

public interface MemberRepository {
    void save(Member member);
}

public class JdbcMemberRepository implements MemberRepository {
    @Override
    public void save(Member member) {
        // ... 저장 로직
    }
}

위의 코드는 MemberRepository를 구현하는 코드입니다.

public class MemberService {

    private MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

위의 코드는 MemberService를 구현하는 코드입니다.

MemberService memberService = new MemberService(new JdbcMemberRepository());
memberService.save(...);

위의 코드는 MemberService를 선언할 때의 예시 코드입니다.

 

MemberService가 세부적인 구현을 담당하는 JdbcMemberRepository에 의존하지 않고 추상화된 인터페이스인 MemberRepository만 의존했기 때문에 DIP를 지켰습니다.

---

5. 객체 지향 설계와 스프링

5-1. 다시 스프링으로

스프링 이야기에 왜 객체 지향 이야기가 나올까요?

스프링은 다음 기술로 다형성과 OCP, DIP를 가능하게 지원합니다.

• DI (Dependency Injection): 의존관계, 의존성 주입
• DI 컨테이너 제공
  • 자바 객체들을 어떤 컨테이너 안에 넣어놓고 이 안에서 의존관계를 서로 연결해주고 주입해주는 기능을 제공해 줍니다.

이것들을 활용하면 클라이언트 코드의 변경 없이 기능 확장이 가능하며 쉽게 부품을 교체하듯이 개발할 수 있습니다.

 

옛날에 스프링 없던 시절에 어떤 개발자가 좋은 객체 지향 개발을 하려고 OCP, DIP 원칙을 지키면서 개발을 해봤습니다.

그러니 너무 할 일이 많았습니다. 그래서 프레임워크로 만들어버렸습니다.

순수하게 자바로 OCP, DIP 원칙들을 지키면서 개발을 해보면 결국 스프링 프레임워크를 만들게 됩니다. (더 정확히는 DI 컨테이너)

---

마지막으로...

가장 중요한건 모든 설계에는 역할과 구현을 분리해야한다!

유연하게 변경이 가능해야 좋은 객체 지향 설계다!

 

다음 섹션부터는 본격적으로 코드 위주로 정리하게 될 것입니다.

그럼 안뇽~~