객체 지향 설계(OOP)와 스프링(Spring)

Spring 프레임워크

- 핵심 기술 : 스프링 DI 컨테이너, AOP, 기타

- 웹 기술 : 스프링 MVC

- 데이터 접근 기술 : 트랜잭션, JDBC, ORM 등

 

Spring Boot (스프링 부트)

- 스프링을 편리하게 사용할 수 있도록 지원, 그냥 이거 쓰면 된다

- 스프링 어플리케이션 쉽게 생성, Tomcat 같은 웹 서버 따로 설정할 필요 없음

- 손쉬운 빌드 구성을 위한 starter 종속성 제공 (라이브러리)

 

스프링의 진짜 핵심

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

- Java는? 객체 지향 프로그래밍(Object-Oriented Programming) 언어

- 즉, 스프링은 좋은 객체 지향 프로그래밍을 도와주는 프레임워크

 

객체 지향 프로그래밍

- 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들어 ~

- 유연하고 변경이 용이한 것은 객체 지향 프로그래밍에서 다형성(Polymorphism)을 가리킨다.

 

다형성(Polymorphism)

- 역할과 구현으로 세상을 구분

- 운전자(클라이언트), 자동차(역할), K3, 아반떼, 테슬라 모델3(구현)

- 역할과 구현을 분리하면 단순해지고, 유연해지며 변경도 편리해진다.

장점

1. 클라이언트는 역할(인터페이스)만 알면 된다.

2. 구현 대상의 내부 구조를 몰라도 된다.

3. 구현 대상의 내부 구조가 변경되어도 영향 X

4. 구현 대상 자체를 변경해도 영향 X

 

자바 언어의 다형성

- Overriding(오버라이딩)

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

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

- 위의 코드에서 MemberRepository는 역할, MemoryMemberRepository와 JdbcMemberRepository는 구현이다.

 

다형성의 본질

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

 

- 역할과 구현을 분리하는 것은 매우 중요 -> 확장 가능한 설계

- 인터페이스를 안정적으로 잘 설계하는 것이 중요

 

SOLID 원칙

SRP(Single Responsibility Principle) 단일 책임 원칙

 

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

- 하나의 책임? 기준은 변경, 변경이 적을 때 파급 효과가 적으면 SRP 원칙을 잘 따른 것

 

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

- 확장에는 OPEN, 변경에는 CLOSED

- 다형성 활용

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

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

문제점

- 위의 코드를 보면 기존 코드를 변경하였다 MemoryMemberRepository -> JdbcMemberRepository

- 구현 객체를 변경하려면 클라이언트 코드를 변경

- 다형성은 지켰지만 OCP 원칙 위반

스프링이 이를 해결해준다!

 

LSP(Liskov Substitution Principle) 리스코프 교환 법칙

- 다형성에서 하위클래스는 인터페이스 규약을 지켜야 한다

- 자동차 인터페이스의 엑셀은 앞으로 가는 것인데 구현체가 뒤로 가면? LSP 위반

 

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

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

- 자동차 -> 운전, 정비로 분리

- 인터페이스 분리하면 명확해지고, 대체 가능성이 높아진다

 

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

- 추상화에 의존해야지, 구체화에 의존하면 안된다

- 구현 클래스 말고, 인터페이스에 의존하라는 뜻, 역할에 의존

- 위의 코드르 보면 MemberService 클라이언트가 MemoryMemberRepository에도 의존 -> DIP 위반

 

스프링은 다형성 + OCP, DIP를 가능하게 지원

 

 

출처: 스프링 핵심 기본 원리편