스프링 스터디 3주차

EJB

•  ORM (자바 객체를 쿼리 없이 데이터베이스에 저장하는 것) 기술 가지고 있음 
• 이론은 좋지만 실제로 복잡하고 어려움, 비쌈

 

EJB를 비판하면서 더 단순하고 좋은 방법을 제시함 = Spring

 

최근 사용하는 것

• 표준 인터페이스:JPA
• JPA의 구현체들 : 하이버네이트(가장 많음), EclipseLink, 기타 ...

지금 시대 -> 스프링과 JPA 두가지 모두 중요함

 

 

[스프링의 역사]

EJB의 문제점을 지적하면서 만듦

 

 

2014년 스프링 부트 

-> 스프링 설정 어려웠던 것들 해결

 

 

[스프링이란?]

• 스프링 생태계

 

• 스프링 프레임워크 - 위의 모든 것들을 편리하게 사용하도록 도와주는 것 / 가장 중요!!

<스프링 프레임워크>

핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타

 

<스프링 부트>

• 스프링 프레임워크를 편리하게 사용할 수 있도록 해주는 것
• 별도의 웹 서버를 설치하지 않아도 됨
• starter -> 손쉬운 빌드 구성
• 스프링 프레임워크와 별도로 사용할 수 X  (도와주는 기술)

 

 

 

[스프링을 왜 만들었을까?]

<스프링의 핵심 개념 & 컨셉>

• 스프링 : 자바 언어 기반의 프레임워크
• 자바 = 객체 지향 언어
• 스프링 = 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크

 

<좋은 객체 지향 프로그램이란?>

• 프로그램을 명령어의 목록이 아닌 여러개의 독립된 단위(=객체)들의 모임으로 파악하는 것
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들어줌
• 유연하고 변경이 용이 = 컴포넌트를 쉽고 유연하게 변경하면서 개발 가능

 

<다형성>

역할 - 구현

자동차가 바뀌어도 운전자 역할에는 영향을 주지 않는다!!

= 운전자는 자동차 역할에 대해서만 알고 있고, 각각의 구현에 대해서는 알고 있지 않기 때문에 가능하다

역할와 구현의 분리 => 운전자(클라이언트)를 위해서 분리한 것

자동차 세상을 무한히 확장할 수 있다

새로운 자동차가 나와도 클라이언트는 바뀌지 않아도 된다는 것이 중요한 것

클라이언트는 자동차의 내부 구조를 알 필요가 없다

 

 

자바

역할=인터페이스

구현=인터페이스를 구현한 클래스, 객체

구현보다 역할이 중요! 역할이 먼저 부여되어야 한다

다형성을 오버라이딩으로 구현

 

 

다형성의 본질

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능

클라이언트를 변경하지 않은 채로 서버를 변경할 수 있다.

 

 

문제점

->역할(인터페이스)이 변하면, 클라이언트, 서버 모두에 큰 변경이 발생

->인터페이스를 안정적으로 잘 설계하는 것이 가장 중요!!

 

 

 

스프링

-> 다형성을 극대화해서 이용할 수 있게 도와준다.

 

 

 

 

[SOLID - 좋은 객체 지향 설계의 5가지 원칙] (중요!!!!!!)

<SRP 단일 책임 원칙>

• 한 클래스는 하나의 책임만
• 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙

 

<OCP 개방-폐쇄 원칙> 가장 중요!!

• 코드의 변경 없이 확장 가능
• 다형성을 통해 새로운 클래스를 만들어서 새로운 기능을 구현

*문제점*

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

구현 객체를 변경하려면 클라이언트 코드를 다음과 같이 선택을 통해 변경해야한다.

 

MemberRepository m = new MemoryMemberRepository(); //기존 코드

MemberRepository m = new JdbcMemberRepository(); //변경 코드

 

->코드의 변경이 일어남 -> OCP원칙 못 지킴 -> 객체 생성, 연관관계를 맺어주는 별도의 조립, 설정자를 통해 해결해야함 = 스프링이 해결해줌

 

 

<LSP 리스코프 치환 원칙>

-하위 클래스는 인터페이스 규약을 다 지켜야한다.

 

<ISP 인터페이스 분리 원칙>

-인터페이스를 여러개로 분리하는 것이 범용 인터페이스 하나보다 낫다.

-인터페이스가 명확해지고, 대체 가능성이 높아짐

 

<DIP 의존관계 역전 원칙> 가장 중요!!

-"추상화에 의존해야지, 구체화에 의존하면 안된다."

-구현 클래스에 의존하지 말고, 인터페이스에 의존해라 = 구현이 아닌 역할에 의존해라

 

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

MemberRepository m = new MemoryMemberRepository();

-> DIP 위반 (추상화와 구체화에 둘 다 의존 했기 때문)

 

 

--> 다형성 만으로는 OCP, DIP를 지킬 수 없다. = 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.

-> 다른 무언가가 더 필요하다 !!

 

 

 

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

스프링 = OCP, DIP를 가능하게 지원 = 클라이언트 코드의 변경 없이 기능 확장

 

 

package hello.core.member;

//MemberService에 대한 구현체
public class MemberServiceImpl implements MemberService{

    //구현 객체 선택해주기
    //좌변은 인터페이스에 의존하지만, 우변은 구현체에 의존하게 된다 (DIP위반)
    private final MemberRepository memberRepository=new MemoryMemberRepository();

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

 

 

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository=new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy=new FixDiscountPolicy();

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        //회원정보 조회
        Member member = memberRepository.findById(memberId);
        //단일책임원칙이 잘 지켜진 것 = discountPolicy에게 할인 관련된 것들을 다 맡겼음
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId,itemName,itemPrice,discountPrice);
    }
}