[Spring 기초 이론] Spring

 

Spring은 프레임워크이다.

Java 기반의 웹 프레임워크

Spring makes Java simple.

스프링은 오픈소스이다. 

무료, 기여 가능

 

IoC (Inversion of Controll)

Class가 설계도라면 Object는 실체화 가능한 것이다. 

 

실체화가 가능한 것이란?

예를 들어 제드를 만들기위한 설계도인 제드 class가 있으면 제드는 실제로 게임에 등장하니까 실체화가 가능한 것, 즉 Object이다. 반면 캐릭터라는 것은 많은 것들을 포함하는 추상적인 class이고 제드, 누누 등은 전부 캐릭터라고 불린다. 캐릭터는 추상적인 것이기 때문에 실제로 게임속에 존재할 수 없는 것이라서 실체화가 불가능하다. 

 

Instance는 실체화 된 것을 의미한다. 제드가 실제로 협곡에 존재하면 실체화가 된 것이다.

 

IoC는 제어의 역전을 뜻하며 스프링이 주도권을 가지고 있음을 의미한다.

 

주도권이 스프링에 있다는 것은 무슨 의미일까?

내가 Object를 직접 new를 해서 heap이라는 메모리 공간에 올리는 상황을 가정해보자

public void make {
	제드 s = new 제드();
}

이렇게 되면 만들어진 제드의 주소는 레퍼런스 변수 s이다. 이 s는 new를 한 make 메서드 내부에서 관리한다. 

 

만약 다른 use라는 메서드에서 이 제드를 사용하고 싶다면 어떻게 해야할까?

public void use {
	제드 s = new 제드();
}

use에서 새로 new를 해서 제드를 만들면 make의 제드와 다른 제드가 만들어진다. 즉, 공유가 힘들어지는 것이다. 

 

 

여기서 스프링의 IoC기능으로 이런 문제를 해결해준다. 

제드, 누누, 아리 등 수많은 Object들을 내가 클래스로 만들어뒀을 때 스프링이 이것을 전부 스캔해서 스프링이 직접 heap 메모리 공간에 객체를 직접 생성하고 관리해준다. 

 

 

DI (Dependency Injection)

 

스프링의 IoC에 의해 딱 한번만 스프링에서 띄우고 그 이후엔 내가 원하는 모든 클래스의 메서드에서 스프링에 띄운 객체들을 가져와서 사용할 수 있다.

여기저기에서 같은 객체를 요청해도 같은 객체가 반환되어서 공유되는 것이다.

 

이렇게 필요한 곳에서 가져다 쓰는 것을 DI라고 한다. 

 

 

수많은 필터

스프링에는 검열을 해주는 필터 기능을 지원한다. 필터는 문지기 역할을 하기 때문에 어떤 임무, 조건에 따라 검열을 해준다. 

 

스프링 자체가 사용하는 필터도 있고, 사용하지 않는 필터를 활성화해서 사용할 수도 있고, 직접 필터를 생성하여 사용할 수도 있다.

 

 

수많은 어노테이션

어노테이션은 컴파일러가 무시하지 않는 주석으로 추가적인 정보를 제공해주는 메타데이터이다. 

• 어노테이션으로 에러 잡기 - 컴파일 체킹

class Animal {
    run();
}

class Dog extends Animal {
    @Override
    run();
    
    @Override
    fly();  // 에러!!!
}

 

• 어노테이션으로 객체 생성 in 스프링
  • @Component : 스프링이 해당 클래스 스캔 후 heap 메모리에 로딩
  • @Autowired : 로딩된 객체 해당 변수에 주입
  • 등등

@Component
class A {
    
}

@Component
class B {
    @Autowired
    A a;
}

 

B 클래스를 스캔할 때 B 클래스 내부를 분석(리플렉션)해서 어떤 메서드, 필드, 어노테이션이 있는 지 체크 후 그에 따라 적절한 작업을 수행한다.

 

여기서는 @Autowired가 있으니까 로딩된 객체를 해당 변수에 집어 넣어야 하니까 스프링 컨테이너를 쭉 읽어서 A 타입을 가진 객체가 있는 지 확인하고 없으면 null, 있으면 주입해준다 -> DI

 

