[Spring] 핵심원리 기본편 - 객체 지향 설계와 스프링

인프런 - 스프링 핵심 원리 (김영한) 강의를 듣고 간단하게 정리한 글입니다.

스프링 부트

• 스프링을 편리하게 사용할 수 있도록 지원해주는 기술
• Tomcat과 같은 웹 서버를 내장해서 별도의 웹 서버 설치하지 않아도 됨
• 손쉬운 빌드 구성을 위한 starter 종속성 제공 -> spring-data-starter 등 여러개를 직접 설치해 써야 했지만 스프링 부트를 통해 한번에 관리 가능
• 스프링과 서드파티 라이브러리 자동 구성 -> 버전 조합 알아서 설치해줌
• 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공 -> 운영에 필요한 중요한 기능들 알아서 제공해줌
• 관례에 의한 간결한 설정 -> 대부분 디폴트 설정 사용하고 필요한 부분만 일부 커스텀 가능

 

스프링

• 자바 언어 기반의 프레임워크
• 자바 언어의 가장 큰 특징인 객체 지향 언어가 가진 강력한 장점을 살려내는 프레임워크
• 그렇다면 객체 지향 프로그래밍은 어떻게 해야 하는 걸까?

---

객체 지향 프로그래밍

• 대표적 특징: 추상화, 캡슐화, 상속, 다형성(하나의 객체가 여러가지 타입 가질 수 있는 것)
• 유연하고 변경이 용이하다는 특징 -> 레고 블럭 조립하듯이 컴포넌트를 쉽고 유연하게 변경 가능함 == 다형성
• 다형성의 장점
  • 클라이언트는 대상의 역할(인터페이스)만 알면 됨
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않음
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않음

- 다형성에서 역할(인터페이스)과 구현(인터페이스를 구현한 클래스)을 명확하게 분리해서 개발하자!
- 객체를 설계할 때는 역할을 먼저 부여하고 그 역할을 수행하는 구현 객체를 만들자! 
- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있도록 하자!

---

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

SRP 단일 책임 원칙 (Single Responsesibility Principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임? 애매 -> 중요한 기준은 '변경이 있을 때 파급 효과가 적어야 한다'는 것

OCP 개방-폐쇄 원칙 (Open/closed Principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 무슨 말..? 다형성의 관점에서 생각해보자!
• ex) MemberService 클라이언트가 구현 클래스를 선택한다고 가정해보자
  • MemberRepository m = new MemoryMemberRepository(); // 기존 코드
  • MemberRepository m = new JdbcMemberRepository(); // 변경 코드
• 여기서 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다 -> 다형성을 사용한 건 맞지만 OCP 원칙이 지켜지지 않았다 -> 객체를 생성하고 연관관계를 맺어주는 별도의 존재가 필요! -> spring container가 해줌

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

• 프로그램의 객체의 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 즉, 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것
• ex) 자동차 인터페이스의 엑셀은 앞으로 가는 기능임 -> 뒤로 가게 구현? LSP 지켜지지 않는 것

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

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• ex) 자동차 인터페이스가 운전 인터페이스와 정비 인터페이스로 나뉘어져 있을 때 정비쪽에 변경이 필요하면 운전은 건드리지 않고 정비만 변경하면 된다.
• 인터페이스가 명확해지고, 대체 가능성이 높아짐

DIP 의존관계 역전 원칙 (Dependency Inversion Principle)

• 추상화에 의존하지, 구체화에 의존하면 안된다 -> 구현 클래스에 의존하지 말고, 인터페이스에 의존하라
• ex) MemberService가 MemberRepository interface만 바라보고 MemoryMemberRepository는 몰라야 한다.
• 즉, 위에서 MemberRepository m = new MemoryMemberRepository(); 이 부분은 MemberService 클라이언트가 구현 클래스를 직접 선택하므로 DIP를 위반한다고 볼 수 있다.

 

결론

• 객체 지향의 핵심은 다형성!
• 하지만 다형성 만으로는 OCP, DIP 지킬 수 없다.
• 뭔가 더 필요하다!
• 이제부터 그걸 배울것