코드스테이츠 - 스프링 - 시작

kwak woojong·2022년 6월 14일
0

코드스테이츠

목록 보기
23/36
post-thumbnail

framework? Library?

어플리케이션 흐름 제어권에 따라 차이가 난다.

주도권을 개발자가 가지면 Library

주도권이 얘가 가지면 framework다.

스프링은 흐름이 개발자가 아닌 framework에 있다. 스프링이 워낙 자체적으로 해결해주는게 많으니까 당연함.

만약 개발자가 개발할 때, 컨테이너는 이렇게 넣고 저기 붙여주고 이렇게 찾고 하는 모든 코드를 작성한다면, Library라 볼 수도 있겠지?

스프링은 지가 알아서한다 캬

그래서 스프링을 이용하면 개발자는 자바 코드만 열심히 작성하면 된다. 물론 엄밀히 말하자면 여러개 신경쓸게 많지만, 스프링 자체가 워낙 광범위하니까 참고만 하셈.


Spring framework의 특징

POJO (Plain Old Java Object)

순수한 자바 객체로 프로그래밍 하는 것을 POJO라 한다.

특정 라이브러리나, 특정 환경에 의존적이게 되면 유지보수시 치명적인 단점을 가지게 된다.

때문에 SOLID 원칙 처럼 5대 객체지향 원칙을 지키는게 우선시 된다고 보면 좋겠다.

  • POJO란 순수한 Java 객체를 의미
  • POJO 프로그래밍이란 순수 Java 객체가 다른 기술이나 환경에 종속되지 않도록 하기 위한 프로그래밍 기법
  • POJO 프로그래밍을 효과적으로 적용하기 위해서는 특정 기술에 대한 지식보다는 JDK의 API에 대한 지식과 객체지향적인 사고 방식과 설계를 위한 훈련이 우선시 되어야 한다.
  • Spirng framework은 POJO 프로그래밍 지향을 위해 IoC/DI,AOP,PSA라는 기술을 제공한다.

그냥 객체지향이지 뭐...


IoC / DI

IoC (Inversion of Control)

제어의 역전이라는 뜻

framework는 어플리케이션 제어의 흐름을 가진다. (개발자한테 없음)

흐름은 Spring에 맡기고 개발자는 자바 코드 개발에 집중할 수 있음.

Bean 컨테이너에 등록하고, 싱글톤을 보장시킨 다음에 의존관계 주입, 실제 어플리케이션 작동에 잘 되는지 이런거 일일히 구현하면 대가리 깨진다.

특히 Bean 컨테이너 없이 SOLID를 지키기가 드릅게 힘들고 어렵다.

생성할 때 private final로 만들고, 생성된 애를 게터세터처럼 불러오는 방식으로 해야 하는데, 이게 여간 불편한게 아님. 스프링을 활용하면 이런 필수적인 흐름을 알아서 제어해주니까 매우 좋다.

public class SingletonService {
    private static final SingletonService instance = new SingletonService();
    
    public static SingletonService getInstance(){
        return instance;
            }
            
