스프링 핵심 원리-기본편 섹션 1. 객체 지향 설계와 스프링 정리

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

SRP 단일 책임 원칙

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

중요한건 변경이다. 변경이 있을때 파급효과가 적으면 단일 책임 원칙을 잘 따른것

 

OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야한다 => 다형성 활용

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

 

아래는 멤버서비스에서 메모리멤버리포지토리를 Jdbc 멤버리포지토리로 갈아끼우려고 하는 상황이다.

두번째 코드를 보면 다형성만 사용하면 OCP 원칙을 지킬 수 없다. 

구현 객체를 변경하려면 클라이언트 코드를 변경해야하는 문제가 생긴다.

LSP 리스코프 치환 원칙

차를 만든다고 했을때 인터페이스에서 엑셀 기능을 속도를 올리는 것으로 규정을 했다면 구현체에서 엑셀을 속도 마이너스 10 이런식으로 구현할 수 없다.

 

ISP 인터페이스 분리 원칙

적절하게 인터페이스를 나누는 것이 좋다

 

DIP 의존관계 역전 원칙

멤버서비스가 메모리 리포지토리 인터페이스만 바라보고 메모리멤버 리포지토리나 JDBC 멤버 리포지토리에 대해서는 몰라야한다

 

그림으로 설명하자면 운전자가 자동차 역할에 대해 알고 있어야지 K3에 대해 잘 알고 있으면 안된다

 

역할과 구현을 철저하게 분리하고 시스템을 언제든지 갈아끼울 수 있게 설계

 

위의 코드 문제점: 멤버서비스 new 를 보면 메모리 멤버 리포지토리에도 의존하고 있다. 의존한다는건 저 코드를 안다는 뜻

즉 멤버서비스는 메모리리포지토리와 메모리멤버리포지토리를 안다는 뜻이다. 그래서 메모리 멤버리포지토리를 변경하려고 할 때 아래와 같이 코드를 변경해야하는 문제가 발생한다 (DIP 위반)

 

객체 지향 설계와 스프링

인페이스를 모두 도입하면 좋지만 추상화라는 비용이 발생한다. 코드를 인터페이스를 열고 구현체들도 열고 이래야하는 단점이 있음

 

미래에 기능을 확장할 가능성이 있다 : 처음부터 인터페이스 만들기

미래에 기능을 확장할 가능성이 없다 : 구체 클래스를 직접 사용하고 향후 꼭 필요할때 리팩터링해서 인터페이스 도입