01. Spring Basic - 스프링과 객체지향

1. Spring and Spring Boot

---

1.1 Spring Framework

• 핵심 기술 : Spring DI container, AOP, Event, etc..
• 웹 기술 : Spring MVC, Spring WebFlux
• 데이터 접근 기술 : Transaction, JDBC, ORM, XML
• 기술 통합 : cache, email, remote access, scheduling
• 테스트 : 스프링 기반 테스트 지원
• 언어 : kotlin, groovy

1.2 Spring Boot

• 스프링을 편리하게 사용할 수 있도록 지원
• 단독으로 실행할 수 있는 스프링 어플리케이션을 쉽게 생성
• Tomcat,Jetty 등과 같은 웹 서버 내장
• 단순한 빌드 구성을 위한 독자적인 starter 종속성 제공
• 매트릭, 상태 확인 및 외부화된 구성과 같은 프로덕션 준비 기능 제공
• 자동으로 Spring 및 3rd parth(타사) 라이브러리 자동 구성
• 관례에 의한 간결한 설정

2. OOP (Object-Oriented Programming)

---

2.1 What is OOP ?

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체" 들의 모임 으로 파악하고자 하는 것이다. 각각의 객체는 메시지 를 주고 받고, 데이터를 처리할 수 있다. (협력)
  
  
• 객체 지향 프로그래밍은 프로그램을 유연 하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

2.2 SOLID

SRP (single responsibility principle)

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

• 중요한 기준은 변경 이다. (변경이 있을 때 파급 효과가 적으면 SRP 를 잘 따른 것)

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

OCP (Open/closed principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

• 다형성을 활용

• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현

• MemberService 클라이언트가 구현 클래스를 직접 선택

MemberRepository m = new MemoryMemberRepository();
MemberRepository m = new JdbcMemberRepository();

다형성을 사용했지만 OCP 원칙 위반

이 경우에는 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요

LSP (Liskov substitution principle)

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

• Ex) 자동차 인터페이스의 엑셀은 전진하는 기능, 후진하게 구현하면 LSP 위반

ISP (Interface segregation principle)

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

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

• 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트

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

DIP (Dependency inversion principle)

• 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다.

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

그런데 OCP 에서 설명한 MemberService 는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존
DIP 위반

2.3 Spring and OOP

• 다형성이 중요하다.

• 스프링은 다형성을 극대화하게 도와준다.

• 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 인터페이스와 구현을 편리하게 다룰 수 있도록 지원

• 스프링은 DI 기술로 다형성 + OCP, DIP 를 가능하게 지원

3. Conclusion

---

• 모든 설계에 인터페이스와 구현을 분리하자

• 이상적으로는 모든 설계에 인터페이스를 부여

• 실무적으로는 인터페이스를 도입하면 추상화 라는 비용이 발생

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

<출처 : 스프링 핵심 원리 - 기본편 by 김영한 >