Spring 객체지향

2024. 1. 17. 23:16· Spring
목차
  1. Spring 과 객체지향
  2. 1. Spring 이란?
  3. 2. 객체 지향
  4. 3. SOLID
반응형

Spring 과 객체지향

국내 백엔드 생태계에서 빠질 수 없는 것이 바로 Java Spring 이다.

Java는 프로그래밍 언어이고 Spring이 프레임워크 라는건 안다.

그럼 사람들은 왜 Spring을 쓰는지 어떤 장점이 있는지 알아보려고 한다.

 

1. Spring 이란?

Spring 이란 뭘까, 스프링은 프레임워크다.

 

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

<Spring 프레임워크 표>

나는 기초 강의를 수강하면서 스프링 찍먹을 했고 이때는 Spring Boot를 사용했다.

 

* Spring Boot

스프링을 쉽게 사용하게 해주는 도구라고 생각
최근에는 Default로 사용하는데 스프링의 고질적 문제인 설정 문제를 해결해주기 때문이다.

• 단독으로 실행 수 있는 스프링 애플리케이션 쉽게 생성
• Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버 설치 X
• 손쉬운 비륻 구성을 위한 스타터를 자체 제공
• 스프링과 3rd Party(외부) 라이브러리를 자동 구성
• 메트릭, 상태확인 등 프로덕션 준비 기능 제공
• 관례에 의한 간결한 설정

핵심 장점들이 존재한다.

 

Spring 이라는 것은 문맥에 따라서 조금 다르게 해석되지만 일반적으로는 세가지 경우이다.

  • 스프링 DI 컨테이너 기술
  • 스프링 프레임워크
  • 스프링 생태계 전체

그럼 Spring은 왜 쓰는 걸까

스프링은 기본적으로 자바 언어 기반의 프레임워크이다.

자바는 대표적인 객체지향 언어

객체지향 언어이기에 가지는 여러 유용한 특성들이 존재하고 스프링은 이런 강력한 특성을 살려내는 프레임 워크

즉 객체지향 개발을 도와주는 프레임워크

 

이제 객체지향 언어가 가지는 강력한 특성이 뭔지 알아보고 한번 적용해보자

2. 객체 지향

◼ OOP( Object-Oriented Programming)

직역하자면 객체 지향 프로그래밍 이라는 의미를 가진다.

컴퓨터 프로그램을 명령어의 목록이 아닌 독립된 단위의 객체들의 모임으로 파악하는 것

객체 사이에서 메세지를 주고 받아서 데이터 처리를 가능하게 한다.

👉 객체간의 소통방식이기 때문에 유연하고 변경이 쉽다

◼ 다형성

객체 지향 언어가 가지는 가장 큰 특징 중에 하나이다.

다형성을 이해하기 위해서 세상을 역할과 구현으로 분리해보자

 

역할과 구현, 쉽게 자동차를 생각해보자

자동차라는 역할이 있고 구현된 결과들에 K5, G80, 벤츠 등등 여러 자동차들이 있다.

즉 구현체 K5가 G80으로 바뀌어도 자동차라는 역할 수행함에 있어서 문제가 없다.

 

객체 지향 개발의 개념으로 가보자

자동차라는 인터페이스를 구현하고 그 구현체를 선택했기에 가능한 일이다.

자동차 인터페이스 라는 것이 운전을 하기 위해 필요한 핵심 기능이 모두 동일하기 때문에 다른 자동차 구현체로 무한하게 확장 가능하다.

 

 서비스 차원에서 본다면 클라이언트에는 영향을 주지 않고 변경이 가능🔧

역할과 구현 분리(자동차ver)

추가 예시를 생각해보자

로미오와 줄리엣 이라는 연극이 있다.

로미오, 줄리엣은 각각 배역 즉 역할이다. 이 배역을 연기하는 배우는 유명 배우일수도 무명 배우일수도 있다.

