[Spring/기본편] 1. 객체 지향 프로그래밍 및 스프링 개념 정리

목표

• 스프링을 왜 만드는가?
• 이유와 핵심원리
• 스프링 기본 기능 학습
• 스프링 본질 깊은 이해
• 객체 지향 설계에 대한 고민을 할 수 있게 해줌

 

 

서론

2000년대 초반에는 자바 정파 기술에는 EJB(Enterprise Java Beans)가 있었습니다. EJB는 이론, 분산, 트랜잭션 면에서 다 좋았지만, 개발자들이 배우기에 정말 어렵고 복잡할 뿐만아니라 속도도 느렸습니다. 결론적으로 개발자가 사용하기에 단순하고 편하지 않았습니다. 따라서 선배개발자분들이 사용하기 어려워했다고 합니다. EJB에 불편함을 느끼던 다른 개발자들 중 2명이 각각 새로운 오픈소스를 만들었습니다. 2명의 개발자 중 한 명은 SI 개발자였습니다. 이름은 Rod Johnson이였고 Rod Johnson은 EJB를 비판하며 더 단순하고 좋은 방법으로 개발할 수 있다며 책을 통해 공개한 오픈 소스 3만줄이 미래에 Spring이 됩니다. 또 2명의 개발자 중 다른 한 명인 Gavin King은 EJB 엔티티빈 기술을 사용하면서 불편함을 느꼇고, 해당 기술을 더 편리하게 사용할 수있는 Hibernate를 개발합니다. 후에 Hibernate는 JPA 인터페이스의 구현체로 사용됩니다. 현재 JPA시장의 80%는 Hibernate를 사용한다고 합니다. Spring의 시작은 Rod Johnson의 오픈 소스 책을 읽은 Juerhen hoeller(유겐 휠러)와 Yann Caroff(얀 카로프)가 오픈 소스 프로젝트를 제안하며 시작했고, EJB라는 개발 지옥의 겨울을 넘어 개발자들에게 봄이 왔다는 뜻으로 이름을 Spring이라고 짓게 되었다고 합니다.

 

 

스프링 생태계

• 필수
  • 스프링 프레임워크
    • 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
    • 웹 기술 : 스프링 MVC, 스프링 WebFlux
    • 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
    • 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
    • 테스트 : 스프링 기반 테스트 지원
    • 언어 : 코틀린, 그루비
    • 최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용
  • 스프링 부트
    • 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
    • 단독으로 실핼할 수 있는 스프링 애플리케이션을 쉽게 생성
    • Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨 - 옛날에는 빌드 한 후 톰캣서버 특정 위치에다가 빌드한 스프링 프로젝트를 넣고 띄우고 등등 복잡했다고 합니다.
    • 손쉬운 빌드 구성을 위한 starter 종속성 제공 - 라이브러리 하나를 쓸 때 여러개의 라이브러리를 땡겨왔어야 했는데 이를 쉽게 스타터를 통해 쉽게 해줍니다.
    • 스프링과 3rd parth(외부) 라이브러리 자동 구성
    • 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
    • 관례에 의한 간결한 설정 - 스프링 프레임워크가 설정이 힘들었다고 합니다. 이를 보완
• 선택
  • 스프링 데이터
    • RDBMS, NoSQL, mongoDB, Redis 등 기본적인 CRUD(등록, 수정, 삭제, 조회)는 비슷합니다. 이러한 DB를 편리하게 사용할 수 있도록 도와줍니다. 기본적으로 스프링 데이터 JPA를 가장 많이 사용합니다.
  • 스프링 세션
    • 세션 기능을 편리하게 사용할 수 있도록 도와줍니다.
  • 스프링 시큐리티
    • 보완을 도와줍니다.
  • 스프링 Rest Docs
    
    • API문서와 Test를 묶어서 API 문서화를 편리하게 해줍니다.
  • 스프링 배치
    • 실제 천 만명의 데이터를 한번에 업데이트를 해야할 때 실시간으로 하기 어려움이 있다고합니다. 이럴 때 천만 건 중 몇 건씩 돌리고 저장을 반복하는 것을 배치처리라고 합니다. 이러한 처리를 담당하는 곳 입니다.
  • 스프링 클라우드
    • 최근 클라우드 기술에 특화된 기술입니다.

 

 

 

스프링이란 기술은 왜 만들었고 왜 필요한가?

