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

OCP, DIP가 가장 중요

 

 

 

 

1. SRP

 

- 책임이란 것이 실무에서는 좀 애매하다.

( 중요한 판단의 기준은 변경이다. 파급효과가 적으면 Good ) 변경=바꿔야되는 코드양.

- ex) 코드 하나에 3만줄 ...

 

 

 

 

 

2. OCP

 

이 사진을 다시 보면 이해가 쉽다. 자동차 역할의 인터페이스는 여러 종류의 차로 확장 가능하지만 아무리 확장되더라도 운전자 역할의 코드를 바꿀 필요가 없다.

이렇게 코드를 바꿔야함 => OCP 위반!!!위반!!!위반!!!위반!!!!

다형성을 사용하려하면 OCP 원칙을 지킬 수 없다. !! -> 문제를 어떻게 해결 할 까? -> 스프링의 DI를 받자!!!!!!!!!!!!!

 

 

 

3. LSP

 

업캐스팅이 되야한다.? 정도로 이해함.

기능적으로 보장되어야함. ( 엑셀은 뒤로가게 구현하면 LSP 위반 -> 엑셀의 기능이 보장 되어야함. )

 

 

 

 

 

 

4. ISP

 

- 자동차 인터페이스를 운전 인터페이스, 정비 인터페이스로 분리

- 정비와 관련된 문제가 생겨서 기능을 바꿔야하면 정비 인터페이스 와 정비 구현체만 바꾸면 되지 운전 인터페이스를 건드릴일이 없다.

- 적당한 크기로 잘 쪼개는 게 중요하다.

- 덩어리가 작으면 구현 할 기능이 적어진다.

- 스프링 코드 까보면 철저히 분리되어 있다.

 

 

 

 

5. DIP

 

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

클라이언트코드가 구현클래스를 바라보지 말고 인터페이스만 바라봐라!!!

 

운전자는 자동차 역할에 대해서만 알아야지 내가 K3에 관해서만 디테일하게 알면 안됨. 

 

시스템을 언제든지 갈아낄 수 있게 설계해야함.

 

의존한다는 것 = 내가 저 코드를 안다는 것 ( 알기만 하면 다 의존한다고 표현함 )

 

DIP 위반!!!!!!!!!!!!!!!!!!!!!!!!!!

이 사진에서 MemberService 클래스는 memberRepository 인터페이스만 아는게 아니라 MemoryMemberRepository도 알고 있다. 그래서 MemoryMemberRepository를 바꾸려 할 때 MemberService의 코드도 변경해야한다.

 

 

 

 

 

 

# 정리

 

다형성 만으로는 OCP, DIP를 지킬 수 없다. 

당연하지!!! 자바코드만으로 구현체를 안 넣어주면 당연히 NullPointerExeption 터지지!!!

 

==> 뭔가 가 더 필요하다

 

 

# 인프런 김영한님의 강의를 수강한 후 작성한 글입니다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard