스프링(Spring)

스프링(Spring)이란?

• JAVA의 웹 프레임워크로 JAVA 언어를 기반으로 사용한다.
• JAVA로 다양한 어플리케이션을 만들기 위한 프로그래밍 틀이라 할 수 있다.
• JAVA의 활용도가 높아지면서, JAVA를 이용한 기술이 JSP, Mybatis, JPA 등의 기술이 생겨났다.
• Spring은 다른 사람의 코드를 참조하기 쉽고 편리한 구조로
  앞서 말한 기술들을 더 쉽게 사용해주는 오픈소스 프레임워크 이다.

스프링 프레임워크

• 핵심 기술 : 스프링 DI 컨테이너,AOP,이벤트,기타
• 웹 기술 : 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술 : 트랜잭션,JDBC,ORM 지원,XML 지원
• 기술 통합 : 캐시,이메일,원격접근,스케줄링
• 테스트 : 스프링 기반 테스트 지원
• 언어 : 코틀린,그루비

스프링 부트

• 스프링을 편리하게 사용할 수 있도록 지원,최근에는 기본으로 사용
• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
• Tomecat 같은 웹 서버를 내장해서 별도의 웹 서버 설치하지 않아도 됨
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 스프링과 3rd party(외부) 라이브러리 자동 구성
• 메트릭,상태 확인,외부 구성 같은 프로덕션 준비 기능 제공
• 관례에 의한 간결한 설정

웹 서버(Web Sever)

• HTTP 기반으로 동작
• 정적 리소스 제공,기타 부가기능
• 정적(파일) HTML,CSS,JS,이미지,영상
• 예) NGINX,APACHE

웹 애플리케이션 서버(WAS)

• HTTP 기반으로 동작
• 웹 서버 기능 포함 + (정적 리소스 제공 가능)
• 프로그램 코드를 실행해서 애플리케이션 로직 수행
• 동적 HTML,HTTP API(JSON)
• 서블릿,JSP,스프링 MVC
• 예)톰캣(Tomcat) Jetty,Undertow

톰캣(tomcat)은 흔히 WAS(Web Application Server)

• dynamic(동적)인 웹을 만들기 위한 웹 컨테이너, 서블릿 컨테이너라고 불리며, 웹서버에서 정적으로 처리해야할 데이터를 제외한 JSP, ASP, PHP 등은 웹 컨테이너(톰캣)에게 전달한다.
• 동적인 데이터 처리가 가능하고, DB연결, 데이터 조작, 다른 응용프로그램과 상호 작용이 가능하다.
• 톰캣은 8080포트로 처리한다.

스프링의 핵심

• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
• 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

객체 지향 특징

• 추상화
• 캡슐화
• 상속
• 다형성

객체 지향 프로그래밍

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

다형성(多形性)이란?

• 한자 이름 그대로 어떤 객체의 속성이나 기능이 상황에 따라 여러 가지 형태를 가질 수 있는 성질을 의미
• 어떤 객체의 속성이나 기능이 그 맥락에 따라 다른 역할을 수행할수 있는 객체 지향의 특성
• 역할과 구현으로 세상을 구분
• 메서드 오버라이딩과 메서드 오버로딩(method overloading)

• 운전자 - 자동차
• 공연무대
• 키보드,마우스,세상의 표준 인터페이스들
• 정렬 알고리즘
• 할인 정책 로직

역할과 구현을 분리

• 역할과 구현으로 구분하면 세상이 단순해지고,유연해지며 변경도 편리해짐

장점

• 클라이언트는 대상의 역할(인터페이스)만 알면된다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

자바 언어의 다형성 활용

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스,구현 객체
• 객체를 설계할 때 역할과 구현을 명확히 분리
• 객체 설계시 역할(인터페이스)을 먼저 부여하고,그 역할을 수행하는 구현 객체 만들기

자바의 오버라이딩

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

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

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점 에 유연하게 변경할 수 있다.
• 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야함
• 클라이언트를 변경하지 않고,서버의 구현 기능을 유연하게 변경할 수 있다.

역할과 구현을 분리(정리)

• 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음
• 유연하고,변경이 용이
• 확장 가능한 설계
• 클라이언트에 영향을 주지 않는 변경 가능
• 인터페이스를 안정적으로 잘 설계하는 것이 중요

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

SOLID

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

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

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

• ISP - 인터페이스 분리 원칙(Interface segregation principle)

• DIP - 의존관계 역전 원칙(Dependency inversion principle)

• 구현 클래스에 의존하지 말고,인터페이스에 의존해라

• 역할(ROLE)에 의존해야한다는 것

• 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경 가능하다!구현체에 의존하게 되면 변경이 매우 힘들어진다...

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

• 한 클래스는 하나의 책임만 가져야 한다.
• 책임?
  • 중요한 기분은 변경
  • 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
  • 예 ) UI 변경,객체의 생성과 사용을 분리

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

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 무슨 말??
  • 다형성을 활용해보자.
  • 인터페이스를 구현한 새로운 클래스를 만들어서 새로운 기능 구현

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

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

• 문제점
  • MemberService 클라이언트가 구현 클래를 직접 선택하게 된다.
  • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 함
  • 분명 다형성을 사용했지만 OCP 원칙 X
  • 해결 방법은?? - 객체를 생성하고,연관관계를 맺어주는 별도의 조립,설정자 필요

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

• 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 인스턴스로 바꿀 수 있어야함
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것,다형성을 지원하기 위한 원칙,인터페이스를 구현한 구현체가 믿고 사용하려면,이 원칙 필요
• 단순히 컴파일에 성공하는 것을 넘어서는 이야기
• 예시) 자동차 인터페이스의 엑셀은 앞으로 가는 기능,뒤로 가게하면 LSP 원칙 위반,무조건 앞으로

ISP - 인터페이스 분리 원칙(Interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 자동차 인터페이스 -> 운전 인터페이스,정비 인터페이스로 분리
• 사용자 인터페이스 -> 운전자 클라이언트,정비사 클라이언트로 분리
• 분리하면 인터페이스 자체가 변해도 운전자 클라이언트에 영향X
• 인터페이스가 명확해지며,대체 가능성 증가

DIP - 의존관계 역전 원칙(Dependency inversion principle)

• 구현 클래스에 의존하지 말고,인터페이스에 의존해라
• 역할(ROLE)에 의존해야한다는 것
• 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경 가능하다!구현체에 의존하게 되면 변경이 매우 힘들어진다...

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

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

• 여기서는 MemberService는 인터페이스에 의존하지만,구현 클래스도 동시에 의존한다.
• MemberService 클라이언트가 구현 클래스를 직접 선택
• DIP위반!!

김영한 - 스프링 핵심 원리 기본편 강의를 참고해서 정리했습니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8?gad_source=1&gclid=CjwKCAjw6JS3BhBAEiwAO9waF-U94I5Q7HOBbL2-GdSWah8TZfAF48E3wQIKeOHwAc6cDY6Xkeu25BoC7BMQAvD_BwE