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

안녕하세요? 주니하랑 입니다.

오늘은 Spring의 SOLID에 대해서 공부 해 보도록 하는 것이에요.

이 내용은 인프런 - 김영한 강사님의 스프링 핵심 원리를 공부하면서 정리 하였습니다.

 

📋 목차

---

01. [Spring] 스프링 핵심 원리
02. [Spring] 좋은 객체 지향 설계의 5가지 원칙 (SOLID)
03. [Spring] 객체 지향 설계와 스프링   
04. [Spring] OCP와 DIP 고려하기
05. [Spring] 객체 지향 원리 적용 - 새로운 할인 정책 개발
06. [Spring] AppConfig 리팩터링    
07. [Spring] Ioc, DI Container  
08. [Spring] 스프링 컨테이너 생성  
09. [Spring] 싱글톤 컨테이너  
10. [Spring] Component Scan And Auto wired Start
11. [Spring] 의존관계 주입 방법    
12. [Spring] Bean Life Cycle Call Back
13. [Spring] Bean Scope

 

 

 

---

 

 

 

📌 SOLID란?

---

    📍Clean Code로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 제시

1. SRP (Single Responsibility Principle) : 단일 책임 원칙
2. OCP (Open/Closed Principle) : 개방 - 폐쇄 원칙
3. LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
4. ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
5. DIP (Dependency Inversion Principle) : 의존관계 역전 원칙 

 

 

 

         👉 SRP (Single Responsibility Principle) : 단일 책임 원칙

1. 한 개의 Class는 하나의 책임만 가져야 한다.
   하지만, 하나의 책임이라는 것이 매우 모호하다.
   • 이것은 클 수도 있고, 작을 수도 있다.
   • 문맥과 상황에 따라 달라진다.
2. 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따랐다고 본다.
   • 예:) UI 변경, 객체의 생성과 사용을 분리
   • Layer를 나누는 이유도 단일 책임 원칙을 지키기 위함

 

반응형

 

         👉 OCP (Open/Closed Principle) : 개방 - 폐쇄 원칙 (매우 중요)

1. Software 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
   [Spring] 스프링 핵심 원리에 작성해 둔 자동차가 K3에서 테슬라로 운전자가 차를 새로 사더라도 운전자는 그냥 운전할 수 있다. 
2. 확장을 하는데, 어떻게 코드를 변경하지 않을 수가 있을까?
3. 다형성을 활용
4. Interface를 구현한 새로운 Class를 하나 만들어서 새로운 기능 구현
5. 역할과 구현의 분리로 생각. 즉, Interface Code는 변경하지 않고, 새로운 구현체를 통해 확장할 수 있다. 

 

 

public class MemberService {
	private MemberRepository memberRepository = new MemoryMemberRepository();
} // Class 끝






public class MemberService {
//	private MemberRepository memberRepository = new MemoryMemberRepository();
	private MemberRepository memberRepository = new JdbcMemberRepository();
} // Class 끝

 

문제점

1. MemberService Client가 구현 Class를 직접 선택
   • MemberRepository m = new MemberMemberRepository();   => 기존 코드
   • MemberRepository m = new JdbcMemberRepository();   => 변경 코드
2. 구현 객체를 변경하려면 Client Code가 변경되어야 한다.
3. 분명 다형성을 사용했으나, OCP 원칙을 지킬 수 없는 문제 발생
   • 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요
     이것을 Spring Container가 DI를 통해 처리

 

 

 

         👉 LSP (Liskov Substitution Principle) : 리스코프 치환 원칙

어떤 Interface에 대한 구현체가 있을 때, 예를 들어 자동차 Interface를 구현한 아반떼에 악셀 기능이 앞으로 간다이지만, 뒤로 갈 수 있게도 할 수 있답니다. 이렇게 해도 문제는 없으나, 악셀을 밟으면 앞으로 간다가 규약이라면 이 규약을 무조건 지켜야 된다에 대한 것이에요!

 

1. 프로그램의 객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
2. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면? 이 원칙이 필요
3. 단순히 컴파일에 성공하는 것을 넘어서는 부분

 

 

 

         👉 ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

1. 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
2. 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
3. 사용자 클라이언트 - > 운전자 클라이언트, 정비사 클라이언트로 분리
   이렇게 구현 시 이용자 클라이언트와 정비사 클라이언트를 분리해서 정비사 클라이언트(정비 인터페이스 자체 변경)에 변경 사항이 있더라도 이용자 클라이언트에 영향을 주지 않을 수 있다.
4. 인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

 

 

 

         👉DIP (Dependency Inversion Principle) : 의존관계 역전 원칙 (매우 중요)

1. 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나
   • 클라이언트(Service Layer 등)이 인터페이스(MemberRepository 등)만 바라봐야지 구현체는 몰라야 한다.
2. 쉽게 이야기해서 구현체에 의존하지 말고, 인터페이스에 의존하라는 뜻
3. 역할(Role)에 의존하게 해야 한다는 이야기. 즉, 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.
   구현체에 의존하게 되면 변경이 아주 어려워진다.
   • 정리하자면 로미오 역할에 원빈 배우님이 줄리엣 역할에 김태희 배우님이랑 연습하고, 호흡을 맞추었다면 김태희 배우님 외에 대체가 불가하다. 원빈 배우님은 줄리엣 역할만 알고, 자기 것을 연습하면 되지 다른 배우들을 일일이 알 필요가 없다.
4. OCP에서 공부한 MemberService는 인터페이스에 의존하나, 구현 클래스도 동시에 의존한다.
5. MemberService 클라이언트가 구현 클래스를 직접 선택
   • MemberRepository(인터페이스) m = new MemoryMemberRepository(); (구현체)
     인터페이스와 구현체를 모두 의존하고 있기 때문에 DIP 위반
6. DIP 위반이란?
   • 추상화(인터페이스)에 의존해야지 구체화(구현체)에 의존하면 안된다.

 

 

 

    📍정리

• 객체 지향의 핵심은 다형성
• 다형성 만으로 쉽게 부품을 갈아 끼우듯 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경해야 하는 문제가 발생한다.
• 즉, 다형성 만으로는 OPC, DIP를 지킬 수 없다.

 

 

 

 

---

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글 그리고 방명록은 주니하랑에게 많은 힘이 됩니다