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

01. 자바 진영의 추운 겨울과 스프링의 탄생

01-1. 스프링의 탄생 배경

로드 존슨 : Spring F/W 게빈 킹 : Hibernate

Spring + JPA + 등등을 합친 종합 선물세트라 봐도 됨
2000년대 초반 Java 진영의 EJB(Enterprise Java Beans) 기술이 존재하였다
- 자바 진영의 표준
- 당시에는 EJB 사용을 위해서는 수천만원짜리 서버가 필요 하였음
- 어렵고, 복잡하고, 말 그래도 EJB 지옥이였다
- 결국 POJO로 돌아가자는 말도 나옴
EJB를 가지고 프로젝트를 진행 하였던 로드 존슨은 오픈 소스로 Spring을 내세운다
게빈 킹 역시 EJB 엔티티빈 기술의 대체안으로 Hibernate 오픈 소스를 내세운다

01-2. 스프링 역사

유겐 휠러, 얀 카로프 : 오픈 소스 프로젝트 제안

2002년 로드 존슨 책 출간
EJB의 문제점 지적
EJB 없이도 충분히 고품질의 확장 가능한 애플리케이션을 개발할 수 있음을 보여주고, 30,000라인 이상의 기반 기술의 예제 코드를 선보임
BeanFactory, ApplicationContext, POJO, 제어의 역전, 의존관계 주입 개론 설명
책이 유명해지고, 개발자들이 책의 예제 코드를 프로젝트에 사용
- 책 출간 이후에 Juergen Hoeller(유겐 휠러), Yann Caroff(얀 카로프)가 로드 존슨에게 오픈소스 프로젝트를 제안
- 스프링 핵심 코드의 상당수는 유겐 휠러가 지금도 개발
- 스프링 이름은 전통적인 J2EE(EJB)라는 겨울을 넘어 새로운 시작이라는 뜻으로 지음

01-3. 스프링 역사

2003년 스프링 프레임워크 1.0 출시 - XML
2006년 스프링 프레임워크 2.0 출시 - XML 편의 기능 지원
2009년 스프링 프레임워크 3.0 출시 - 자바 코드로 설정
2013년 스프링 프레임워크 4.0 출시 - 자바8 지원
2014년 스프링 부트 1.0 출시
2017년 스프링 프레임워크 5.0, 스프링 부트 2.0 출시 - 리엑티브 프로그래밍 지원
2020년 9월 현재 스프링 프레임워크 5.2.x, 스프링 부트 2.3.x

02. 스프링이란?

02-1. 스프링 생태계

스프링이란 어떠한 특정 하나가 아닌 여러 가지 기술의 모음을 의미
- 스프링 프레임워크
- 스프링 부트
  - 스프링 데이터
  - 스프링 세션
  - 스프링 시큐리티
  - 스프링 배치
  - 스프링 클라우드

02-2. 스프링

핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
웹 기술 : 스프링 MVC, 스프링 WebFlux
데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
테스트 : 스프링 기반 테스트 지원
언어 : 코틀린, 그루비
최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용

02-3. 스프링 부트

스프링은 기초가 되는 대규모 프로젝트입니다. 이러한 스프링을 기반으로 하여 실행 가능한 내장 톰캣을 가지고 .jar 파일 하나만으로도 실행이 가능하고 의존성을 관리해주는것이 새로운 표준인 스프링 부트 입니다.

스프링을 더욱 더 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
단독 실행이 가능한 스프링 애플리케이션을 쉽게 생성
- 내장 톰캣 지원하므로, 웹 서버 설치가 불필요함
- 손쉬운 빌드 구성을 위한 Starter 종속성 제공
  - 즉, 외부 라이브러리 버전에 대해서 크게 고민하지 않아도 된다
메트릭, 모니터링, 외부 구성 같은 프로덕션 준비 기능 제공
관례에 의한 간결한 설정
- 문서가 잘 되 있으며 설정이 간편하다

02-4. 스프링 단어

스프링이라는 단어는 문맥에 따라 다르게 사용
- 스프링 프레임워크
- 스프링 DI 컨테이너 기술
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계

02-5. 핵심 개념?

어떤 기술이든 그 기술의 핵심 컨셉이 어떤 것인지 고민해볼 필요가 있다.