MessageConverter (기본값 : Json)

영어권에서 접속한 사람과 한국에서 접속한 사람이 메세지를 주고 받으려면 MessageConverter 기능이 필요하다. 

한국어 -> 영어, 영어 -> 한국어로 직접 번역하는 것은 너무 비효율적인 작업이므로 중간 언어, 즉 중간 데이터로 번역해서 통신한다. 중간 데이터는 모든 나라가 이해할 수 있는 데이터이다. 

 

중간 데이터로 옛날엔 xml로 사용했는데 요즘은 거의 Json을 사용한다. 

 

Java Object와 Python Object는 서로 다르니까 중간 데이터 Json Ojbect로 변경해서 보내면 받고 나서 Json Object를 자신의 언어 Object로 바꿔서 해석한다.  

스프링은 MessageConverter 기능을 라이브러리로 지원한다.

 

 

BufferedReadr, BufferedWriter의 쉬운 사용

각 언어마다 통신 단위가 다 다르다. 한국은 한 문자에 16bit가 필요해서 2Byte가 필요하고 영어는 한 문자가 8bit면 2의 8승 즉 256가지의 문자 전송이 가능해서 1Byte면 가능하다.

 

각 언어별로 통신 단위가 달라서 전 세계적으로 통신하는 것이 불가능하니까 유니코드에서 utf-8이라는 인코딩을 지원해준다. 

 

JAVA의 인코딩

• Java는 내부적으로 문자열을 UTF-16 으로 인코딩
• 문자열 송/수신을 위해 직렬화가 필요할 때에는 변형된 UTF-8 사용
• 문자열을 입출력할 시 운영체제 기본 인코딩 값, 또는 사용자 지정 인코딩 값으로 문자열 인코딩
• 입력(UTF-8) -> 송수신(modified UTF-8) -> 자바 메모리 (UTF-16) -> 송수신(modified UTF-8) -> 출력(UTF-8)

 

System.in과 InputStream

데이터의 흐름을 Stream이라고 하는데 입력과 출력이 동시에 가능하다.

Java에서 입력 스트림은 기본적으로 InputStream을 사용한다. (출력은 OutputStream)

 

System.in은 InputStream 타입의 정적 필드로 키보드 등에서 입력을 넣어주는 것들을 System.in으로 연결한다. 하지만 InputStream의 입력 메소드인 read()는 1 Byte 단위로 읽기 때문에 나머지 데이터는 입력받지 못한다. 또한 InputStream으로 받고 char로 캐스팅하는 과정이 매우 복잡하다. 

 

InpubStreamReader

InputStream가 문자 그대로 읽지 못하기 때문에 사용하는 방법

 

InputStreamReader는 Byte를 문자 하나로 바꿔서 입력받는다. 배열로도 여러 개의 문자를 받을 수 있다. 하지만 배열은 선언할 때 크기를 정해줘야 하기 때문에 최대 크기로 지정해주면 메모리 낭비가 심할 것이다. 

 

 

BufferedReader

결국 사용하는 것은 BufferedReader를 사용하는데 이것은 가변길이의 문자를 받을 수 있다. Buffer를 통해 입력받은 문자를 쌓아둔 뒤 한 번에 문자열처럼 보내버리는 것이다. 

 

보통 입력 메소드로 readLine()을 많이 쓰는데 이 메소드는 공백을 포함한 한 줄 전체를 읽기 때문에 char 배열을 하나하나 생성할 필요 없이 String으로 바로 return하여 받을 수 있다는 장점이 있다. 

 

따라서 데이터를 담고있는 요청이 오면 BufferedReader로 이 입력을 받아야 한다. 마찬가지로 데이터를 쓸 때에도 BufferedWriter를 사용한다. 

 

 

스프링은 @ResponseBody라는 어노테이션으로 BufferedWriter를 동작시킬 수 있다. 데이터를 받을 때에는 @RequestBody 어노테이션으로 BufferedReader를 통해 입력받을 수 있다.

 

 

 

출처

[무료] 스프링부트 개념정리(이론) - 인프런 | 강의

JAVA [자바] - 입력 뜯어보기 [Scanner, InputStream, BufferedReader]