[기본] 객체 지향 설계와 스프링

스프링의 역사

스프링 이전에 Enterprise Java Beans 줄여서 EJB라는 기술이 사용되었다.

그러나 서버 비용도 크고, 설계도 잘못되어 이에 불만을 느낀 Rod Johnson이 EJB 컨테이너를 대체하는 기술을 출시하고, Gavin King이 엔티티빈을 대체하는 Hibernate를 만들었다.

Hibernate는 자바 표준화 되어 JPA(Java Persistence API)가 된다.

 

로드 존슨은 EJB의 문제점을 지적하며 스프링의 핵심 기반 코드(BeanFactory, ApplicationContext, POJO, 제어의 역전, 의존관계 주입)가 포함된 책을 출간한다. 후에 유겐 휠러, 얀카로프와 함께 오픈소스 프로젝트를 시작하며 이게 스프링이 된다.

 

스프링 프레임워크는 DI 컨테이너, AOP, MVC, JDBC 등을 포함하고 스프링 부트는 스프링을 편리하게 사용할 수 있도록 지원한다.

 

---

스프링의 핵심 개념

자바 언어는 객체 지향을 특징으로 한다.

스프링은 좋은 객체 지향 어플리케이션을 개발할 수 있도록 도와주는 프레임워크이다.

 

객체 지향 - 추상화, 캡슐화, 상속, 다형성

 

다형성은 역할(인터페이스)과 구현(클래스)으로 세상을 구분한다. ex) 자동차 역할 / k3, 아반떼 등

역할과 구현으로 구분하면 클라이언트는 내부 구조를 몰라도 되며, 내부 구조 변경에 영향을 받지 않는다.

 

따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.

 

---

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

SRP(single responsibility principle): 단일 책임 원칙

    -한 클래스는 하나의 책임만 가진다. 기준은 "변경" 이다. 변경의 파급 효과가 적도록 설계한다.

OCP(open/closed principle): 개방-폐쇄 원칙

    - 확장에는 열려있으나 변경에는 닫혀 있어야 한다. 구현 객체를 변경해도 클라이언트 코드를 변경하지 않아야 한다.

LSP(Liskov substitution principle): 리스코프 치환 원칙

    - 단순 컴파일 성공 문제를 넘어 프로그램 객체는 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 예) 자동차 엑셀 기능은 뒤로 가게 구현되어서는 안 된다.

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

    - 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 즉 명확한 기능별로 인터페이스를 분리한다.

DIP(dependency inversion principle): 의존관계 역전 원칙

    - 추상화에 의존해야하며, 구체화에 의존하면 안된다. 즉 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다.

 

---

객체 지향 설계와 스프링

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

ex) MemberRepository m = new MemoryMemberRepository() // 클라이언트에 구현체 코드가 포함됨

 

따라서 스프링은 DI(dependency injection, 의존관계/의존성 주입)와 DI 컨테이너 기능을 제공하여 OCP, DIP를 가능하게 지원한다.

 

즉 OCP, DIP 원칙을 지키며 개발하면 결국 스프링 프레임웍을 만들게 된다.

 

 

+) 그러나 실무에서는 인터페이스를 도입하면 추상화 비용이 발생한다. 기능 확장할 가능성이 없다면, 구체 클래스를 직접 사용하는 것도 방법