이 기술을 왜 만들었는가??
이 기술의 핵심 컨셉은 무엇인가??

02-6. 스프링의 진짜 핵심

핵심은 스프링은 좋은 객제치향 프로그래밍을 하도록 도와주는 프레임워크다

스프링은 자바 언어 기반의 프레임워크
자바 언어의 가장 큰 특징 - 객체 지향 언어
스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
- 당시에 EJB를 상속하면 EJB에 지저분하게 의존적인 개발을 해야 했다
- 객체지향의 장점을 모두 잃어버렸다
- 여기서 POJO로 돌아가자는 말도 나왔지만, 스프링 F/W가 나옴
그렇다면 좋은 객체지향 프로그래밍이 무엇인가? 이 부분을 아는 게 핵심이다

03. 좋은 객체 지향 프로그래밍이란?03-1. 객체 지향의 특징과 종류

상속
추상화
캡슐화
다형성

03-2. 객체 지향 프로그래밍이란?

컴퓨터 프로그램을 단순히 명령어의 단위로 보는 것이 아님
여러개의 독립된 단위인 객체들의 모임으로 파악하는 특징이 있음
이러한 객체들은 서로 메시지를 주고 받으면 데이터 처리가 가능
유연하고 변경에 용이하여 주로 대규모 개발에서 사용
객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉 객체들의 모임으로 파악하고자 하는 것을 의미함

각각의 객체들은 메시지를 주고받고, 데이터를 처리할 수 있다 (협력)
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들어 대규모 개발에서 많이 사용이 된다

03-3. 유연하고, 변경이 용이?

레고 블럭 조립하거나, 컴퓨터 부품 갈아 끼우듯이
컴포넌트를 쉽고 유연하게 변경이 가능

03-4. 다형성의 실세계의 비유

실세계와 객체 지향을 1 : 1로 매칭 x
- 그래도 실세계의 비유로 이해하기에는 좋음
이 세상을 역할과 구현으로 세상을 구분

03-5. 운전자 - 자동차(OCP - 개방 폐쇄 원칙)

운전자 역할과 자동차 역할 2개로 구분이 된다
자동차 역할을 구현하는 구현체는 다음과 같다
- K3
- 아반테
- 테슬라 모델3
클라이언트에 영향을 주지않고 기능을 구현할 수 있음
- 새로운 자동차가 나와도 클라이언트를 바꿀 필요가 없음

03-6. 공연 무대(OCP - 개방 폐쇄 원칙)

로미오, 줄리엣 역할(인터페이스)이 존재
- 로미오와 줄리엣 공연 시 배우는 대체가 되어야 한다

03-7. 역할과 구현을 분리

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경이 용이해짐
장점
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된며, 변경되어도 영향을 받지 않는다
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다

03-8. 역할과 구현을 분리

자바 언어

자바 언어의 다형성을 활용
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
객체를 설계할 때 역할과 구현을 명확히 분리
객체 설계 시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

03-9. 객체의 협력이라는 관계부터 생각

혼자 있는 객체는 없다
클라이언트: 요청, 서버: 응답
수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다

03-10. 자바 언어의 다형성

MemberRepository memoryMemberRepository = new MemoryMemberRepository();
memoryMemberRepository.save(); // MemoryMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

MemberRepository jdbcMemberRepository = new JDBCMemberRepository();
jdbcMemberRepository.save(); // JDBCMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

public class MemoryMemberRepository implements MemberRepository {
	
    @Override
    public void save() {
        ...중략
    }
}

public class JDBCMemberRepository implements MemberRepository {
	
    @Override
    public void save() {
        ...중략
    }
}

오버라이딩을 떠올려보자
- 오버라이딩은 자바 기본 문법
- 오버라이딩 된 메서드가 실행 됨
- 다형성으로 인터페이스를 구현할 객체를 실행 시점에 유연하게 변경할 수 있다
물론 클래스 상속 관계도 다형성, 오버라이딩 적용 가능
부모는 자식 마음을 잘 알기에 자식들을 모두 품을 수 있으나 자식은 부모의 마음을 모르기에 부모를 품을 수 없다

03-11. 다형성의 본질

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

03-12. 역할과 구현을 분리 - 정리

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

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

