2)좋은 객체 지향설계의 5가지 원칙(SOLID), 객체지향 설계와 스프링

SRP (단일 책임 원칙 , Single responsibility principle)

하나의 책임이라는게 정하기 모호하다. 하나의 책임의 중요한 기준은 변경이다.

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

ex)만약 ui를 고치려고하는데 sql문부터 시작해서 다른 변경이 많이 생길때 -> 단일 책임 원칙을 잘 따르지 못했다.

 

OCP 개방-폐쇄 원칙 

가장중요한 원칙

리포지토리를 메모리리포지토리,jpa리포지토리 등등으로 바꿔도 기존의 코드는 바꾸지않았던점, (새로 리포지토리 구현체만 생성했을뿐 기존 코드는 건들지않음.)

이전 게시글에서 운전자 예시중 자동차가 바뀌어도 운전자는 운전이 가능했다는점

이런 다형성의 예시로 설명이 가능하다.

메모리리포지토리에서 jdbc리포지토리로 바꾸려는데 멤버서비스의 코드변경이 필요하다 -> ocp원칙을 지킬 수 없다 어떻게해야하나?

클라이언트=멤버서비스

어떻게해결? -> 별도의 조립을 해주는 설정자가 필요하다 (누가? -> 스프링 컨테이너)

OCP원칙을 지키기위해 DI도 Ioc도 필요한것이다.

이후 게시글에 코드로 짜서 해결하는것을 확인해볼것이다.

LSP 리스코프 치환 원칙

 ISP 인터페이스 분리 원칙

자동차 인터페이스가 운전,정비 인터페이스로 분리되었다면

나중에 정비 인터페이스의 수정이 필요할때 정비인터페이스를 구현하는 클래스들만 수정하면되므로 

코드의 변경점이 줄어들게 된다.

+ 인터페이스가 명확해지고 대체 가능성이 높아진다.

 

DIP 의존관계 역전 원칙

쉽게말해 클라이언트가 구현클래스를 바라보지않고 , 인터페이스를 바라보라는 뜻이다 ( 인터페이스를 의존하라)

이전 강의에서 멤버서비스가 메모리리포지토리 인터페이스를 의존했던것처럼

멤버 서비스가 멤버리포지토리를 필드에 가지고있다. 그리고 new로 메모리멤버리포지토리(구현체)를 할당했다.

그러면 멤버서비스는 메모리멤버리포지토리에도 의존하고있다는것이다.

즉 멤버서비스는 인터페이스와 구현클래스 둘다 의존하고 있다는것 ( 위에 코드로 보면)

[의존한다는것 == 저 코드에 대해 알기만 하면 의존한다는것]

멤버서비스클라이언트가 구현 클래스를 직접 선택하고있는 상황 -> DIP 의존관계역전원칙 위반

 

어떻게 해결? -> 뒤에 강의에서 설명

다시 스프링으로

DI 컨테이너 -> 자바의 객체들을 컨테이너에 넣어놓고, 의존관계를 서로 넣어주고 주입해주는걸 제공해주는 컨테이너

이전 강의에서도 리포지토리가 계속 바뀌어도 됬던이유는 

인터페이스로 어떤 기능이 필요한지 설계를 해놓고 들어갔기 때문이다. (인터페이스를 먼저 설계하라)

인터페이스를 이용하면 어떤 구현체를 썼는지 찾아보는 비용이 든다.

기능을 확장할 가능성이 없다면 구현체 클래스를 직접사용하고, 향후 필요할떄 리팩토리링해서 인터페이스를 도입하는 방법도 있다.  [애초에 필요할거 같다면 인터페이스를 도입해서 시작한다.]

 

 

다음강의부터 예시코드를 만들면서 학습한다.