그리고 로미오가 유명배우 A라도 줄리엣은 무명배우 B일수 있는 것이다.

즉 구현체가 본인의 역할만 수행하도 서로가 서로에게 영향을 주지 않는다.

추가 예를 들면 A라는 프로그램에서 정렬이라는 인터페이스를 만들었고 이 정렬 객체를 사용하는데
이때 정렬이 버블이든, 퀵소트이든 상관이 없다. 정렬을 사용하는 다른 역할에서는!

 

역할/구현 분리 장점

  1. 클라이언트는 대상의 역할(인터페이스)만 알면 OK
  2. 클라이언트는 구현 대상 내부 몰라도 OK
  3. 클라이언트가 내부 구조 변경 OK
  4. 클라이언트는 구현 대상 자체 변경에 영향 X

인터페이스를 만들고 이를 구현체를 통해서 사용하는 것은

Overriding으로 다형성을 구현한다.

오버라이딩된 메서드가 실제로 실행되고 , 다형성으로 인터페이스를 구현한 객체를 실행 시점에서 변경 가능

클래스 상속에서도 오버라이딩 가능

클라이언트(멤버 서비스) ----요청-----> 멤버 리포지토리 <-----실제 응답-----(메모리 리포지토리 등등)

◼ 다형성의 본질

인터페이스를 구현한 객체 인스턴스를 실행 시점에 변경

❗협력이라는 객체 사이의 관계에 유의

 

클라이언트를 변경하지 않고 서버의 구현 기능을 변경할 수 있다는 것!!

인터페이스를 안정적으로 설계하는 것이 중요한 것이다.

인터페이스가 바뀌면 클라이언트도 결국 수정해야 하기 때문에

 

Spring은 이런 객체 지향의 다형성을 극대화 시켜주는 프레임워크

IoC, DI 를 통해서 다형성을 극대화 하는데 이는 SOLID를 통해서 조금 더 상세하게 알아보자

 

3. SOLID

좋은 객체 지향 설계의 5가지 원칙이다.

 

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

# SRP 단일 책임 원칙

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

하나의 책임이라 사실 조금 모호한 정의이다.

책임의 크기는 다양하기 때문이다.

그럼 여기서 책임이란 기준은 변경을 의미한다.

 

변경이 있을때 파급 효과가 최소화 되면 이는 단일 책임 원칙을 잘 준수한 것이다

 

# OCP 개방-폐쇠 원칙

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

확정하려면 기존 코드를 수정해야 하는데 어떻게 변경에는 닫혀 있는거지 라고 생각할 수 있다.

역할과 구현 분리(자동차ver)

이 그림을 다시 가져와보자

구현체가 바뀌어도 자동차의 역할은 동일하다.

즉 구현체가 바뀌는 확장에는 열려있지만 자동차라는 역할에 변경에는 닫혀있는 것이다.

인터페이스를 구현한 새로운 클래스는 만들어서 기능 구현 OK

구현체가 하는 역할 자체는 유지

 

👉 다형성 자체를 의미하는 원칙

 

어떤 서비스를 개발할때 저장소를 메모리저장소, MySQL 기반 저장소를 쓸지, PostgreSQL 기반 저장소를 쓸지 모른다는 가정에서 저장소의 역할을 만들고 이후 사용자 요구에 따라 구현 객체를 선택할 것이다.

근데 구현 객체를 생성하고 쓰는 과정에서 단순하게 new를 통해서 인스턴스 생성을 하면 문제가 발생한다.

 

OCP 위배가 발생한다.

이를 추후에 어떤 방법을 통해서 해결할 것인데 이는 다음 포스팅에서 알아볼 것이다.

OCP 위배가 발생되는 문제를 해결하는 객체 생성 및 조립을 진행하는 설정자가 필요하고 이를 Spring 컨테이너가 수행 예정

 

 

#  LSP 리스코프 치환 원칙