[OOP] 객체지향 5원칙(SOLID) - 의존성 역전 원칙 (Dependency Inversion Principle) - 𝝅번째 알파카의 개발 낙서장

04-0. SOLID

😀 클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

SRP : 단일 책임 원칙(Single responsibility principle)
OCP : 개방 폐쇄 원칙(Open/closed principle)
LSP : 리스코프 치환 원칙(Liskov substitution principle)
ISP : 인터페이스 분리 원칙(Interface segregation principle)
DIP : 의존관계 역전 법칙(Dependency inversion principle)

04-1. SRP : 단일 책임 원칙(Single responsibility principle)

하나의 객체는 반드시 하나의 동작만의 책임을 갖는다는 원칙이다
하나의 책임이라는 것은 모호한 부분이 있다
- 클 수 있고, 작을 수 있다
- 문맥과 상황에 따라 다르다
중요한 기준은 변경이 있을 때 Side effect가 적으면 단일 책임 원칙을 잘 따른 것
예) UI 변경, 객체의 생성과 사용을 분리
- application 코드부터 SQL까지 다 수정을 해야 하는 경우?
- 계층이 구분되지 않고 모든 행위를 하나의 파일에 넣는다

예시

@Service
public class UserService {

    @AutoWired
    private UserRepository userRepository

    public void login(String userId, String userPwd) {

            // 회원 존재 여부 로직 있다 가정

            ...

            // 로그인

            ...

            // 세션 처리 로직 있다 가정

            ...

            // 쿠키 ..

            ...
    }
}

로그인 처리를 하는 로직이 있다고 가정
해당 로직은 존재 여부, 로그인, 세션, 쿠키 등의 모든 처리를 하나의 메서드에서 담당
현재 4개의 책임을 하나의 메서드가 담당하고 있는 상황이다

@Service
public class UserService {

    @AutoWired
    private UserRepository userRepository

    public void login(String userId, String userPwd) {

            // 회원 존재 여부 메서드 호출

            ...

            // 로그인 처리 메서드 호출

            ...

            // 세션 처리 메서드호출

            ...

            // 쿠키 ..

            ...
    }

    public int checkUserExists() {
            ...
    }

    public void saveUserSession() {
            ...
    }

    public void saveUserCookie() {
            ...
    }
}

하나의 메서드가 가진 4개의 책임을 각각의 메서드로 분리하여 책임을 나누었다
장점 : 이슈 발생 시 각 메서드 내에서 디버깅이 가능, 가독성 역시 좋아지는 효과를 가져옴

04-2. OCP : 개방 폐쇄 원칙(Open/closed principle)

[SOLID] 개방 폐쇄 원칙(OCP)이란?

소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다
변화하는 부분을 추상화함으로써 기존 코드를 수정하지 않고도, 확장을 할 수 있게 만든다
다형성을 활용해보자
인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능 구현
지금까지 배운 역할과 구현의 분리를 생각해보자

개방 폐쇄 원칙을 지키는 법?

핵심은 변화하는 부분을 추상화 하는 것
- 상속 사용
- 인터페이스 사용

예제 코드 : 이번에는 상속을 사용

클라이언트의 요청이 왔을 때 데이터를 HTTP 응답 프로토콜에 맞춰 데이터를 전송 해주는 ResponseSender가 있다 가정

public class ResposneSender {
    private Data data;

    public ResponseSender(Data data) { // 생성자를 통해 data 객체 초기화
            this.data = data;
    }

    public Data getData() { // getter data 객체 반환
        return data;
 	}

  	public void send() { // HTTP 응답 프로토콜에 맞춰 데이터를 전송 해주는 send 메서드
    	sendHeader();
        sendBody();
  	}

  	protected void sendHeader() {
    	// 헤더 데이터 전송
  	}

  	protected void sendBody() {
    	// 텍스트로 데이터 전송
  	}			
}

ResponseSender 클래스의 send 메서드는 요청에 대한 header, body를 전달 해주는 메서드
이 때, 두 메서드는 접근 제한자가 protected로 선언이 되어 있기 때문에 상속 관계로 이루어진 하위 객체에서 오버라이딩 가능

// 하위 클래스
public class ZippedResponseSender extends ResponseSender {
		
