지나공 : 지식을 나누는 공간

코루틴의 취소에 대해 알아본다. 코루틴의 취소를 알아야 리소스도 해제할테니 잘 알아두자! Canceling coroutine execution fun maini() = runBlocking { val job = luanch{ repeat(1000) { i -> println("job: I'm sleeping $i ...") delay(500L) } } delay(1300L) println("main : I'm tired of waiting!") job.cancel() job.join() println("main : Now, I can quit") } launch는 코루틴 job을 반환하는데 이 job은 취소하는 기능도 가지고 있다. 1000번을 반복하면서 0.5초 간격으로 숫자를 출력하고, 1.3초 지났..

코루틴을 정리하면 비동기 처리를 순차적으로 간단하게 하고, 콜백을 대체할 수 있는 도구다. 뭐가 편해지는 건지 한번 코드로 확인해보자. 코루틴, 뭐가 편해지는걸까? val user = fetchUserData() textView text = user.name 위처럼 코드를 짜면 참 편하다. 바로 서버를 호출하고, 그 결과를 바로 텍스트뷰에 삽입할 수 있으니까. 하지만 위처럼 할 수는 없다. 서버를 호출하는 부분은 네트워크 부분이기 때문에 NetworkOnMainThreadException이 발생하기 때문이다. 지난 포스팅에서 말했듯, 네트워크 작업은 main thread가 아니라 IO thread에서 작업하는 것이다. 근데 지금은 메인스레드에서 네트워크 콜을 하고 있네? 문제다. fetchUserData..

코루틴(Coroutine)? 실행의 지연과 재개를 허용함으로써, 비선점적 멀티태스킹을 위한 서브 루틴을 일반화한 컴퓨터 프로그램 구성요소. 이제 진하게 칠한 단어를 하나씩 공부해보자! 1. 루틴과 서브루틴? 프로그램은 보통 크고 작은 여러가지의 루틴을 조합시켜서 성립되는데 여기서 메인 루틴과 서브루틴으로 나뉜다. 메인 루틴 : 프로그램 전체의 개괄적인 동작 절차를 표시하도록 만들어진 루틴. 서브 루틴 : 반복적인 특정 기능을 모아서 별도로 묶인 루틴. 서브 루틴은 별도의 메모리에 해당 기능을 모아 놓고 서브루틴이 호출될 때마다 저장된 메모리에 이동한 뒤 다시 return을 통해 원래 호출자의 위치로 돌아온다. 서브루틴은 함수와 비슷하다. 코루틴도 루틴의 일종인데, 3가지 차이점이 존재한다. 메인 - 서브..

REST API 의 장점 학습과 사용이 매우 쉽다. 자유도가 높아 원하는 대로 사용 가능하다. json이 응답으로 오면 파싱할 필요도 없다. REST API의 문제점 너무 자주 바뀌는 API (서버에서 자꾸 변경할 때가 많음) 너무 높은 자유도 버저닝(이 가능하긴 하나 손이 너무 많이 감) api 문서를 만들 수는 있으나 코드랑 너무 떨어져 있으니 죽은 문서가 됨 그래서 나온 게 바로 IDL(Interface Description Language) 라고 하는 인터페이스 정의 언어이다. 이것의 큰 장점은 언어에 종속되지 않고 컴포넌트 사이의 통신을 가능하게 한다. 그럼 우리는 이 rest api를 어떤 idl을 사용해서 표현할 수 있을까? 라는 고민을 한다. 첫 번째는 open API로, 그 장점은 아래와..

지금까지의 흐름, 객체 지향 설계 원칙을 따를 때 의존성 주입이 왜 필요했는지 정리해보자. 지금까지의 흐름과 DI의 필요성 1. 새로운 할인 정책 개발 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것까진 문제가 없다. 2. 새로 만들어진 정률 할인 정책을 적용할 때 문제 발생 새로 개발한 정률 할인 정책을 적용하려고 했더니, 클라이언트 코드인 주문 서비스 구현체 (OrderSerivceImpl)의 코드도 같이 변경해야 했다. 왜냐면 여기서 직접적으로 DiscountPolicy를 FixDiscountPolicy로 구현하고 있었기 때문이다. 얘를 RateDiscountPolicy로 변경하는 순간 DIP 위반이라는 문제가 발생한다. 3. 관심사의 분리 애플리케이션을 하나의 공연으로 생각하자. ..

