JAVA/이펙티브 자바

Java. 예외처리 주의점

프로그램을 작성하면서 예외 처리는 항상 까다롭고 귀찮다. 하지만 그만큼 중요하다. 나도 서버를 만들 때 마다 어떤 방식으로 예외처리를 해야 정확하고 깔끔할까 항상 고민한다. 주의할 점들을 알아보자. 예외는 진짜 예외 상황에만 사용하자 1. 예외는 예외 상황에 쓸 용도로 설계되었으므로 JVM 구현자가 최적화를 하지 않았을 수 있다. 2. try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다. 3. 배열을 순회하는 관용구는 중복 검사를 수행하지 않게 최적화한다. 예외는 예외상황에서만 사용하고, 일상적인 제어 흐름용으로 사용하지 마라. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야한다. 필요 없는 검사 예외 사용은 피하라 검사 예외를 잘 사용하..

Java. 오버로딩, 오버라이딩은 신중히 사용하자 ( 다중 정의 )

오버로딩과 오버라이딩은 개발자 면접 질문을 검색해보면 항상 들어있는 녀석들이다. 상속을 사용하며 오버라이딩은 자주 사용했지만, 오버로딩은 정의 정도만 달달 외우고 가끔씩 사용했기 때문에 주의점에 대해 깊게 생각해본 적이 있었나 싶다. 여러 우회할 수 있는 방법들이 있기 때문에 지나쳐왔지만 한번 짚어보고 가도록 하자. 오버로딩 문제의 예제코드 static class CollectionClassifier { public static String classify(Set s) { return "집합"; } public static String classify(List s) { return "리스트"; } public static String classify(Collection s) { return "그 외 컬렉..

Java. 명명규칙은 통용되는 것으로 지키자.

처음 개발을 시작할 때는 명명규칙이 이렇게나 중요하다는 것을 잘 몰랐다. 흔히 통용되거나 그룹에서 따로 지정해놓은 명명규칙을 잘 지키면 아무 문제가 일어나지 않지만, 제대로 지키지 않으면 무시무시한 일이 일어난다. 일단 시니어의 말을 빌려보자면 코드에서 똥냄새가 난다고 한다. 아무리 코드를 잘 짜도 가장 기본이라고 할 수 있는 명명규칙을 지키지 않으면 무시당하기 십상이다. 멋들어지게 쓰여진 글이라도 맞춤법을 제대로 지키지 못하는 걸 보면 신뢰도가 확 떨어지지 않는가? 그것과 동일하다고 생각한다. 팀 내 명명규칙을 잘 따르려고 노력했지만 부족한 경험과 영어 실력으로 인해 냄새가 나는 코드를 많이 작성했었다. 지금은 어느정도 규칙을 염두해두고 작성하고 있지만, 이렇게 되기까지 많은 지적을 해준 시니어에게 정..

Java. 불변 사용 시 적시에 방어적 복사본을 만들자

알다시피 자바는 가비지컬렉터로 인해 메모리 충돌 오류에서 안전하다. 하지만 클라이언트가 불변식을 깨뜨리려 혈안이 되어있다고 가정하고 방어적으로 프로그래밍 해야한다. 어떤 객체던 그 객체의 허락 없이는 외부에서 내부를 수정하는 일은 불가능하다. 하지만 주의를 기울이지 않으면 허락되는 경우가 생길 수 있다. 자바에서 불변식이 깨진다는 것은, 객체의 상태가 예상치 못한 방식으로 변경되어 객체가 의도한 동작만을 수행할 수 없게 된다는 것이다. - 데이터 무결성이 손실 될 수 있다 : 객체가 가지고 있는 데이터가 더이상 유효하지 않게 된다. 예를 들어, 금융 애플리케이션에서 계좌잔액이 음수가 되지 않도록 하는 불변식이 깨질 경우, 잘못된 잔액 정보가 발생할 수 있다. - 예기치 않은 예외 발생 : 객체의 상태가 ..

Java. 스트림이란?

스트림이란 자바 8부터 다량의 데이터 처리 작업을 돕고자 나온 API 이고, 두 가지 핵심적인 추상개념을 제공한다. 스트림은 원하는 결과를 생성하기 위해 파이프라인으로 연결될 수 있는 다양한 메서드를 지원하는 개체시퀀스이다. 스트림 파이프라인의 개념 1. 데이터 소스 : 스트림은 데이터를 처리하는데 사용할 수 있는 다양한 소스로부터 생성됩니다. 이 데이터 소스는 컬렉션, 배열, 파일 등 다양한 형태 일 수 있다. 2. 연속된 작업 : 스트림은 중간 연산과 최종 연산으로 구성된다. 중간 연산은 스트림을 반환하며, 여러 중간 연산이 연결될 수 있다. 최종 연산은 스트림 파이프라인을 종료하고 결과를 생성한다. 3. 파이프라인 : 스트림에서 제공하는 중간 연산과 최종 연산을 연결하여 데이터를 처리하는 구조를 파..

43. 람다보다는 메서드 참조를 사용하라 ( 람다 표현식과 메서드 참조 )

람다가 익명 클래스보다 나은 점 중 가장 큰 특징은 간결함이다. 그런데 더 간단하게 만드는 방법이 있다. 바로 메서드 참조다. map.merge(key, 1, (count, incr) -> count + incr); map.merge(key, 1, Integer::sum); 메서드 참조를 사용하여 코드를 간결하게 만드는 예시이다. 매개변수인 count와 incr는 크게 하는일 없이 공간을 차지한다. 이 람다는 두 인수의 합을 단순히 반환할 뿐이다. 람다 대신 이 메서드의 참조를 전달하면 똑같은 결과를 더 보기 좋게 얻을 수 있다. 하지만 어떤 람다에서는 매개변수의 이름 자체가 프로그래머에게 좋은 가이드가 되기도 한다. 이런 람다는 길이는 더 길지만 메서드 참조보다 읽기 쉽고 유지보수도 쉬울 수 있다. 람..

42. 익명 클래스보다는 람다를 사용하라 ( 람다 표현식 )

예전의 익명 클래스 방식은 코드가 너무 길기 때문에 자바는 함수형 프로그래밍에 적합하지 않았다. 자바 8에서 추상 메서드 하나짜리 인터페이는 특별한 의미를 인정받아 함수형 인터페이스의 인스턴스를 람다식을 사용해 만들 수 있게 되었다. 람다는 함수나 익명 클래스와 개념은 비슷하지만 코드는 훨씬 간결하다. 다음은 익명 클래스를 사용한 앞의 코드를 람다 방식으로 바꾼 모습이다. Collection.sort(words, new Comparator() { public int compare(String s1, String s2){ return Integer.compare(s1.length(), s2.length()); } }); Collection.sort(words, (s1,s2) -> Integer.compar..

41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라 ( 마커 인터페이스 )

아무 메서드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스를 마커 인터페이라 한다. Serializable 인터페이스 좋은 예다. 클래스의 인스턴스는 ObjectOutputStream을 통해 쓸 수 있다고, 즉 직렬화 할 수 있다고 알려준다. 마커 애너테이션이 등장하면서 마커 인터페이스는 구식이 되었다. 하지만 사실이 아니다. 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있다. 또, 적용 대상을 더 정밀하게 지정할 수 있다. 적용 대상을 ElementType.TYPE 으로 선언한 애너테이션은 모든 타입에 달 수 있다. 부착하는 타입을 더 세밀하게 제한하지는 못한다는 뜻이다. Set 인터페이스도 일종의 마커 인터페이스로 볼 수 있..

40. @Override 애너테이션을 일관되게 사용하라 ( @Override )

자바가 기본으로 제공하는 애너테이션 중 보통의 프로그래머에게 가장 중요한 것은 @Override일 것이다. @Override는 메서드 선언에만 달 수 있으며, 이 애너테이션이 달렸다는 것은 상위 타입의 메서드를 재정의했음을 뜻한다. 이 애너테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해준다. 상위 클래스의 메서드를 재정의하려는 모든 메서드에 @Override 애너테이션을 달자. 특정 메서드를 재정의할 때 잘 못 구현하면 메서드를 새로 정의하게 되어버린다. @Override 애너테이션을 붙이면 컴파일 할 때 컴파일러가 오류를 찾아낼 수 있다. @Override는 클래스뿐 아니라 인터페이스의 메서드를 재정의할 때도 사용할 수 있다. 재정의한 모든 메서드에 @Override 애너테이션을 의식적..

39. 명명 패턴보다 애너테이션을 사용하라

전통적으로 도구나 프레임워크가 특별히 다뤄야 할 프로그램 요소에는 딱 구분되는 명명 패턴을 적용해왔다. 테스트 프레임워크인 JUnit은 버전 3까지 테스트 메서드 이름을 test로 시작하게끔 했다. 효과적인 방법이지만 단점도 크다. 첫째, 오타가 나면 안된다. 실수로 이름을 test~~...으로 지으면 JUnit3는 이 메서드를 무시하고 지나치기 때문에 개발자는 이 테스트가 통과했다고 오해할 수 있다. 둘째, 올바른 프로그램 요소에서만 사용되리라고 보증할 수 없기 때문이다. 셋째, 프로그램 요소를 매개변수로 전달할 마땅한 방법이 없다는 것이다. 특정 예외를 던져야만 성공하는 테스트가 있다고 해보자. 기대하는 예외타입을 테스트에 매개변수로 전달해야 하는 상황이다. 예외의 이름을 테스트 메스드 이름에 덧붙이..