	public ZippedResponseSender(Data data) {
		super(data)
	}
		
	@Override
	protected void sendBody() {
		// 데이터 압축 처리
	}		
}

ZippedResponseSender 클래스는 기존 기능에 압축 기능을 추가
해당 기능을 추가하기 위해 ResposneSender 클래스를 변경 하지는 않음, 부모 클래스의 메서드를 재정의하여 사용
상속과 오버라이딩을 통해 메서드를 재정의하여 사용 하였다, 이렇듯이 변경에는 막혀있고 확장에는 열려있는 상황을 재현 해보았고 이러한 원칙을 OCP(개방 폐쇄 원칙)이라 지칭한다

이전 MemberSerivce의 문제점

public class MemberService {
	
	MemberRepository memoryMemberRepository = new MemoryMemberRepository();
	memoryMemberRepository.save(); // MemoryMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

}

public class MemberService {

	MemberRepository jdbcMemberRepository = new JDBCMemberRepository();
	jdbcMemberRepository.save(); // JDBCMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

}

public class MemoryMemberRepository implements MemberRepository {
	
    @Override
    public void save() {
        ...중략
    }
}

public class JDBCMemberRepository implements MemberRepository {

    @Override
    public void save() {
        ...중략
    }
}

MemberService 클라이언트가 구현 클래스를 직접 선택
- MemberRepository m = new MemoryMemberRepository(); // 기존 코드
- MemberRepository m = new JdbcMemberRepository(); // 변경 코드
구현 객체를 변경하려면 클라이언트 코드(MemberService)를 변경해야 한다
- 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다
이 문제를 어떻게 해결할 것인가?
객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 생성자가 필요하다
- 이러한 역할을 하는 것이 Spring Framework
  - IOC
  - DI

💡 현재 위 소스를 리팩토링 하지 않았다. 추후 강의에서 스프링을 통한 리팩토링 과정 기재 예정

04-3. LSP : 리스코프 치환 원칙(Liskov substitution principle)

https://velog.io/@jinmin2216/자료구조-2.-JAVA-Collection

영한님께서 말씀하신 부분

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

LSP 정리

강의 내에서 좋은 말씀을 해주셨지만, 개인적으로 이해하기에는 내용이 부족하여 추가 내용을 정리하였다

[JAVA] SOLID - 리스코프 치환 원칙 LSP(Liskov Substitution Principle)

서브 타입(자식)은 언제든 자신의 기반(부모) 타입으로 교체할 수 있어야 한다
즉, 상속 관계 내에서 자식 클래스는 언제든 부모 타입으로 교체할 수 있다는 말을 의미

잘못된 예시 : 가족 구성

참고 : “하위 클래스는 상위 클래스다” 로버트 C. 마틴

위 예시처럼 상 하위 관계가 정해지면 논리적 관계가 맞지 않음
- 사촌형을 할아버지로 교체할 수 있는가?
- 사촌 누나를 삼촌으로 교체할 수 있는가?
- 아들을 아버지로 대체할 수 있는가?
  - 위 예시는 리스코프 치완 원칙을 위배하는 구성도다

올바른 예시 : 동물 구성

위 예시를 리스코프 치완 원칙과 상속 관계를 지키는 올바른 예시라고 할 수 있다
- 고래는 포유류다?
- 참새는 조류다?
- 펭귀은 조류다?

예시 코드

[SOLID 원칙] 3. Liskov Substitution Principle 리스코프 치환 원칙

Base base = new Derived();
base.funcA();
base.funcB();
base.funcC();
base.funcD();

상위 클래스 Base로 하위 클래스 Derived를 받는다
함수 호출 시 하위 클래스에서 오버라이딩 한 메서드가 호출이 됨, 부모 클래스로 자식 클래스를 대체 한다

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

영한님께서 말씀하신 부분

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리
분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
인터페이스가 명확해지고, 대체 가능성이 높아진다

ISP 정리

