늘

스프링과 JPA로 애플리케이션을 개발하다 보면 프록시에 대해서 많이 만나게 된다. 이와 관련되어 구글링을 해보면 게시글들마다 다른 말을 해서 직접 정리해보려고 한다. - 총정리 스프링 AOP는 [런타임에 프록시 인스턴스가 동적으로 변경되는] 다이나믹 프록시 기법으로 구현되어있다 인터페이스의 유무에 따라 다음과 같이 나뉜다. 1. JDK 다이나믹 프록시 2. CGLIB JDK Dynamic Proxy JDK에서 지원하는 프록시 생성 방법 Invocation Handler를 재정의한 invoke를 구현하여 부가기능 수행 Reflection API 사용 인터페이스를 통해서만 프록시 생성 가능 CodeGenratorLibrary(CGLIB) 상속을 기반으로 프록시 생성 final이 붙으면 오버라이딩이 불가능하므..

1. RestDocs vs swagger 스웨거와는 다르게 프로덕션 코드에 어노테이션을 붙이지 않아서 좋다! 스웨거를 사용하면 뭔가 프로덕션 코드에서 테스트를 위한 코드가 짜여진 느낌?이 든다. 레퍼런스가 많다! - 여러 레퍼런스들을 참고했었는데 자료들이 많아서 쉽게 적용할 수 있다! 운영 코드를 퓨어하게 가져가고 싶다면 레스트 독스를 사용하고 이를 포기하더라도 테스트 코드를 짜고 관리하는 비용을 지불할 경우에는 스웨거를 사용하는 느낌이죠. 2. 잦은 api요청의 영향 API 요청 하나도 내부 서버에서 무거운 로직을 실행하거나 DB를 오래 조회하는 쿼리를 날린다면 성능에 무리가 될 수 있어요. 또한 사용자도 기다리는 시간이 늘어나서 좋지 않은 경험을 하겠죠. 물론 요청의 개수도 성능에 영향을 미쳐요. D..

Reflection API란? 구체적인 클래스 타입을 알지 못해도 그 클래스의 정보(메서드, 타입, 변수 등등)에 접근할 수 있게 해주는 자바 API다. 사용하는 Library, Framework, API, Feature Jackson, GSON 등의 JSON Serialization Library Log4 j2, Logback 등의 Logging Framework Apache Commons BeanUtils 등의 Class Verification API Spring의 @Autorwired와 같은 DL, DI 기능 (: processInject(), inject() Method ) Spring Contatiner의 BeanFactory에서 사용 내부적으로 Spring의 ReflectionUtils라는 A..