Rod Johnson이 약 3만 줄의 오픈 소스를 만들기 전 EJB를 사용하던 개발자들은 EJB를 상속받고하면서 EJB에 의존적으로 개발을 해야했습니다. 이를통해 객체지향이 가진 좋은 장점들을 다 잃어버리게 됩니다.(이 부분에 대해서는 필자도 어떠한 장점들을 잃어버리게 되는지 정리해야될 것 같습니다.) 따라서 당시 순수한 자바로 돌아가고자 POJO라는 단어도 나오기도 했습니다. 결론적으로 객체지향의 장점들을 잘 살려내기 위해 스프링이란 기술이 등장하게 되었습니다.

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

 

 

 

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

객체 지향 프로그래밍에는 추상화, 상속화, 다형성, 캡슐화로 총 4가지의 특징이 있습니다. 볼 때마다 설명하기 어려운 것 같아 이번에 확실하게 정리하고자 합니다. 객체 지향 프로그래밍의 정의는 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위인 객체 들의 모임으로 파악하고자 하는 것 입니다. 각각의 객체는 메시지를 주고받고 데이터를 처리할 수 있습니다. 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용됩니다.

 

 

 

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

유연하고 변경이 용이하다가 잘 와닿지 않을 거라고 생각합니다. 유연하고 변경이 용이하다는 것은 레고 블럭을 조립하듯이 또는 키보드, 마우스를 갈아 끼우듯이 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 것을 의미합니다. 이것을 가능하게 해주는 것이 객체 지향 프로그래밍의 특징 중 하나인 다형성입니다.

 

 

 

다형성

실세계와 객체 지향을 1:1로 매칭할 순 없지만 이해하기는 좋기때문에 실세계를 비유해서 이해시켜보도록 하겠습니다. 역할과 해당 역할의 구현으로 세상을 나눠서 생각해봅시다. 해당 역할을 운전자와 자동차로 비유해서 다형성에 대해서 이해해보도록 하겠습니다.

운전자라는 역할이 있고 자동차라는 역할이 있습니다. 여기서 자동차 역할을 할 수 있는 구현체는 K3, 아반떼, 테슬라 모델3가 있습니다. 운전자는 K3를 타다가 아반떼로 차가 바뀌어도 운전을 할 수 있습니다. 그 이유는 자동차 역할의 구현만 바뀌었고 바뀐 자동차의 역할은 운전자에게 영향을 끼치지 않기 때문입니다. 이 점이 유연하고 변경이 용이하다고 하는 것 입니다. 쉽게 말해 운전자, 자동차 역할이 있을 때, 자동차가 어떤 것으로 바뀌던 간에 운전자는 운전을 할 수 있다는 것 입니다. 이 것을 인터페이스라는 개념으로 풀어서 설명하면 운전자가 있고 자동차 역할인 인터페이스가 있을 때 자동차 역할의 구현체를 어떤 자동차로 바꾸든 운전자는 자동차 역할이라는 인터페이스를 가지고 운전하기 때문에 운전이 가능하다는 것 입니다. 여기서 가장 중요한 것은 구현체인 새로운 자동차가 나와도 운전자는 바꾸지 않아도 된다는 것 입니다. 

 

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

장점으로는 아래 4가지가 있습니다.

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

여기서 핵심은 구현체보단 역할인 인터페이스에 있습니다.

 

 

이제 객체 지향 프로그래밍에서의 실제 다형성의 특성으로 작성된 프로그램의 예시를 보겠습니다. 

위의 사진을 보며 오버라이딩을 떠올려봅시다. 오버라이딩에 대해 간략하게 설명하자면 만약 MemberService가 interface인 MemberRepository에 있는 save()를 호출할 때 실제 호출되는 save()는 MemoryMemberRepository와 JdbcMemberRepository중 들어와 있는 객체에 있는 save()가 호출되는 것 입니다. 인터페이스로 구현한 객체를 실행 시점에 유연하게 변경할 수 있는 것이 객체 지향 프로그래밍의 장점입니다. 

 

이미지로 설명한 예시

위의 이미지가 코드로 구현된 경우

다형성을 정리하자면 다형성의 본질은 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다는 점입니다. 이것을 클라이언트 시점에서 보면 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다고도 볼 수 있습니다.

 

 

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

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

• 단일 책임 원칙
  • 한 클래스는 하나의 책임만 가져야 합니다. 중요한 기준은 변경입니다. 즉, 하나를 변경할 때 최대한 하나만 변경하면 되도록 로직을 구현하면 됩니다.