김영한 님의 강의를 참고했습니다. 객체지향설계의 원칙은? SRP(Single Responsibility Principle) 단일책임 원칙 한 클래스는 하나의 책임만 가진다. 변경이 있을 때 파급효과가 적으면, 다른 곳에 영향을 덜 미치면 단일책임원칙을 잘 따른것임. OCP(Open/closed principle) 개방폐쇄원칙 SW 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 확장을 하려면 당연히 기존 코드를 변경하는 것 같지만!!! 다형성을 떠올리자. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하잖아? 그런데 문제점이 있다. 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다는 것이다. 그래서 이걸 해결해야 한다. 객체를 생성하고 관계를 맺어주는 별도의 조립, 설..

오늘은 JPA Auditing에 대한 포스팅입니다. 프로젝트를 하다보면 어떤 데이터의 생성시간, 수정시간, 또는 생성한 사람, 마지막으로 수정한 사람을 저장해야 할 때가 있습니다. 예를 들어 공지사항이나 게시글 등을 저장하는 테이블에 게시글이 작성된 날짜와 시간, 작성한 사람, 수정시간과 수정한 사람 등이 필요해요. 회원 가입이나 주문내역을 저장할 때도 마찬가지고요. 생각해보면 게시글이나 주문내역 처럼 사용자가 직접 생성해내는 데이터들은 웬만하면 데이터 생성일과 수정일을 저장하게 되는 것 같습니다. 근데 이걸 모든 엔티티에 매번 컬럼으로 지정해서 코드를 작성하는 건 번거로워요. 생성 시간 수정 시간 저장을 자동화하고 BaseTimeEntity로 만들어서, 이게 필요한 엔티티들은 모두 BaseEntity를..

03장 마지막 JPA Auditing으로 생성시간/수정시간 자동화하기 BaseTimeEntity는 abstract 클래스로, Entity들의 생성시간과 수정시간을 자동으로 관리하는 역할을 한다. @MappedSuperclass JPA Entity 클래스들이 BaseTimeEntity를 상속할 경우 그 필드들인 createdDate, modifiedDate를 컬럼으로 인식하도록 한다. @EntityListeners(AuditingEntityListener.class) BaseTimeEntity 클래스에 Auditing 기능을 포함시킨다. @createdDate Entity가 생성되어 저장될 때 시간이 자동저장된다. @LastModifiedDate 조회한 Entity의 값을 변경할 때 시간이 자동저장된다.

이동욱님의 '스프링부트와 AWS로 혼자 구현하는 웹서비스'를 읽고 기록하고 싶은 내용을 정리했다. JPA는 jpa 카테고리에서 자세하게 다루었으므로 기억하고 싶은 내용만 간단히 적을 예정이다. 1. 주요 어노테이션을 클래스에 가깝게 쓰자 한 클래스에 어노테이션을 여러 개 쓰는 경우가 많다. 그럴 때 순서는 중요할 수록 클래스명에 가깝게 쓰자. @Getter와 같은 롬복 어노테이션은 코드를 단순화시키지만 필수 어노테이션은 아니다. 따라서 @Entity를 클래스에 가깝게 두자. 2. Entity 클래스에서는 절대 setter 메소드를 만들지 말자 현재 위에 첨부한 사진에는 Getter만 있고 Setter는 없다. 무작정 getter/setter를 생성하면 해당 클래스의 인스턴스 값들이 언제 어디서 변해야 하..

이동욱 님의 '스프링 부트와 AWS로 혼자 구현하는 웹서비스'를 읽고 기록하고 싶은 내용을 적은 글입니다. 1. 코드 외 패키지명은 주로 웹사이트 주소의 역순으로 한다. 절대 수동으로 검증하고 테스트 코드를 작성하지 않는다. 테스트 코드로 먼저 검증한 뒤 정말 못 믿겠다 싶을 때 프로젝트를 실행해서 확인한다. 2. 메인 클래스 코드 작성하기 Application 클래스는 앞으로 만들 프로젝트의 메인 클래스이다. @SpringBootApplication 스프링부트가 자동설정되게 하는 어노테이션. 스프링 Bean 읽기와 생성을 모두 자동으로 설정한다. 특히, 이 어노테이션이 있는 위치부터 설정을 읽어가므로 이 어노테이션은 항상 프로젝트의 최상단에 위치해야 한다. SpringApplication.run() m..