ISP(인터페이스 분리 원칙)은 하나의 인터페이스가 너무 많은 역할을 가지고 있으면 해당 인터페이스의 역할을 분리하라는 개념을 가지고 있다
인터페이스의 경우 상속과 다르게 구현을 강제하게 되는데 여기서 문제가 발생하게 된다
- 하위 구현체는 상위 인터페이스 중 사용하지 않는 메서드도 모두 오버라이딩 구현 해야 한다
- 역할이 구분되어 있지 않기에, 불필요한 메서드 역시 구현

예시

SOLID - ISP(Interface Segregation Principle)란? : 인터페이스 분리 원칙

인터페이스 작성

public interface SmartPhone {
    String telephone();

    String mp3();

    String internet();
}

구현 클래스 작성 : Galaxy1

package solid.isp;

public class Galaxy1 implements SmartPhone {
    
    @Override
    public String telephone() {
        return "ring ring";
    }

    @Override
    public String mp3() {
        return "play mp3";
    }

    @Override
    public String internet() {
        return "connect complete!";
    }
}

SmartPhone을 상속한 Galaxy1 버전이 출시 되었다 가정
여기서 추후에 Galaxy2 버전이 출시된다, 다음 소스를 보자

구현 클래스 작성 : Galaxy2

package solid.isp;

public class Galaxy2 implements SmartPhone {
    @Override
    public String telephone() {
        return "ring ring";
    }

    @Override // 나는 이 기능을 삭제하고 싶은데???????
    public String mp3() {
        return "play mp3";
    }

    @Override
    public String internet() {
        return "connect complete!";
    }

    public String video() {
        return "play video";
    }
}

Galaxy2 업그레이드 버전에서는 video 기능이 추가되었다
mp3 기능은 삭제를 해야 하는 상황이다

인터페이스 수정

public interface SmartPhone {
    String telephone();

//		String mp3(); // SmartPhone에서 mp3 추상 메서드는 제거

    String internet();
}

package solid.isp;

public interface Galaxy1Function {
    String mp3();
}

public class Galaxy1 implements SmartPhone, Galaxy1Function {
    @Override
    public String telephone() {
        return "ring ring";
    }

    @Override
    public String mp3() {
        return "play mp3";
    }

    @Override
    public String internet() {
        return "connect complete!";
    }
}

공통 인터페이스에서는 mp3 기능을 제거, 또 다른 인터페이스를 생성하여 해당 인터페이스에 mp3 기능을 추가
인터페이스의 경우 다중 구현이 가능하기에 Galaxy1에서 두 개의 인터페이스를 구현
Galaxy2의 경우 생략 (동일한 방식으로 video 메서드를 가진 인터페이스 생성 후 구현 한 로직)

04-5. DIP : 의존관계 역전 법칙(Dependency inversion principle)

DIP 원칙을 간단히 정의하면 의존 관계 형성 시 변하기 쉬운것에 의존하는 것이 아닌 변하지 않는 것에 의존하라는 원칙이다.

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다” 의존성 주입은 이 원칙을 따르는 방법 중 하나
앞 장 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인테페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 또한 구현체에 의존하게 되면 변경이 아주 어려워진다.
운전자는 자동차의 역할에 대해서 알아야지, K3에 대해서 알아서는 안된다
- 역할과 구현을 철저하게 분리할 수 있게 설계해야 한다
- 클라이언트가 인터페이스에 의존해야 함

부가 설명

여기서 MemberService를 Client Class라 볼 수 있다

public class MemberService {
	
    MemberRepository memoryMemberRepository = new MemoryMemberRepository(); // 구현 클래스에도 의존한다
    memoryMemberRepository.save(); // MemoryMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

}

public class MemberService {

    MemberRepository jdbcMemberRepository = new JDBCMemberRepository(); // 구현 클래스에도 의존한다
    jdbcMemberRepository.save(); // JDBCMemberRepository의 save() 메서드 호출, 오버라이딩 된 메서드 호출

}

위 OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다
MemberService 클라이언트가 구현 클래스를 직접 선택
- MemberRepository m = new MemoryMemberRepository();
DIP 위반
의존한다는 것은 내가 해당 코드에 대해 알고 있다면 의존한다고 할 수 있다

04-6. 정리

객체 지향의 핵심은 다형성
다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다
다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다
다형성 만으로는 OCP, DIP 원칙을 지킬 수 없다

05. 객체 지향 설계와 스프링

05-1. 다시 스프링으로