• 개방-폐쇄 원칙
  • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 합니다. 이게 무슨 모순인가 싶습니다. 이때 다형성을 생각해봅시다. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 것을 보면 기존 코드를 변경하지 않고 새로운 클래스를 통해 확장합니다. 하지만 위의 다형성으로 예시를 들면 구현 객체를 변경하는 경우 클라이언트 코드를 변경하기 때문에 개방-폐쇄 원칙을 지킬 수 없습니다. 이 문제를 해결하기 위해서는 별도의 조립을 해주는 설정자가 필요합니다. spring에서는 개발-폐쇄 원칙을 지키기위해 spring 컨테이너를 통해 해결해 준다고합니다. (현재는 이해가 잘 되지 않습니다.)
  • ex) 위의 코드로 예시를 들면
    MemberRepository member Repository = new MemoryMemberRepository();
    에서 구현체를 변경하면
    MemberRepository member Repository = new JdbcMemberRepository();
    MemoryMemberRepository 를 JdbcMemberRepository로 변경을 해야 합니다. 이렇게 때문에 개방-폐쇄 원칙을 어긴다고 볼 수 있습니다.
• 리스코프 치환 원칙
  • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 합니다. 이를 간단하게 얘기하면 어떤 인터페이스가 있고, 구현체가 있다고 가정합니다. 자동차를 예로들면 자동차 인터페이스에 엑셀(앞으로 빠르게 가는 기능)이 있습니다. 엑셀의 본질적인 정확한 기능은 앞으로 빠르게 가는 기능입니다. 하지만 구현체인 K3가 엑셀의 기능을 멈추는 기능으로 만들어 버릴경우 리스코프 치환 원칙을 위배했다는 것이라고 보면됩니다. 이처럼 리스코프 치환 원칙은 인터페이스에서 정의한 본질적인 기능을 구현체에서 깨뜨리지 않는 것을 의미합니다.
• 인터페이스 분리 원칙
  • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다를 말합니다. 
  • 예를 들어, 자동차 인터페이스를 운전 인터페이스, 정비 인터페이스로 분리합니다.
  • 이에 따라, 운전자 클라이언트, 정비사 클라이언트로 분리할 수 있게 됩니다.
  • 이렇게 분리하는 경우 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않기 때문에 인터페이스가 보다 명확해지고, 대체 가능성도 높아지게 됩니다.
• 의존관계 역전 원칙
  • 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나 입니다. 쉽게 이야기하면 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻입니다. 앞에서 이야기한 역할에 의존하게 해야 한다는 것과 같습니다. 위에 말한 운전자와 자동차로 다시 예시를 들면 운전자는 자동차의 역할만 알면되지 구현체에 대해서는 몰라도 되게 해야한다는 것 입니다. 즉, 운전자는 자동차라는 역할에 의존하게 됩니다. 이를 통해 얻는 장점은 유연하게 구현체를 변경할 수 있습니다.

하지만, 다형성 만으로는 개방-폐쇄, 의존관계 역전 원칙을 지킬 수 없습니다. 

그 이유는 다형성 만으로는 위의 사진처럼 인터페이스인 MemberRepository 뿐만아니라 구현체인 MemoryMemberRepository도 클라이언트에서 알아야하기 때문입니다. 

 

 

 

객체 지향 설계와 스프링 

스프링은 다음 기술로 다형성 + 개방-폐쇄, 의존관계 역전 원칙을 가능하게 지원합니다.

• DI(Dependency Injection) : 의존 관계, 의존성 주입
• DI 컨테이너 제공

실제로 순수하게 자바로 개방-폐쇄, 의존관계 역전 원칙들을 지키면서 개발을 하다보면, 결국 스프링 프레임워크를 만들게 된다고합니다. (정확히는 DI 컨테이너) 이 때문에 스프링을 프레임워크로 만들었다고 합니다. 즉, SOLID 원칙 중 다형성으로 해결되지 않는 개방-폐쇄, 의존관계 역전 원칙 2가지를 지키기 위해 프레임워크를 만들었다고 보면 됩니다.

 

 

 

 

 

 

 

용어 정리

JPA - ORM기술 

ORM기술 - Java 객체를 DB에 편하게 저장하고 꺼내는 기술 (쿼리를 사용하지 않음.)

POJO(Plan Old Java Object) - 오래된 방식의 간단한 자바 오브젝트

 

 

책 추천 (김영한님의 추천입니다.)

객체지향 책 추천 : 객체지향의 사실과 오해 (주니어, 시니어 모두 도움 될 책)

스프링 책 추천 : 토비의 스프링 (필수 - 어느정도 공부한 뒤 책을 읽으면서 정리하면 분명 많은 도움이 된다고 합니다.)

JPA 책 추천 : 자바 ORM 표준 JPA 프로그래밍 (김영한님의 앞PPL...)

 

 

 

 

출처

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