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

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

solid 란 무엇인가

 ㄴ 클린코드로 유명한 로버트 마틴이 좋은 객체 지향설계의 5가지를 정리를 했는데 

아래와 같이 앞글자만 따서 SOLID 라고 한다 .

 

1. SRP : 단일 책임 원칙 (single resposibility principle)

2. OCP : 개발 -폐쇄 원칙 (open/closed principle)

3. LSP : 리스코프 치환 원칙 ( Liskov substitution Principle)

4. ISP : 인터페이스 분리 원칙 (interface segregation principle)

5. DIP : 의존관계 역전 원칙 ( Dependency inversion principle)

 

 

---

1. SRP : 단일 책임 원칙 (single resposibility principle)

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

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

ex) UI 변경, 객체의 생성과 사용을 분리

 

2. OCP : 개발 -폐쇄 원칙 (open/closed principle)

정말 중요한 원칙이다. 

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 🤔엥.. 이게 무슨말이지?

열러있으나? 닫혀있어야한다..?

 

다형성에 대해 다시 보자.

여기서 확장에 열려있고 변경에 닫혀있다 라는 의미는 다형성의 의미를 생각하면서 이해하면 된다...?...

인터페이스가 자동차 운전방법 이라고 가정한다면 갑자기 변경된다면 위에 k3 , 아반테 든간에 자동차 운전에 있어 영향을 미칠 수 있다...?....😑 그치만 코드 수정..변경...은 해야되지 않을까..?

분명 다형성을 사용했지만 OCP원칙을 지킬 수 없다.

 이 문제를 해결하기위해서는 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다고 한다.😣🤔

<일단 나중에 이 부분에대해 추가 설명한 글을 올려야겠다. 일단 PASS>

 

3. LSP : 리스코프 치환 원칙 ( Liskov substitution Principle)

 

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

 

자동차 인터페이스의 엑셀은 앞으로 가라는 기능이다.

그런데 만약 엑셀을 밟으면 뒤로가게 된다면..리스코프 치환원칙을 위배하게 된다.느리게 가더라도 앞으로 가야한다는 것이 리스코프 치환 원칙이다.

 

4. ISP : 인터페이스 분리 원칙 (interface segregation principle)

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

 

자동차라는 인터페이스가 있다면 ,, 

(1)운전 인터페이스 , (2)정비 인터페이스 로 분리 해보자

 

자동차 인터페이스 는 너무 크기 때문에 위와 같이 분리한다.

그러면 사용자 클라이언트는 (1)운전자 클라이언트 (2) 정비사 클라이언트 로 구분할 수 있다.

 

5. DIP : 의존관계 역전 원칙 ( Dependency inversion principle)

프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. // 의존성 주입은 이 원칙을 따르는 방법중 하나이다.

=> 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻이다.

다시 위 그림을 가지고 설명하자면  운전자는 자동차의 역할에 대해서만 알아야한다는 것이다.

운전자가 k3 , 아반떼에 대해 알 필요가 없다.

 

여기서 MemberService 는 MemberRepository 만 아는 것이 아니라 MemorymemberRepository 까지 아는것이다.

그래서 MemoryMemberRepository를 딴걸로 바꾸려고 할때 코드를 변경해야한다.

🤔 DIP 위반..??   혼란스럽다..😣😣

DIP를 만족하기 위해서는 MemberService  가 MemberRepository 인터페이스에만 의존하도록 클래스를 설계해야하는데..

 

이 해결 방법은  <다음 글에 정리>

 

정리:

- 객체 지향의 핵심은 다형성

- 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.

- 다형성 만으로는 구현 객체를 변경할때 클라이언트 코드도 함께 변경된다.

- 다형성 만으로는 OCP DIP를 지킬 수 없다. ===> 뭔가 더 필요함!!

---

객체 지향 설계와 스프링

옛날에는 개발자들이 좋은 객체 지향 개발을 하기위해 OCP(개발-폐쇄), DIP(의존관게 역전)원칙을 지키면서 개발을 해보니 너무 할일이 많았다.  ===> 그래서 프레임워크로 만들어버렸다.

 

우리가 직접 순수하게 JAVA 로 OCP,DIP 원칙들을 지키면서 개발을 해보면 결국에는 스프링 프레임워크를 만들게 된다.

(==DI 컨테이너)  // 

 

정리

1. 모든설계에 역할과 구현을 분리

2. 앞서 정리한 글에서 자동차, 공연을 비유로 했던것을 떠올려보자.

애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는것이 좋은 객체 지향 설계이다.

3. 이상적으로는 모든 설계에 인터페이스를 부여하자

 

실무 고민

-> 인터페이스를 도입하면 추상화라는 비용이 발생한다. // 추상화가 되면 다시 코드를 들여다 보아야 함.

-> 기능을 확장할 가능성이 없다면,  구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는것도 방법이다.