    private SingletonService() {
    }
    
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

빈 없이 싱글톤을 만들려고 자체 클래스에서 객체 생성을 한 다음에 getInstance()로 객체를 불러온다. 이러면 무적권 싱글톤이지

@Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    void singletonServiceTest(){
        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();

        System.out.println("singletonService1 = " + singletonService1);
        System.out.println("singletonService2 = " + singletonService2);
        assertThat(singletonService1).isSameAs(singletonService2);
    }

이런식의 동작이 쌉가능하다는 거다. 근데 일일히 설정하기 너무 귀찮잖아

거기다가 인터페이스가 아닌 구체화된 클래스의 의존하게 될 가능성도 높고...

저런 흐름은 걍 빈 컨테이너에 박아버리고 걍 하던대로 하면 얼마나 좋아?


DI (Dependency Injection)

DI는 의존성 주입을 말한다.

아이템 서비스 클래스를 사용하려면 레포지터리가 필요하다. 저 부분이 바로 의존성 주입이다.

이 의존성 주입시 싱글톤이냐 아니냐, 인터페이스를 주입받느냐 아니냐 이런게 매우 중요하다.

만약 구체화된 클래스에 의존한다면, 레포(DB) 정책이 바뀔 때 고생 꽤나 할거다.

인터페이스에 의존한다면, 그냥 인터페이스를 확장시켜서 다른 레포(DB) 클래스를 만들면 된다.

그리고 빈 등록시 바꿔주기만 하면 된다!

만약 구체클래스 내부에서 의존성 주입을 한다면, SOLID원칙, IoC 원칙이 박살날 수 있다. 이를 방지하기 위해 Configuration을 써야 한다.

Config 클래스를 따로 만들어서 상기 사진과 같이 의존성 주입, 객체 생성을 한다면 Spring에서 알아서 싱글톤을 만들어주고 알아서 다 의존관계 주입을 각자 클래스에서 다 해준다.

이게 디게 특별한 부분인데, 의존관계 주입된 객체의 주소값을 불러오면 우리가 평소 보던 java 클래스의 주소가 아니라 뭔 이상한 문자가 붙은 주소가 된다.

Spring이 framework인 이유를 다시 생각해보면, 우리는 객체를 생성했는데, Spring에서 알아서 다른 주소를 불러주고 싱글톤을 보장해주고 있는거다.

class hello.core.AppConfigEnhancerBySpringCGLIBEnhancerBySpringCGLIB77446392

저런 주소가 뜸. 뭔가 이상하지? springCGLIB어쩌구저쩌구는 처음보쟈?

Config을 쓰면 자바 언어 자체는 뜯어 고치지는 않고 CGLIB라는 다른 객체를 만든다. 얘가 Config의 자식클래스로 만들어짐.

때문에 Spring이 어플리케이션의 흐름을 제어하면서 싱글톤을 보장해주며 다른 곳에서 객체를 생성할 때 Bean 등록이 되어 있는 친구라면 new가 붙더라도 새로운 객체를 생성하지 않는다.


AOP (Aspect Oriented Programming)

관심 지향 프로그래밍 정도로 해석이 가능하겠다.

AOP라는 것은 어플리케이션의 핵심 업무 로직에서 로깅이나 보안, 트랜잭션 같은 공통 기능 로직들을 분리하는 것이라고 보면 쉽다.

X기능은 ABC 모두 사용하고, Y기능은 A,C Z기능은 A,B에서 사용한다.

기능을 분리한 다음에 각각 붙여주면 쉽자너? 그게 AoP의 주요 취지다.

  • Aspect : 흩어진 관심사를 모듈화 한 것. 주로 부가기능을 모듈화 한다.
  • Target : Aspect를 적용하는 곳. (클래스나 메서드)
  • Advice : 실질적으로 어떤 일을 해야할 지에 대한 것, 구체화된 부가기능을 담은 구현체
  • JointPoint : Advice가 적용될 위치, 끼어들 지점, 타이밍, 등등
  • PointCut : JointPoint의 상세한 스펙을 정의한 것. "XX메서드 진입 시점에 호출할 것' 이런 느낌

스프링 빈에만 AoP를 적용할 수 있으며, 스프링 IoC와 연동하여 흔한 문제들 (중복코드)에 대한 해결책을 지원하는 것이 목적이라 할 수 있겠다.


PSA (Portable Service Abstraction)

쉽게 말하면 인터페이스 기반으로 설계하라는 거임 서비스를 추상화 시켜서 인터페이스에 의존하면, 유지보수가 깔끔하다.

다시 말하는 것 같지만, 뭔가 정책이 바뀌었을때, DB를 바꿔야 한다면?

DB관련 클래스를 다 고치는게 아니라, DB 인터페이스를 확장해서 만들고, 그 인터페이스를 기반으로 구체화 클래스를 바뀐 DB 클래스로 바꾸면 된다.

다른 서비스 로직들은 인터페이스에 의존적인 상태기 때문에, 내용물이 뭐로 바뀌든 동작함.


스프링은 객체지향적 프레임워크기 때문에, 그 특징이 OOP와 연관돼 있다.

SOLID를 다시 보는 것도 좋을듯

profile
https://crazyleader.notion.site/Crazykwak-36c7ffc9d32e4e83b325da26ed8d1728?pvs=4<-- 포트폴리오

0개의 댓글