@JdbcTest @Sql("/schema.sql") class RoomDaoTest { @Autowired private JdbcTemplate jdbcTemplate; private RoomDao roomDao = new RoomDaoImpl(jdbcTemplate); } 위 코드는 현재 NPE가 발생합니다. 반면에 아래 코드처럼 텍스트픽쳐스를 이용한 테스트는 정상 동작합니다. @Sql("/schema.sql") @JdbcTest class PieceDaoTest { @Autowired private JdbcTemplate jdbcTemplate; private PieceDao pieceDao; @BeforeEach void setUp(){ pieceDao = new PieceDaoImpl(jdbcT..

1. 의존성 주입 방법 setter를 통한 주입 생성자를 통합 주입 필드를 통한 주입 스프링 공식 문서에서도 생성자를 통한 주입을 추천한다고 한다. 생성자를 통한 장점으로는 아래와 같다. setter를 통한 주입과 달리 필드에 final을 선언해줄 수 있고 불변으로 만들 수 있다는 장점이 있다. 결합도를 낮춰 테스트 코드 작성에 용이해지는 장점이 있고 null을 주입하지 않는 한 NPE가 발생하지 않도록 보장해준다. 순환 참조가 발생하면 애플리케이션 실행 시 미리 알려주기 때문에 예방할 수 있다. 왜냐하면 생성자 주입 방식은 객체가 생성되고 필요한 빈을 빈팩토리에서 생성해서 생성자를 찾아 주입하기 때문이다. 반면에 다른 2가지 방법들은 빈이 먼저 생성된 이후에 객체가 생성되고 주입이 되기 때문에 빈을 생..

테스트 코드 @DisplayName()을 사용하면 아스키코드 warning이 안뜨므로 운영할떄 로고가 안찍혀서 좋다. 리펙토링을 할때는 기존의 테스트 코드가 깨지지않도록 해야한다! private 매서드 테스트할떄 로직을 테스트 코드 작성하는 곳에 가져와서 테스트를 돌려본다.. JDK11 타입 추론 final을 붙여서 타입 불변으로 해주는게 좋다. 뭐든 커지면 의심하자 패키지가 커지면 응집도에 관해 의심해보고, 매서드가 커지면 단일책임 원칙에 대해서 의심해보자... Static 언제 사용하는게 좋나? util 클래스와 같은 곳 , 상태관리를 안해도 되므로, 생성자를 private으로 하여 인스턴스화를 막기도 한다.(util이라는 것을 명확히 보여주기 위해) 값을 비교할 때, 이상? 초과? 어떤 방식을 이용..

Level 1의 마지막 미션으로는 체스 미션을 진행했다. 1단계에서는 콘솔 창에서 명령어를 입력해서 체스 게임을 할 수 있도록 구현했다. 2단계에서는 1단계에서 작성했던 도메인을 기반으로 자바 spark로 jdbc를 이용해 db와 연동되도록 구현했다. 1. 상황에 적절한 예외를 던지자. 이펙티브 자바에 의하면 IllegalArgumentException은 허용하지 않는 인수가 들어오는 경우 IllegalStateException은 객체가 메서드를 수행하기에 적절하지 않은 상태인 경우 UnsupportedOpertionException 은 호출한 메서드를 지원하지 않을 때 사용한다. 위 코드는 한 번 override된 메서드이므로 UnsupportedOperationException보다는 IllegalSt..

평소에 runtimeOnly는 런타임 때 작동하겠지, implementation은 gradle이 돌아갈 때부터 작동하겠지라고 대충 생각하고 넘겨와서 그런지 막상 퀴즈를 받으니 대답을 못하겠다.. 이번 기회에 공부하고 정리해보려고 한다. 일단 gradle에 의존성부터 확인해 보았다. 일단 눈에 띄었던 것은 빨간 박스로 표시한 것처럼 runtimeClasspath에 implementation으로 선언된 의존성 파일들이 들어있었다. 대충 implementation은 시작부터 runtime때까지 의존성이 살아있는구나(?)라고 생각했다. CompileClasspath 에러 없이 컴파일을 하기 위해 필요한 클래스와 jar들의 위치를 나타낸다. compileClasspath만 잘 설정했다고 애플리케이션이 잘 작동하는..

우테코 나와 맞을까? 옷을 멀리서 보기만 해서는 나와 사이즈가 맞는지 알 수 없다. 직접 입어 보기 전까지는 모른다. 처음 우테코를 지원할 때만 해도 전공자이고 스프링 공부도 하고 있었기 때문에 쉽게 적응할 것이라고 생각했다. 하지만 1단계, 2단계 미션이 진행될수록 여유로움은 점점 사라지고 안일했던 나를 반성하게 되었다. 나에게 작아 보였던 우테코라는 옷은 나에게 맞지 않은 큰 옷처럼 보였다. 맞지 않은 옷 초등학교시절 엄마와 옷을 사러 가면 엄마는 항상 소매보다 긴 옷을 사 입혔다. 그때는 왜 옷을 크게 사주는지 몰랐지만 지금은 알 수 있다. '유년기 시절에는 빠르게 성장하기 때문에 미리 큰 옷을 사 입힌 것이었다.' 처음 ot를 시작으로 메타버스에서의 활동, 보이는 라디오, 온라인 회식, 페어 프로..

1. 자료구조를 사용하자 여러 값들을 담을 때 생각없이 매번 List를 쓰는 버릇을 고쳐야겠다. 적절한 자료구조를 사용하면 코드가 많이 줄여지고 깔끔해진다. 2. 정적 팩토리 매서드 네이밍 정적 팩토리 메서드 명명 규칙 from : 매개변수 하나를 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 ex) Date date = Date.from(instant); of : 매개변수 여러개를 받아서 적합한 타입의 인스턴스를 반환하는 집계 메서드 ex) Set cards = EnumSet.of(JACK, QUEEN, KING); valueOf : from과 of의 더 자세한 버전 ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE); instance o..