8장 메서드 아이템 49 - 매개변수가 유효한지 검사하라 메서드 몸체가 실행되기 전에 매개변수를 확인하면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 자바 7에 추가된 java.util.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다. 메서드나 생성자를 작성할 때 그 매개변수들에 어떤 제약이 있을지 생각해야 하고 그 제약들은 문서화하고 코드 시작 부분에서 명시적으로 검사해야 한다. 아이템 50 - 적시에 방어적 복사본을 만들라 클라이언트가 여러분의 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다. 가변 필드를 생성자 매개변수로 받아 클래스 필드에 저장하는 경우 각각을 방어적으로 ..
아이템 42 - 익명 클래스보다는 람다를 사용하라 함수 객체와 람다식 함수 객체 : 추상 메서드를 하나만 담은 인터페이스로 람다식이 등장하기 전에는 익명 클래스를 사용해서 주로 만들었음 Collections.sort(words, new Comparator() { public int compare(String s1, String s2) { return Integer.compare(s1.length(), s2.length()); } }) 자바8에와서 추상 메서드 하나짜리 인터페이스는 특별한 의미를 인정받아 특별한 대우를 받게됨 람다식을 이용해서 훨씬 간결한 코드를 만들 수 있게됨 Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.leng..
개념 MySQL Enum 타입은 Java enum 타입과 비슷한 유형이다. 컬럼 정의 시 다음과 같이 enum 컬럼에 들어갈 수 있는 항목들을 정의한다. CREATE TABLE shirts ( name VARCHAR(40), size ENUM('x-small', 'small', 'medium', 'large', 'x-large') ); enum 컬럼도 empty string이나 null값 삽입 가능하고 empty string은 유효하지 않은 값으로 취급된다. enum 항목이 없어지면 기존에 있던 삭제된 그 항목을 가지고 있던 컬럼값은 유효하지 않은 상태(empty string)로 변경된다. 다음과 같이 index값을 가지고 올 수 있다. index는 enum 정의 시 해당 항목의 위치값이다. SELECT..
스프링 배치 잡을 실행할 때 MyBatis 쿼리 실행 부분에서 다음과 같은 오류가 발생하는 경우가 있었다. cannot change the ExecutorType when there is an existing transaction이 에러는 존재하는 트랜잭션이 있을 경우 MyBatis의 ExecutorType (SIMPLE, BATCH, REUSE) 을 변경할 수 없다는 의미이다. 원인 스프링 배치 잡에서만 날 수 있는 오류는 아니고 MyBatis를 사용하고 트랜잭션 설정된 부분이 있다면 발생할 수 있을 것이다. 트랜잭션으로 묶여있는 범위 내에서는 배치 잡 내에서 동일 데이터 소스에 대해서는 동일 SqlSessionTemplate을 사용하게 될 것인데, ExecutorType은 SqlSessionTempl..
웹 사이트 서버와 모바일 앱 API 서버는 기술적인 부분에서 비슷한 부분이 많지만 앱 API 서버라는 특성 때문에 조금 신경 써야할 부분도 있기에 API 디자인 시 참고할 만한 내용들을 찾아보고 정리한 내용이다. API 서버는 한번 API가 클라이언트에게 나가고 나면 변경하기가 힘들다.웹 사이트는 클라이언트 코드와 서버 코드 모두 웹 서버에서 제공하기 때문에 두 부분을 동시에 변경하는 것이 가능하지만, 앱 같은 경우에는 일반적으로 앱 스토어를 통해서 배포되기 때문에 동시에 변경할 수도 없고 사용자가 업데이트 하지 않으면 계속해서 구 버전을 사용할 수도 있다. 앱을 업데이트하지 않으면 사용할 수 없도록 강제 업데이트하는 방법이 있긴 하지만 되도록이면 피해야 한다. REST를 준수하는 것은 좋지만 그것을 목..
클린 코드 책으로 유명한 로버트 마틴의 책 클린 코더에 대한 독서 노트이다.최근 클린 아키텍처라는 책도 나오면서 클린 트릴로지?(클린 코드, 클린 코더, 클린 아키텍처)가 완성되는 듯하다. 소프트웨어는 너무 복잡해서 오류가 생길 수 밖에 없다. 안타깝지만 너무 복잡하다는 이유로 책임이 사라지진 않는다. 완벽하지 않다는 사실에 책임을 져야한다. 완벽한 소프트웨어를 만드는 것이 사실상 불가능하다는 것이지 완벽하지 않아도 괜찮다는 뜻은 아니다. 경력을 쌓아가면서 오류를 만드는 비율을 0에 가깝게 만들어야 한다. 코드에 결함이 있는걸 알면서도 QA에게 코드를 보내는 일은 매우 프로답지 못한 행동이다.반성하게 되는 부분이다.. 제대로 작동하는지 아닌지 알아야 한다. 알려면 어떻게 해야할까? 테스트하고 또 테스트하..