프로그램 객체는 프로그램의 정확성을 깨지 않고 하위 타입의 인스턴스로 변경 가능
하위 클래스는 인터페이스 규약을 지켜야한다는 것
다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하기 위함

 

ex) 자동차 엑셀이 앞으로 가는거지 뒤로 가는 엑셀을 만들면 안되는 것 (컴파일 유무의 문제가 아니다)

 

#  ISP 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나 보다 낫다

 

예시를 통해서 알아보자
자동차 인터페이스, 사용자 인터페이스 두개 보다는 각각 운전 인터페이스, 정비 인터페이스로 분리하는 것이 유지 보수 면에서도 좋은 것이다.
사용자 인터페이스도 운전사, 정비사로 나누는 것이 더 좋다. 즉 이렇게 나눔으로 서로의 클라이언트들에 영향을 주지 않는다.

 

#  DIP 의존관계 역전 원칙

프로그래머는 추상화에 의존해야하며 구체화에 의존하면 안된다.
구현 클래스가 아니라 인터페이스에 의존해야한다.

 

즉 구현체가 아니라 역할에 의존하게 해야 한다.

자동차라는 역할이 존재할때 구현체는 다양한 차종이 되겠다.

 

벤츠라는 구현체에 지나치게 의존해서 소나타에서는 사용할 수 없는 메소드가 지나치게 많아지면 이는 문제가 된다.

인터페이스에 의존해야 여러 구현체에서 사용할 수 있는 것이다.

자동차는 엑셀, 브레이크, 파킹 등 기본 기능이 있어야 하는데 벤츠라는 구현체에 의존해서 자율주행, 엉뜨 등 이런 구현체에 집중된 기능으로 이루어지면 안된다.

반응형

'Spring' 카테고리의 다른 글

Spring MVC 패턴 - Servlet  (0) 2024.03.06
Spring 빈 생명주기  (0) 2024.02.15
Spring 의존관계 자동 주입  (4) 2024.02.09
Spring 컴포넌트 스캔  (0) 2024.02.09
Spring과 싱글톤  (1) 2024.02.07
  1. Spring 과 객체지향
  2. 1. Spring 이란?
  3. 2. 객체 지향
  4. 3. SOLID
'Spring' 카테고리의 다른 글
  • Spring 빈 생명주기
  • Spring 의존관계 자동 주입
  • Spring 컴포넌트 스캔
  • Spring과 싱글톤
김도도새
김도도새
1년자 주니어 개발자의 좋은 백엔드 개발자로 걸음을 기록하는 공간
반응형
김도도새
Stacking Devlop
김도도새
전체
오늘
어제
  • 분류 전체보기 (48)
    • 회고 (0)
    • Spring (13)
    • Java (3)
    • 잡동사니 (0)
    • 도서 (0)
    • 웹 Basic (5)
    • 개인프로젝트 (0)
    • 에러모음 (2)
    • 개발회고록 (0)
    • 알고리즘 (5)
    • Git (1)
    • 디자인패턴 (2)
    • FrontEnd (11)
    • JPA (3)
    • Build Tool (1)
    • DB (0)
    • 운영체제 (0)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

인기 글

태그

최근 댓글

최근 글

hELLO · Designed By 정상우.v4.2.2
김도도새
Spring 객체지향
상단으로

티스토리툴바

개인정보

  • 티스토리 홈
  • 포럼
  • 로그인

단축키

내 블로그

내 블로그 - 관리자 홈 전환
Q
Q
새 글 쓰기
W
W

블로그 게시글

글 수정 (권한 있는 경우)
E
E
댓글 영역으로 이동
C
C

모든 영역

이 페이지의 URL 복사
S
S
맨 위로 이동
T
T
티스토리 홈 이동
H
H
단축키 안내
Shift + /
⇧ + /

* 단축키는 한글/영문 대소문자로 이용 가능하며, 티스토리 기본 도메인에서만 동작합니다.