kth990303의 코딩 블로그

기본적이지만 놓치기 쉬운 부분을 기록해보려 한다. 이해하기 쉽게 예시를 들어, 코드와 함께 상황극으로 설명하려 한다. 아래와 같은 코드가 있다.1234567891011121314151617181920@Getterpublic class BoulderingCrewSignupRequest {     private ListLong> memberId;    private String crewName;     public BoulderingCrewSignupRequest(ListLong> memberId, String crewName) {        this.memberId = memberId;        this.crewName = crewName;    }     public static Bouldering..

아는 지인 중 샤인(https://github.com/zbqmgldjfh)이랑 수지누나(https://github.com/sujileelea)가 발표한다고 해서 참여한 행사. GDSC Konkuk 리더이신 현우님(https://github.com/l2hyunwoo) 이 준비하신 걸로 알고 있다. (맞나?) 샤인이 발표하는 헥사고날 아키텍처는 우리 팀의 일부 프로젝트에서 사용하기도 하고, 샤인이 발표하기도 해서 들어보려고 하고, Vision Pro로 접해보는 공간 컴퓨팅도 수지누나가 발표하고, 아예 새로운 분야여서 들어보기로 했다. 그리고 CS와 함께하는 BE 이야기 세션은 흥미로워보여서 중간에 2시부터라도 들어보려 했다. 일정 상 12시부터 3시까지만 참여하긴 했지만 이에 대해 후기를 적어보려 한다. ..

jdk 1.7 이하, 즉 Java 8 이전 버전에서의 JVM 메모리 구조(Runtime Data Area)와 Java 8 이후의 JVM 구조는 아래와 같은 차이가 존재한다. Eden 영역과 Survivor, Old 영역의 존재는 변함이 없다. 하지만 Java 8 이후부터는 Permanent Heap(이하 Permgen) 영역이 제거되고 Metaspace 영역이 생성된 것이다. 특히 눈여겨볼만한 점은 Permgen은 Heap 영역에 속했었는데 Metaspace는 Native Memory 즉 OS 관리대상에 속한다는 것이다. 근데 Permgen(Java 7 이하), Metaspace(Java 8 이후)가 뭐하는 녀석인데? 여기서 잠깐, Permgen (Metaspace)에서는 무엇을 관리하는걸까? 자, 잠깐..

Java, Kotlin은 둘 다 JVM 생태계 언어로써 상당히 비슷한 면이 많다. 하지만 둘은 다른 언어다보니, 당연히 다른 점들도 꽤 많이 존재한다. kotlin의 null-safe operator로 편리하고 안전하게 null 관련 처리를 할 수도 있고, 확장함수를 통해 자유롭게 커스터마이징이 가능하며, 다양한 lambda functions를 제공해줌으로써 Java의 stream 기능 못지 않게 간단한 코드를 작성할 수 있다. 그럼 반대로 Java에선 제공해주지만 Kotlin에서는 제공하지 않는 기능이 뭐가 있을까? Java에서는 checked exception을 제공하지만, Kotlin에서는 이를 제공하지 않는다! 이번 포스팅에선 이 내용에 대해 적어보도록 하겠다. Checked Exception? ..

친구와 얘기하던 중, Spring IoC, DIP 개념에 대한 얘기가 나왔다. 이 개념들은 구글링하면 워낙 잘 정리된 글들이 많아 별도로 작성하지 말까 고민도 했다. 하지만 해당 개념들은 객체지향에서 매우 중요하기 때문에 한번쯤은 포스팅하는 것이 좋을 듯하여 정리해보려 한다. IoC(제어의 역전) Inversion of Control, 즉 IoC는 제어의 역전이라고 번역된다. 쉽게 말하자면 어떤 객체에 대한 관리를 나 대신 다른 애한테 맡긴다는 것이다. 스프링을 쓴다면 스프링에게 특정 객체의 생성과 소멸을 빈으로 등록해 맡겨주는 것으로 생각하면 된다. 즉, 제어권을 내가 아닌 스프링 컨테이너에게 빈의 생성, 의존 관계 설정을 맡기는 것이므로 IoC가 이루어지는 것이다. 스프링을 사용하지 않는다고 하더라도..

그동안 나는 단위 테스트만을 진행해왔다. 도메인 로직이 잘 실행되는지 junit 문법의 Assertions로 테스트해왔다. dao test는 @JdbcTest를 이용하여 단위테스트를 했고, service test는 fake 객체를 만들어주어 단위 테스트를 진행해주었다. 그런데 컨트롤러는 @RestController에서 @RequestBody로 request를 받고, ResponseEntity를 넘겨주기 때문에 웹 애플리케이션을 직접 실행하면서 테스트하지 않는 이상, 어떻게 테스트해야할지 감이 오지 않았다. RestAssured를 이용하면 API response의 statusCode뿐만 아니라 body에 올바른 값이 담기는지도 테스트가 가능하다! 이번 시간에는 Spring 환경에서의 RestAssured를..

문제 상황 스프링 환경에서 jdbcTemplate을 이용하여 애플리케이션을 생성하고 있었다. 그러던 도중, dao test코드에서 아래와 같은 에러가 발생했다. 웃긴 건, 애플리케이션 실행 자체는 정말 잘 된다는 점이다. groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-xml is loaded in version 4.0.1 and you are trying to load version 3.0.10 dao 테스트 코드에서만 위 에러가 뜨면서 실패한다. 문제 원인 build.gradle의 rest-assured 버전이 문제였다. testImplementation 'io.rest-assured:rest-assured..

호호 스터디에서 Chapter 6: DI와 서비스 로케이터를 듣기 전에, 미리 책을 읽고 공부한 내용을 기록한 포스팅이다. DI와 서비스 로케이터 각 객체들을 사용하기 위해선 어떤 방법이 좋을까? 아무 생각없이 객체를 생성하고 의존하게 될 경우, Chapter 5에서 배웠던 DIP(의존 역전 원칙), OCP(개방 폐쇄 원칙), SRP(단일 책임 원칙) 등 SOLID 원칙을 어기게 되고, 변경에 유연하지 못한 코드가 만들어질 확률이 높다. 특히, 순환 의존이 발생할 경우, 요구사항이 수정되거나 변경될 경우 모든 객체의 코드를 수정해야 될 수도 있다. 이번 시간에는 DI(Dependency Injection), 서비스 로케이터를 이용한 객체 사용 방법에 대해 알아보도록 하겠다. Service Locator ..

호호 스터디에서 Chapter 5: 설계 원칙: SOLID를 듣기 전에, 미리 책을 읽고 공부한 내용을 기록한 포스팅이다. SOLID 원칙 어떻게 보면 귀에 딱지가 앉을 정도로 많이 들어서 너무 뻔하게 느껴질 수 있다. 하지만 막상 코드를 짤 때는 자신도 모르는 사이에 잘 지켜지지 않는 경우가 많다. 애초에, 객체의 값을 꺼내지 말고 메시지를 던지라는 것조차도 코드를 짜다보면 잘 안지켜지는 경우가 많은 것처럼 말이다. 이번 포스팅에서 SOLID 원칙을 살펴보긴 하겠지만, 제일 좋은 건 실전을 통한 많은 경험을 해보는 것인 듯하다 :) 단일 책임 원칙 (Single Responsibility Principle : SRP) 클래스는 단 한 개의 책임을 가져야 한다. 객체지향적인 코드를 짜기 위해 최대한 책임..

VO(Value Object)란, 도메인에서 속성들을 묶어서 값을 나타내는 객체이다. 사실 나는 VO에 대해서 단순하게 "도메인 중에서 가장 기본이 되는 객체" 정도로만 알고 있었는데, 이번에 우아한테크코스 미션을 진행하면서 VO 개념을 정립할 수 있었다. VO란 무엇일까? 사실 VO의 개념에 대해선 이 글이 정말 잘 정리가 돼있다. https://tecoble.techcourse.co.kr/post/2020-06-11-value-object/ VO(Value Ojbect)란 무엇일까? 프로그래밍을 하다 보면 VO라는 이야기를 종종 듣게 된다. VO와 함께 언급되는 개념으로는 Entity, DTO등이 있다. 그리고 더 나아가서는 도메인 주도 설계까지도 함께 언급된다. 이 글에서는 우선 다 tecoble...