Daily Study : 4

IssuedAt : 25 - 09 - 19 (금)

Daily Study : 4

---

JAVA 배열 리펙토링 & 문제 풀이 

(복습 #2)

 

- 생각치도 못한 곳에서 뇌지컬이 딸린 다는 것을 느꼈다.. 

main 클래스가 있는 곳에서 또 다른 메서드를 만든다면 꼭 static으로 만들어서 실행하자..? 

static을 붙이지 않고 메서드를 만든 이후에 계속 main메서드에서 사용하려고 하니까 없다고 뜬다.. 

없다고 할 때 알았어야 했는데.. 아 정적으로 만들어줘야하는구나를.. 

 

" 자바에서 대입은 항상 변수에 들어 있는 값을 복사(참조값만) 해서 전달한다! "

---

Spring AOP란 무엇일까? 

 

AOP 개념, 기술이 탄생한 이유 

 

* 나의 생각 ** 핵심 기능말고 부가 기능을 만들어서 적용한다고 했을 때 부가 기능이 모듈화가 되어 있지 않으면 코드 수정에 있어서 적용 해야 하는 곳이 100개라고 하면 매우 비효율적이게 된다. 그래서 공통 관심사? 공통 기능을 적용하기 위해 탄생한게 아닐까 생각이 든다 ! 

 

* Claude ** AOP 기술이 나오기 전 개발 배경부터 봐야 한다. 로깅, 보안, 트랜잭션 관리, 예외처리 같은 기능들이 여러 클래스와 메서드에 중복되어 나타난다. 비즈니스 로직을 담당하는 모든 메서드마다 로깅 코드를 반복해서 작성해야 했다. 

 

동일한 부가 기능 코드가 곳곳에 흩어져 있기에 로깅 방식을 변경하려면 수십 개의 클래스를 모두 수정해야 하는 상황 발생. 

 

실제 업무 로직보다 부가 기능 코드가 더 많아져서 코드의 본질을 파악하기 어려움. 

 

📒 AOP가 제공한 해결 책 

 

Aspect 로 관심사 분리를 할 수 있다. 로깅, 보안 등의 횡단 관심사를 별도의 Aspect 로 모듈화하여 한 곳에서 관리할 수 있게 되었다. 

 

애노테이션이나 설정을 통해 어떤 메서드에 어떤 부가 기능을 적용할지 선언적으로 지정할 수 있다. 

 

코드의 모듈성을 높이고, 중복을 제거하며, 유지 보수성을 크게 향상시키는 혁신적인 해결책을 제공했다고 한다. 

 

 

📒 어드바이스, 포인트컷 

 

( 어드바이스 ) 우리가 만든 부가기능을 핵심기능 언제 수행할건지 정하는건데, 핵심기능 전/후 일수도 있고 호출하기 전에도 정할 수 있다. 그리고 호출 이후에 성공/실패 여부와 상관없이 정할 수도 있고, 실패시 예외가 발생한 경우만 동작할 수 있도록 설정할 수 있다. 언제 어떻게 할 건지 정하는 것 

 

|  @Around 핵심기능 수행 전과 후 (@Before + @After)

|  @Before 핵심기능 호출 전

|  @After 핵심기능 호출 성공/실패 여부와 상관없이 언제나 동작 

|  @AfterReturning 핵심기능 호출 성공시 리턴값 사용

|  @AfterThrowing 핵심기능 호출 실패시 즉, 예외가 발생한 경우만 동작 

 

( 포인트컷 ) 어디에 수행할 지 정하는 것 

 

 

Spring이 프록시(가짜 혹은 대리) 객체를 중간에 삽입해준다고 한다. 

DispatcherServlet 과 ProductController 입장에서는 변화가 전혀 없다. 

---

API 예외처리란 무엇일까? 

 

( Response 메시지 ) 

 

Start-line ( 상태줄 ) : API  요청 결과 ( 상태 코드, 상태 텍스트 )

( 상태 코드 종류 )

2xx Success -> 성공을 의미 한다. 

4xx Client Error -> 클라이언트의 에러, 즉 잘못된 요청을 의미한다. 

5xx Server Error -> 서버 에러, 즉 정확한 요청에 서버쪽 사유로 에러가 난 상황을 의미한다. 

 

** Spring 에서는 에러를 잘 표현하기 위해 Enum을 제공하는데 HttpStatus 라는 것을 제공한다. **

 

 

@ExceptionHandler : 컨트롤러에서 발생한 예외를 처리하기 위해 사용된다. 

그리고 AOP를 이용한 예외 처리 이다. 

 

그런데 여기서 궁금한 점은 그러면 컨트롤러마다 예외처리를 모두 지정을 해야한다면 이것도 번거롭고 중복되는 코드들인데 방법이 없을까 ?? 

 

* Claude ** @ControllerAdvice, @RestControllerAdvice, 특정 패키지나 컨트롤러에만 적용, 커스텀 ErrorResponse 클래스 사용하는 방법들이 존재한다. 장점으로는 한 곳에서 모든 예외를 처리하게 되어 중복이 제거가 되고, 모든 API에서 동일한 에러 응답 형식으로 일관성이 생긴다. 그리고 예외 처리 로직 변경 시 한 곳만 수정하면 되어서 유지보수성이 올라가게 되고, 비즈니스 로직과 예외 처리 로직을 분리함으로써 관심사가 분리되어서 깔끔한 전역 예외 처리가 가능해진다.

---

Spring의 Global 예외처리 

 

@RestControllerAdvice JSON 형태로 반환을 하고, REST API를 주로 사용하는 프로젝트이기 때문에 RestControllerAdvice를 사용했다. 

 

클래스 레벨 단위의 애너테이션? - 클래스에만 달 수 있고, 메서드에는 달 수 없다. 

클래스 레벨 단위의 애너테이션이란 클래스 선언부 바로 위에 붙이는 애너테이션을 말한다. 클래스 전체에 영향을 미치며, 해당 클래스의 모든 메서드나 필드에 공통으로 적용되는 설정을 담당한다. 

 

대표적인 클래스 레벨 애너테이션으로는 

@Controller, @RestController : 컨트롤러 클래스임을 표시 

@Service : 서비스 계층 클래스임을 표시 

@Repository : 데이터 접근 계층 클래스임을 표시 

@Component : 스프링 빈으로 등록할 클래스임을 표시 

@Configuration : 설정 클래스임을 표시 

@RequestMapping : 클래스 내 모든 핸들러 메서드의 공통 URL 경로 설정 

 

 

모든 컨트롤러에서 발생한 예외를 잡아줄 수 있다. 단 핸들러에 잡아둔 예외 처리 방식에 해당하는 것만 잡아온다. 

 

📒 그래서 Global 하게 예외를 처리하는 이유는 

 

예외처리라는 것을 중앙 집중화 하기 좋다. 관리하는 부분에서 편해진다. 

 

나중에 수정이 일어났을 때 쫒아다니면서 모든 것을 수정하기가 힘들다. 

 

중앙 집중화를 하면 코드 중복을 방지하고 유지 보수성을 올릴 수 있다. 

 

예외 처리를 모듈화 해서 관리하기가 쉽기 때문에 팀프로젝트를 진행하게 될 때 공통적인 예외 처리를 가능하게 한다. 

---

Error 메시지 관리하기 

 

Spring 에서는 에러 메시지를 관리하기 위해 properties 파일을 이용하여 관리할 수 있게 도와준다. 

에러 메시지는 key-value 형태로 작성되며, 작성된 값은 messageSource 를 Bean으로 등록하여 사용할 수 있다고 합니다. 

 

Locale.getDefault() ? 언어 설정을 전달하는 것이고, 해당 메서드는 기본 설정을 가져오는 뜻이다. 

---

HTTP란 무엇일까? 

(복습 #2)

 

데이터를 주고 받는 양식을 정의한 통신 규약중 하나. 통신 규약이란 컴퓨터끼리 데이터를 주고 받을 때 정해둔 약속.

 

HTTP로 데이터를 주고 받는 방법 Request, Response 라는 개념이 항상 존재함. 

 

브라우저는 서버에게 자신이 원하는 페이지(URL등의 정보)를 요구(Request)한다. 

서버는 브라우저가 원하는 페이지가 있는지 확인하고, 있다면 해당 페이지에 대한 데이터를 실어 응답(Response)해준다. 

없다면 없는 페이지에 대한 데이터를 반환. 

 

"데이터"는 어떠한 데이터는 주고 받는게 가능하다. 

 

HTTP 구조에는 Method, Header, Payload가 있다. 

 

Header ( 추가 데이터, 메타 데이터 )

브라우저가 어떤 페이지를 원하는지, 

요청 받은 페이지를 찾았는지,

요청 받은 데이터를 성공적으로 찾았는지,

어떤 형식으로 데이터를 보낼지등등 외에도 아주 다양한 의사 표현을 위한 데이터를 모두 Header 필드에 넣고 주고 받는다. 

 

Payload ( 데이터, 실제 데이터 )

서버가 응답을 보낼 때에는 항상 Payload 를 보낼 수 있다, 

클라이언트( 브라우저 )가 요청을 할 때에도 Payload 를 보낼 수 있고, 

Get Method를 제외하곤 모두 Payload 를 보낼 수 있다는 것이 HTTP 에서의 약속이다. 

HTTP Body 라고도 불린다.  Get Method는 Body 자체가 없다. 

---

테스트 코드

(복습 #2)

 

버그라는 것은 소프트웨어가 예상하지 못한 결과를 내는 것 소스코드나, 설계 과정에서의 오류 때문에 발생합니다. 

 

스프링 부트에서는 버그를 잡아내기 위해 테스트 코드를 작성해야 하는데 junit5 이 도와줍니다. 

 

테스트 하는 기준에는 여러 가지가 있는데, 그 중 엣지 테스트라고 하는 것은 계산기라는 기능을 구현 했을 때 덧셈, 뺄셈, 나누기, 곱하기등 기능 들을 하나 하나 다 테스트 해보는 것이다. 

---

Lombok과 application.properties

(복습 #2)

---

스프링 MVC란 무엇일까?

(복습 #2)

 

많은 스프링 강의들을 봐보면 디자인 패턴중 MVC패턴만이 자주 나오는 것을 볼 수 있을 것이다. 

오늘 갑자기 이런 생각이 들었다. 

 

많고 많은 디자인 패턴중 스프링 부트는 왜 MVC패턴을 고집하는 것일까

고집한다고 생각하는 건 착각인가 하고 자료들을 찾아보았다. 

 

 

📒 스프링 부트가 MVC패턴을 선호하는 이유 !

 

관심사의 분리가 첫 번째 이유이다. 

Model : 데이터와 비즈니스 로직

View : 사용자 인터페이스( 템플릿, JSON 응답 등)

Controller : 요청 처리 및 흐름 제어 

 

각 역할이 분리되어 코드가 깔끔하다. 

 

스프링 프레임워크의 철학이 두 번째 이유인데,, 

스프링은 제어의 역전( IoC )과 의존성 주입( DI )을 기반으로 설계되었는데, MVC 패턴이 이런 철학과 잘 맞아 떨어진다고 한다. 

 

그리고 웹 개발에 최적화가 되어 있다고 한다. 

@Controller, @Service, @Repository 애너테이션으로 각 계층을 명확하게 구분한다. 

 

* Claude ** 웹 애플리케이션 특성상 HTTP 요청/응답 구조와 자연스럽게 매칭이 된다고 한다.

RESTful API구조와 완벽하게 맞아 떨어지며, 대부분의 웹 개발 시나리오에 충분하다고 한다. 

 

 

사용자(클라이언트)가 Request 요청을 하면 서블릿 컨테이너는  HttpServletRequest, HttpServletResponse 객체를 생성하는데, 약속된 HTTP 규격에 맞추면서 쉽게 HTTP에 담긴 데이터를 사용하기 위해 만든 객체이다. 

 

HTTP 는 약속이 된 규격. 

 

서블릿이 대신해서 HTTP를 분석하고 그 안에 들어있는 사용해야할 데이터, 정보들을 HttpServletRequest 객체에 담아준다. 

HttpServletResponse를 굳이 처음에 같이 만드는 이유는 결과에 대한 응답도 해야하기 때문에 같이 만들어 둔다고 한다. 

---

인텔리제이 얼티밋 버전 사용하기

 

나중에 커뮤 버전으로 돌아왔을 때 대비 하여 얼티밋 버전과 커뮤 버전의 호환이 안되는 부분 해결하기 위함 링크 하나 첨부 ..

https://dani0312.tistory.com/81

[Intellij] 인텔리제이 ultimate 만료 후 community 버전 사용하기

 

.idea 파일을 삭제해서 다시 그 파일을 인텔리제이에서 열거나 

 

file -> new -> project from Existing Sources... 를 실행하면 된다.