Spring - Spring의 이해

YUNU·2023년 7월 27일
0

스프링

목록 보기
8/33
post-thumbnail

🌱 Spring


🟦 스프링의 핵심

스프링은 Java 언어 기반의 프레임워크

➡️ Java 언어의 가장 큰 특징은 객체 지향 언어라는 것

➡️ 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크

➡️ ❗좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크


🟦 스프링 부트

  • 스프링을 편리하게 사용할 수 있도록 지원
  • 단독 실행 가능한 스프링 애플리케이션을 쉽게 생성할 수 있음
  • 웹 서버(Tomcat)를 내장하고 있음
  • starter 종속성 제공을 통한 손쉬운 빌드 구성
  • 스프링과 3rd party(외부) 라이브러리 자동 구성
  • 메트릭, 상태 확인, 외부 구성과 같은 프로덕션 준비 기능 제공
  • 관례에 의한 간결한 설정
✅ 스프링 부트는 서버를 내장 (Tomcat)

빌드할 때, 빌드 결과(Jar) WAS 서버(Tomcat)를 포함
➡️ 빌드 배포 단순화

🟦 스프링 생태계

<출처 : https://www.edureka.co/blog/videos/building-web-application-using-spring-framework/ >

🟦 객체 지향 특징

✅ 가장 중요한 것은 다형성!

역할(인터페이스)과 구현(인터페이스를 구현한 클래스, 구현 객체)으로 세상을 구분

➡️ 세상이 단순해지고, 유연해지며 변경도 편리해진다.

클라이언트는 구현 대상의 내부 구조가 변경되어도, 구현 대상 자체를 변경하여도 영향을 받지 않으며 클라이언트는 대상의 역할(인터페이스)만 알면 됨

따라서 객체 설계시에 인터페이스를 먼저 부여하고, 그 역할을 수행하는 구현체를 만든다.

🔹 객체의 협력

홀로 존재하는 객체는 없음

수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가짐

클라이언트 : 요청, 서버: 응답

🔹다형성의 본질

다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경 가능

이름이 같은 오버라이딩, 오버로딩한 메서드 중 해당하는 메서드를 실행시점에 결정하여 실행하는 것처럼

클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있음

❗인터페이스를 수정하지 않도록 안정적으로 잘 설계하는 것이 정말 중요 (예시 - API)

스프링은 다형성을 극대화해서 이용할 수 있게 도와줌


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

  • SRP 단일 책임 원칙
    -> 변경이 있을 때, 파급 효과가 적어야 함 (책임[역할] 분리)

  • OCP 개방-폐쇄 원칙
    -> 확장에는 열려있으나 변경에는 닫혀있어야
    -> 인터페이스의 변경은 No, 구현체의 확장은 OK

    그러나 클라이언트(Service)가 구현 클래스를 직접 선택하는 경우
    구현 객체를 변경하려면 클라이언트 코드를 변경해야 함
    -> 다형성을 사용해도 OCP 원칙을 지킬 수 없음

    예시)
    public class MemberService {
    	MemberRepository mr = new MemoryMemberRepository(); // 기존 코드
    	MemberRepository mr = new JdbcMemberRepository(); //변경하려는 코드
    }
  • LSP 리스코프 치환 원칙
    -> 하위 클래스는 인터페이스의 규약을 지켜야 함

  • ISP 인터페이스 분리 원칙
    -> 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 나음

  • DIP 의존관계 역전 원칙
    -> 클라이언트 코드는 구현 클래스에 의존하지 않고, 인터페이스에 의존해야 함
    -> 역할에 의존해야 한다

    그러나 OCP의 문제 상황으로 든 예시의 경우
    MemberService는 인터페이스에 의존하지만, 동시에 구현 클래스도 의존한다.
    -> DIP 위반

❗ 다형성 만으로는 OCP, DIP를 지킬 수 없음


🟦 DI(Dependency Injection), DI 컨테이너

스프링은 DI, DI 컨테이너로 다형성 + OCP, DIP를 가능하게 지원한다.

➡️ 클라이언트 코드의 변경 없이 기능 확장 가능


❓실무 고민

이상적으로는 모든 설계에 인터페이스를 부여하는 것이 좋음

그러나 인터페이스를 도입하면 추상화라는 비용이 발생함

-> 구현 클래스가 무엇인지 코드를 다시 확인해야 함

따라서 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용,
향후 꼭 필요한 경우에 리팩터링하여 인터페이스를 도입

인프런 스프링 핵심 원리 - 기본편 (김영한) 참조

profile
DDeo99

0개의 댓글