스프링 이야기에 왜 객체 지향 이야기가 나오는가?

스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
- DI(Dependency Injection) : 의존성 주입
- IOC 컨테이너 제공
  - 객체를 어떠한 컨테이너에 넣어두고, 이 안에서 의존 관계를 연결해주고 주입
클라이언트 코드의 변경 없이 기능 확장이 가능
- 쉽게 부품을 교체하듯 개발

05-2. 스프링이 없던 시절

객체 지향 개발을 하려고 OCP, DIP 원칙을 지키면서 개발하려다보니 할일이 너무 많음
- 배보다 배꼽이 더 크다
- 결국 프레임워크로 만들어버림
즉, 순수하게 자바로 OCP, DIP 원칙을 지키면서 개발을 해보면, 결국 스프링 프레임워크를 만들게 된다 (정확히는 DI 컨테이너)

05-3. 정리

모든 설계에 역할과 구현을 분리하자
자동차, 공연의 예를 떠올려보자
애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 객체 지향 설계다.
이상적으로는 모든 설계에 인터페이스를 부여하자
- 하지만 인터페이스 무분별 남발 시 추상화라는 비용이 발생한다 (성능 관점이 아님)
- 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 하나의 방법

참고 자료

저작자표시 변경금지

'Spring MVC > 스프링 - 핵심 원리 기본' 카테고리의 다른 글

[Spring MVC - 핵심 원리 기본] 06. 의존관계 자동 주입 (0)	2023.04.25
[Spring MVC - 핵심 원리 기본] 05. 컴포넌트 스캔과 의존관계 자동 주입 (2)	2023.04.25
[Spring MVC - 핵심 원리 기본] 04. 싱글톤 컨테이너 (1)	2023.04.25
[Spring MVC - 핵심 원리 기본] 03. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용 (0)	2023.04.25
[Spring MVC - 핵심 원리 기본] 02. 스프링 핵심 원리 이해1 - 예제 만들기 (0)	2023.04.25

블로그의 정보

기록하고, 복기하고

ymkim

01. 자바 진영의 추운 겨울과 스프링의 탄생

01-1. 스프링의 탄생 배경

01-2. 스프링 역사

01-3. 스프링 역사

02. 스프링이란?

02-1. 스프링 생태계

02-2. 스프링

02-3. 스프링 부트

02-4. 스프링 단어

02-5. 핵심 개념?

02-6. 스프링의 진짜 핵심

03. 좋은 객체 지향 프로그래밍이란?03-1. 객체 지향의 특징과 종류

03-2. 객체 지향 프로그래밍이란?

03-3. 유연하고, 변경이 용이?

03-4. 다형성의 실세계의 비유

03-5. 운전자 - 자동차(OCP - 개방 폐쇄 원칙)

03-6. 공연 무대(OCP - 개방 폐쇄 원칙)

03-7. 역할과 구현을 분리

03-8. 역할과 구현을 분리

03-9. 객체의 협력이라는 관계부터 생각

03-10. 자바 언어의 다형성

03-11. 다형성의 본질

03-12. 역할과 구현을 분리 - 정리

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

04-0. SOLID

04-1. SRP : 단일 책임 원칙(Single responsibility principle)

예시

04-2. OCP : 개방 폐쇄 원칙(Open/closed principle)

개방 폐쇄 원칙을 지키는 법?

이전 MemberSerivce의 문제점

04-3. LSP : 리스코프 치환 원칙(Liskov substitution principle)

영한님께서 말씀하신 부분

LSP 정리

잘못된 예시 : 가족 구성

올바른 예시 : 동물 구성

예시 코드

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

영한님께서 말씀하신 부분

ISP 정리

예시

인터페이스 작성

구현 클래스 작성 : Galaxy1

구현 클래스 작성 : Galaxy2

인터페이스 수정

04-5. DIP : 의존관계 역전 법칙(Dependency inversion principle)

04-6. 정리

05. 객체 지향 설계와 스프링

05-1. 다시 스프링으로

05-2. 스프링이 없던 시절

05-3. 정리

참고 자료

'Spring MVC > 스프링 - 핵심 원리 기본' 카테고리의 다른 글

블로그의 정보

활동하기

공유하기

다른 글

티스토리툴바