녕의 학습 기록

[Spring 기본] 객체 지향 설계와 스프링 (2) 본문

Dev/Spring

[Spring 기본] 객체 지향 설계와 스프링 (2)

kjyyjk 2022. 10. 26. 01:01

학습 내용 

 

객체 지향 설계 원칙 SOLID /  스프링 프레임 워크의 필요성


* SOLID

 

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

 

- SRP : 단일 책임 원칙

- OCP : 개방 - 폐쇄 원칙

- LSP : 리스코프 치환 원칙

- ISP : 인터페이스 분리 원칙

- DIP : 의존관계 역전 원칙

 

* SRP 단일 책임 원칙

 

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

 

그 기준은 ? 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다

 

하나의 책임 이라는 범위를 적절하게 잘 조절하는게 객체 지향 설계의 묘미

 

* OCP 개방-폐쇄 원칙

 

확장에는 열려있고 변경에는 닫혀 있어야한다.

 

다형성을 활용해 보면 (역할과 구현의 분리를 생각)

 

public class Driving{
	private Car car = new K3Car();
}
public class Driving{
// private Car car = new K3Car();
	private Car car = new TeslaCar();	
}

다형성 잘 활용했다. 클라이언트에 영향 없이 구현 변경

 

문제점 : 구현 객체를 변경하기 위해 코드를 변경했다. ( OCP 위배 )

 

* LSP 리스코프 치환 원칙

 

단순히 컴파일 성공 여부를 떠나서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.

 

다형성을 위한 원칙이기도 하다

 

ex ) 자동차 인터페이스에서는 악셀 밟으면 앞으로 가는 기능

만약 악셀 밟았을 때 뒤로 가는 자동차를 구현하면 ? 컴파일은 되겠지만, LSP 위배이다.

 

 

* ISP 인터페이스 분리 원칙

 

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

 

ex)

자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스

사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트

 

* DIP 의존관계 역전 원칙

 

구현체에 의존하지 않고 역할에 의존해야 한다.

 

즉, 인터페이스에 의존해야 한다.

 

만약 구현체에 의존하게 되면 변경이 어려워짐

 

문제점 : 

public class Driving{
	private Car car = new K3Car();
}

OCP 에서 보면 인터페이스에 의존하면서도 구현 클래스에도 의존한다. ( DIP 위반 )

(의존한다 == 저 코드를 알고 있다)

 

* 스프링 프레임 워크

 

다형성 만으로는 OCP, DIP를 지킬 수 없고 이를 위해서는 뭔가 더 필요하다

 

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

 

- DI(Dependency Injection) : 의존관계, 의존성 주입

- DI 컨테이너 : 자바의 객체들을 컨테이너에 넣어두고 이 안에서 의존 관계를 서로 연결, 주입

 

= > 클라이언트 코드 변경 없이 확장이 가능하다

 

순수하게 자바로 OCP , DIP 원칙을 지키며 개발하면 결국은 스프링으로 돌아오게 된다.

 

즉, 스프링을 왜 만들었고 왜 사용하는 지에 대해 윗 문장으로 어느정도 답변이 된다.

 

 


 다음 학습 내용 

 

스프링 프레임 워크를 왜 만들게 됐는지 직접 코드를 작성해 보며 이해

 

 

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

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com