[Spring] 스프링 등장배경, Spring Framework란?, Spring Boot란?, 좋은 객체지향이란?, SOLID원칙과 문제점

 

"김영한 스프링 핵심 원리 기본편" 내용을 기반으로 작성한 내용입니다.

 

 

 

📝스프링 등장배경

옛날에는 EJB라는 프레임워크가 있었지만 너무 사용하기 어렵고 비용도 많이 들고 느리기 때문에 POJO(Plain한 상태)로 생각하자 해서 나온 게 Spring의 근간이 되는 부분이다. 그리고 EJB에서 사용했던 Entity Bean의 경우는 Hibernate가 대체하게 되었고 표준안이 된 게 JPA이다.

 

 

스프링 변경 순서

• EJB Entity Bean → Hibernate → JPA
• EJB → Spring

 

📝Spring Framework

Spring Framework는 스프링에 들어가는 핵심기술이 다 들어간 프레임워크이다.

 

📝Spring Boot

Spring Boot는 Spring Framework를 쉽게 사용할 수 있게 도와준다.

• 스프링 설정이 편해졌다.
• 내장 서버를 지원해 따로 서버를 깔 필요가 없다. (예를 들면 톰캣)
• 외부라이브러리 버전 호환성을 알아서 잘 처리해준다.
• 모니터링도 지원한다.

 

📝 좋은 객체지향이란?

다형성

"다양한 형태를 가질 수 있다" 라는 의미로 예를 들면 마우스가 고장나면 다른 마우스를 꽂아도 똑같이 동작하는 것처럼 USB포트의 설계만 동일하면 변경에 유연하고 용이하다.

 

객체 설계시에는 역할과 구현을 명확히 분리해야한다. 자바로 따지면 역할은 인터페이스이고 구현은 인터페이스를 이용한 클래스를 의미한다. 즉, 클라이언트는 인터페이스만 알면 된다. (엑셀을 밟으면 움직인다 / 브레이크를 밟으면 멈춘다)

 

인터페이스를 잘 설계했으면 클라이언트에서 따로 변경하지 않더라도 인터페이스를 이용한 클래스만 바꾸면 된다. 그래서 인터페이스 변화가 없게 설계하는게 정말 중요하다

 

 

 

📝 SOLID원칙

클린코드로 유명한 로버트 마틴이라는 사람이 좋은 객체 지향 설계를 위해 5가지 원칙을 정리한 것이다.

 

SRP (단일 책임 원칙)

하나의 클래스는 하나의 책임만 가져야한다. 즉, 변경이 있을 때 파급 효과가 적으면 해당 원칙을 잘 따른 것이다. 예를 들면 UI 변경시 모든 코드를 다 바꿔야하면 해당 원칙을 잘못 활용한 것이다.

 

OCP (개방 폐쇄 원칙)

확장에는 열려있지만 변경에는 닫혀있어야한다.

 

// 기존 코드
public class MemberService {
 private MemberRepository memberRepository = new MemoryMemberRepository();
}

// 변경 코드
public class MemberService {
// private MemberRepository memberRepository = new MemoryMemberRepository();
 private MemberRepository memberRepository = new JdbcMemberRepository();

}

위 코드를 보면 직접 코드를 변경해야하는 문제점이 있다. 즉, 다형성을 사용했지만 직접 주입 클래스를 바꿔야하기 때문에 OCP 원칙을 지킬 수 없다. 이럴 경우 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다

 

 

LSP (리스코프 치환 원칙)

다형성에서 하위 클래스는 인터페이스 규약을 지켜야한다. 예를 들면 엑셀을 밟으면 앞으로 나가는 게 일반적이지만 뒤로 가게도 만들 수 있는데 뒤로 가게끔 만들면 해당 원칙을 위반한 것이다.

 

ISP 인터페이스 분리 원칙

범용 인터페이스 하나보단 여러개의 인터페이스가 좋다. 예를 들면 자동차 인터페이스를 운전, 정비 인터페이스를 분리시키면 정비 인터페이스가 바뀌더라도 운전 인터페이스에 영향을 끼치지 않는다.

 

DIP 의존관계 역전 원칙

프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 즉, 인터페이스에 의존해야지 클래스에 의존하면 안 된다. 예를 들면 로미오라는 배역이라는 역할 자체가 바뀌면 안 되지 로미오를 연기하는 사람은 바뀌어도 괜찮다.

 

📝 SOLID 문제점

다형성 만으로는 OCP와 DIP 즉, 직접 코드를 프로그래머가 바꿔줘야하는 문제점을 해결할 수 없다. 이걸 해결하기 위해 스프링이 나오게 되었다.