아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라.
이펙티브 자바 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라. 직렬화 프록시 패턴의 한계 1. 클라이언트가 멋대로 확장할 수 있는 클래스에는 적용할 수 없다. 1. 객체 그래프에 순환이 있는 클래스에도 적용할 수 없다. 참조
3 min read
이팩티브자바
91 posts
아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거타입을 사용하라.
이펙티브 자바 아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거타입을 사용하라. 생성자를 막아서 하나의 인스턴스만 생성하게 만든 싱근톤 하지만 Serializable구현하면 readResolve 이용해서 싱글턴을 만들어야 된다. 참조
3 min read
아이템 88. readObject 메서드는 방어적으로 작성하라.
이펙티브 자바 아이템 88. readObject 메서드는 방어적으로 작성하라. 위에 코드를 역직렬화 하면 시작일이 종료일보다 늦게 생성 될수도 있다 그것을 방지하기 위해 readObject 메소드를 방어적으로 작성한 경우이다. 실행결과 위에서 참조를 훔쳐 와서 mp의 데이터를 변경했지만 p에 데이터가 변경되었다 위에 코드
4 min read
아이템 87. 커스텀 직렬화 형태를 고혀해보라.
이펙티브 자바 아이템 87. 커스텀 직렬화 형태를 고혀해보라. 먼저 고민해보고 괜찮다고 판단될 때만 기본 직렬화 형태를 사용하라. 객체의 물리적 표현과 논리적 내용이 같다면 기본직렬화 형태라도 무방하다. 기본 직렬화 형태가 적합하다고 결정했더라도 불변식 보장과 보안을 위해 readObject 메서드를 제공해야 할 때가 많
2 min read
아이템 86. Serializable을 구현할지는 신중히 결정하라.
이펙티브 자바 아이템 86. Serializable을 구현할지는 신중히 결정하라. Serializable 구현의 문제점 Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다. 버그와 보안 구멍이 생길 위험이 높아진다. 해당 클래스의 신버전을 릴리스할 때 테스트할 것이 늘어난다는 점이다. Serializable
1 min read
아이템 85. 자바 직렬화의 대안을 찾으라.
이펙티브 자바 아이템 85. 자바 직렬화의 대안을 찾으라. 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는 것 이다. 여러분이 작성하는 새로운 시스템에서 자바 직렬화를 써야 할 이유는 전혀 없다. 신뢰할수없는 데이터는 절대 역질렬화하지 않는 것이다. 블랙리스트 방식보단 화이트리스트 방식을 추천 시스템을
2 min read
아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대하지 말라.
이펙티브 자바 아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대하지 말라. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. 스레드는 당장 처리해야 할 적업이 없다면 실행돼서는 안된다. 실행결과 참조
3 min read
아이템 83. 지연 초기화는 신중히 사용하라.
이펙티브 자바 아이템 83. 지연 초기화는 신중히 사용하라. 다른 모든 최적화와 마찬가지로 지연 초기화에 대해 해줄 조언은 필요할때까지 하지마라. 대부분의 상황에서 일반적인 초기화가 지연 초기화 보다 낫다. private final FieldType field1 = computeFieldValue(); 인스턴스 필드를 초
3 min read
아이템 82. 스레드 안정성 수준을 문서화 하라.
이펙티브 자바 아이템 82. 스레드 안정성 수준을 문서화 하라. 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일뿐 API에 속하진 않는다. 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안정성 수준을 정확히 명시해야 한다. 스레드 안정성 수준이 높은순으로 나열한 목록
3 min read
아이템 81. wait 와 notify 보다는 동시성 유틸리티를 애용하라.
이펙티브 자바 아이템 81. wait 와 notify 보다는 동시성 유틸리티를 애용하라. wait 와 notify는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하자. 동시성 컬렉션에서 동시성을 무력화하는 건 불가능하며, 외부에서 락을 추가로 사용하면 오히려 속도가 느려진다. 위에 코드에서 개선할 포인
4 min read
아이템 80. 스레드보다는 실행자, 테스크, 스트림을 애용하라.
이펙티브 자바 아이템 80. 스레드보다는 실행자, 테스크, 스트림을 애용하라. java.util.concurrent 패키지가 등장 했고 여기에 executor framework라는 것이 포함이 되어 있다. 실행자 서비스는 쓰레드 보다 고급 api면서 조금더 다루기 쉽다. 실행자 서비스의 주요기능 특정 테스크가 완료되기를
2 min read
아이템 79. 과도한 동기하는 피하라.
이펙티브 자바 아이템 79. 과도한 동기하는 피하라. 이전 상황을 동기화를 하지 않았을때 문제가 생기는 상황을 다뤘고 이번에는 과도하게 동기화를 했을때 생기는 문제를 다룰것이다. 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안된다. 실행결과 위에 코드는 정상적
8 min read
아이템 78. 공유중인 가변 데이터는 동기화 해서 사용하라.
이펙티브 자바 아이템 78. 공유중인 가변 데이터는 동기화 해서 사용하라. 동기화(synchronized)는 배타적 실행뿐 아니라 스레드 사이에 안정적인 통신에도 필요하다. 위에 동작은 1초내에 종료할것이라고 생각이 되는가? vm에서 hoisting이 일어나서 종료되지 않는다. 위에 코드가 아래 코드 처럼 최적화 되는것을
3 min read
아이템 77. 예외를 무시하지 말라.
이펙티브 자바 아이템 77. 예외를 무시하지 말라. catch블럭을 비워두면 예외의 존재 이유가 없어진다. 만약 예외를 무시하기로 결정했으면 이유를 주석으로 남기고 예외 변수 이름도 ignored로 바꿔놓도록 하자. 참조
1 min read
아이템 76. 가능한 실패를 원자적으로 만들라.
이펙티브 자바 아이템 76. 가능한 실패를 원자적으로 만들라. 일반화 해서 말하자면 호출된 메서드가 실패 하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure atomic)이라고 한다. 메서드를 원자적으로 만드는 방법 가장 간단한 방법은 불변객체로 설계하는 방법이다. 아래는
3 min read
아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라.
이펙티브 자바 아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라. 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 된다. IndexOutOfBoundsException 에서 실패값을 온전히 포착하도록 수정해 보겠다. 위에 처럼 수정하면 좀 더 좋은 코드가 될수도 있
2 min read
아이템 74. 매서드가 던지는 모든 예외를 문서화 하라.
이펙티브 자바 아이템 74. 매서드가 던지는 모든 예외를 문서화 하라. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확하게 문서화 하자. 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.(비검사 예외도 문서화는 해야 된다.) 한클래스에 정의된 많은 메
1 min read
아이템 73. 추상화 수준에 맞는 예외를 던져라.
이펙티브 자바 아이템 73. 추상화 수준에 맞는 예외를 던져라. 상위 계층에서는 저수준의 예외를 잡아 자신에 추상화 수준에 맞는 예외를 던져야 된다.(exception translation) 1. 저수준의 예외가 도움이 되면 예외 연쇄를 이용하라.(exception chaining) 1. 무턱대고 예외를 던지는 것 보다는
3 min read
아이템 72. 표준 예외를 사용하라.
이펙티브 자바 아이템 72. 표준 예외를 사용하라. 표준 예외는 이미 익숙해서 다른사람이 익히기 쉽다. 그래서 가독성도 좋고 Exception, Throwable, Error, RuntimeException 은 직접 재사용하지 말자 예외 | 주요쓰임 | | IllegalArgumentException| 허용되지 않는 값이
2 min read
아이템 71. 필요 없는 검사 예외 사용은 피하라.
이펙티브 자바 아이템 71. 필요 없는 검사 예외 사용은 피하라. 검사 예외는 꼭 필요한곳에 사용하면 프로그래밍 안정성을 높혀준다. 검사예외를 피하는 방법 1. 검사 예외를 회피하는 가장 쉬운 방법은 옵셔널이다. 1. 검사 예외를 던지는 메소드를 두개로 쪼개 비검사 예외로 바꿀수 있다.(이방식도 옵셔널과 비슷하다.) 참조
1 min read
아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라.
이펙티브 자바 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라. 자바는 throwable 타입으로 3가지가 있는데 하나는 검사 예외(checked exception), 런타임 예외(runtime exception), 에러(error) 이렇게 세가지를 제공한다. 호출하는 쪽에
2 min read
아이템 69. 예외는 진짜 예외 상황에서만 사용하라.
이펙티브 자바 아이템 69. 예외는 진짜 예외 상황에서만 사용하라. 예외는 그 이름이 말해주듯이 진짜 예외 상황에서만 사용하라. 절대로 일상적인 흐름 제어용으로 사용하면 안된다. 잘 설계된 API라면 클라이언트가 정상적인 흐름 제어에서 예외를 사용할 일이 없게 해야 한다. 옵셔널, 상태 검사 메서드, 특정값(null) 중
2 min read
아이템 68. 일반적으로 통용되는 명명 규칙을 따르라.
이펙티브 자바 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라. 자바는 명명규칙이 잘 정의 되 있으며 자바언어 명세에 나타나 있다 명세에 따르는 명명규칙을 따라라. 패키지와 모듈 이름 1. 조직의 인터넷 도메인 이름을 역순으로 사용한다.(com.google, com.naver) 1. 예외 적으로 표준 라이브러리와 선
3 min read
아이템 67. 최적화는 신중히 하라.
이펙티브 자바 아이템 67. 최적화는 신중히 하라. 모든 사람들이 새겨야 할 최적화 격언 맹목적인 어리석음을 포함해 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다 (심지어 효율을 높이지도 못하면서) 윌리엄 울프(Wulf72) (전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가
2 min read
아이템 66. 네이티브 매서드는 신중히 사용하라.
이펙티브 자바 아이템 66. 네이티브 매서드는 신중히 사용하라. 자바 네이티브 인터페이스(JNI)는 자바 프로그램이 C나 C++ 같은 네이티브 언어로 작성한 메소드를 말한다. 자바 네이티브 인터페이스의 주요 쓰임세 레지스터리 같은 플랫폼 특화 기능을 사용한다. 네이티브 코드로 작성된 기존 라이브러리를 사용한다. 성능 개선
3 min read
아이템 65. 리플렉션 보다 인터페이스를 사용하라.
이펙티브 자바 아이템 65. 리플렉션 보다 인터페이스를 사용하라. 리플렉션의 단점 컴파일 타임 타입 검사가 주는 이점을 하나도 누릴수 없다. 리플렉션을 이용하면 코드가 지저분해지고 장황해진다. 성능이 떨어진다. 리플렉션은 아주 제한적으로만 사용해야 그 단점을 피하고 이점을 취할수 있다. 만약에 써야 되도 리플렉션은 인스턴
3 min read
아이템 64. 객체는 인터페이스를 사용해 참조하라.
이펙티브 자바 아이템 64. 객체는 인터페이스를 사용해 참조하라. 적합한 인터페이스가 있다면 매개변수 뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라. 아래는 좋은 예로 인터페이스 타입을 사용하였다. 아래는 나쁜예로 클래스 타입을 사용하였다. 인터페이스 타입을 사용하는 습관을 길러두면 프로그래밍이 훨씬
2 min read
아이템 63. 문자열 연결은 느리니 주의하라.
이펙티브 자바 아이템 63. 문자열 연결은 느리니 주의하라. 자바 6 이후로 성능개선이 많이 되었지만 문자열 연결은 여전히 느리다. += 연결 보다는 StringBuilder를 활용하는것이 좋다. 실행결과 결과는 여전히 StringBuilder를 사용했을때가 더 빠르다 참조
2 min read
아이템 62. 다른타입이 적절하다면 문자열 사용을 피하라.
이펙티브 자바 아이템 62. 다른타입이 적절하다면 문자열 사용을 피하라. 문자열은 다른 값을 대신하기 적절하지 않다. 숫자를 표현할때는 int, float 등등의 타입이 좋고 예/아니오는 boolean 타입이 좋다 문자열은 열거타입을 대신하기에 적합하지 않다. 상수를 열거할때 열거 타입이 훨씬 좋다. 문자열은 혼합타입을
4 min read
아이템 61. 박싱된 기본타입 보단 기본타입을 사용하라.
이펙티브 자바 아이템 61. 박싱된 기본타입 보단 기본타입을 사용하라. 자바의 데이터 타입은 크게 두가지로 나눌수 있다. 기본 타입 : boolean, short, int, long, float, double, char 참조 타입 : String, List 기본 타입 |박싱된 기본타입(Wrapper Class) | byt
6 min read
아이템 60. 정확한 답이 필요하면 float와 double 은 피하라
이펙티브 자바 아이템 60. 정확한 답이 필요하면 float와 double 은 피하라 개발을 할때 floating point 문제에 직면하게 되는데 그 내용에 대해서 푸는 문제이다. 먼저 아래 코드를 보면 실행결과 위에 결과가 전혀 다르게 나오게 된다 float와 double금융타입의 계산과는 맞지 않다. 그럼 대안으로는
3 min read
아이템 59. 라이브러리를 익히고 사용하라.
이펙티브 자바 아이템 59. 라이브러리를 익히고 사용하라. 실행결과 위 코드는 문제가 있는데 보면 low가 50만개가 출력 되어야 되는데 66만개 이상 출력이 된다. 표준 라이브러리를 사용하면 그 코드를 작성한 전문가의 지식과 여러분보다 앞서 사용한 다른 프로그래머들의 지식을 활용할수도 있다. 위에는 java 9에 추가된
2 min read
아이템 58. 전통적인 for문 보다는 for-each문을 사용하라.
이펙티브 자바 아이템 58. 전통적인 for문 보다는 for each문을 사용하라. 위에는 전통적인 for문이다. 위에 관용구 들은 while 문보다는 좋지만 가장 좋은 코드는 아니다. 실행결과 위에 코드를 수정해 보면 실행결과 그럼 향상된 for문을 사용하면 실행결과 또다른 케이스로는 실행결과 foreach문을 사용할수
6 min read
아이템 57. 지역변수 범위를 최소화 하라.
이펙티브 자바 아이템 57. 지역변수 범위를 최소화 하라. 지역 변수의 범위를 최소화 하는 방법 지역 변수의 범위를 줄이는 가장 강력한 방법은 가장 처음 쓰일때 선언하기 이다. 거의 모든 지역변수는 선언과 동시에 초기화 해야 된다. 메서드를 작게 유지하고 한가지 기능에 충실하는것이다. 참조
1 min read
아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라.
이펙티브 자바 아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라. 여러분의 API를 올바로 문서화하려면 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야 된다. 메서드 주석에서는 HOW가 아닌 WHAT을 기술해야 된다. 한클래스 안에 설명이 똑같은 맴버가 둘이상이면 안된다. 제네
2 min read
아이템 55. 옵셔널 반환은 신중히 하라.
이펙티브 자바 아이템 55. 옵셔널 반환은 신중히 하라. 실행결과 위에 코드는 IllegalArgumentException을 발생시켜서 체크를 한다 위에서는 Optional을 사용하는것이 더 좋다고 했는데 바꾼 코드를 보면 실행결과 위처럼 옵셔널을 반환하는 메소드에는 절대로 null을 반환하지 말자 실행결과 위 처럼 옵셔
4 min read
아이템 54. null이 아닌 빈컬렉션이나 배열을 반환하라.
이펙티브 자바 아이템 54. null이 아닌 빈컬렉션이나 배열을 반환하라. 실행결과 위에 코드는 흔하게 볼수 있는 코드이다 여기서 getCheeses()에서 null을 반환하는것보다 빈 컬렉션을 반환하는 것이 좋다. 빈컬렉션을 반환하는 일차 코드는 위처럼 바꿀수 있다. 위 코드는 매번 빈 콜렉션을 할당하니 다시 한번 바꿔
2 min read
아이템 53. 가변인수(varargs)는 신중히 사용하라.
이펙티브 자바 아이템 53. 가변인수(varargs)는 신중히 사용하라. 가변인수(varargs) 메서드는 몇시한 타입의 인수를 0개 이상 받을수 있다. 실행결과 위에 코드는 간단한 가변인수의 활용예 이다. 또 인수가 하나이상이어야 할수도 있다. 코드를 바꿔보면 실행결과 위에 코드는 문제 점이 있다. 런타임에야 코드가 실
5 min read
아이템 52. 다중정의(overloading)는 신중히 사용하라.
이펙티브 자바 아이템 52. 다중정의(overloading)는 신중히 사용하라. 실행결과 위에 코드는 집합 리스트 그외를 차례대로 출력할것 같지만, 실제로는 그외만 3번 출력된다. 다중정의(overloading)된 메소드(classify)중 어떤것을 호출할지는 런타임시에 정해진다. 위에 보면 for문에서 Collectio
7 min read
아이템 51. 메서드 시그니처를 신중하게 설계하라.
이펙티브 자바 아이템 51. 메서드 시그니처를 신중하게 설계하라. 메서드 이름을 신중하게 짓자 편의 메서드를 너무 많이 만들지 말자 확신이 서지 않으면 만들지 말자. 매개변수 목록은 짧게 유지하자. 같은 타입의 매개변수가 연달아 나오는 경우가 특히 해롭다. 매개변수 타입으로는 클래스 보다 인터페이스가 낫다. hashmap
1 min read
아이템 50. 적시에 방어적 복사본을 만들어라.
이펙티브 자바 아이템 50. 적시에 방어적 복사본을 만들어라. 클라이언트가 여러분의 불변식을 깨뜨릴려고 혈안이 되있다고 가정하고 방어적으로 프로그래밍 해야 한다. 위에 코드는 보면 불변식을 지키는것 같아 그럼 식을 깨뜨리는 방법을 써보면 실행결과 위에 처럼 참조가 열려 있으므로 생성시점과는 상관 없이 불변식을 깨뜨릴수 있
5 min read
아이템 49. 매개변수가 유효한지 검사하라.
이펙티브 자바 아이템 49. 매개변수가 유효한지 검사하라. 매서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 이러한 제약은 반드시 문서화해야 되며 몸체가 실행되기전 검사해야된다. java 7에 추가된 requireNonNull 매서드는 유연하고 사용하기도 편하니 더이상 null 검사를 수동으로
2 min read
아이템 48. 스트림 병렬화는 주의해서 적용하라.
이펙티브 자바 아이템 48. 스트림 병렬화는 주의해서 적용하라. 스트림 병렬화를 하면 어떻게 될까? 위에 소스는 응답하지 않는다. 이유는 데이터 소스가 Stream.iterate거가 중간연산으로 limt를 쓰면 파이브라인 병렬화로 성능을 개선할수 없다. 대체로 스트림의 소스가 ArrayList, HashMap, HashS
3 min read
아이템 47. 반환타입으로 스트림보다 컬렉션이 낫다.
이펙티브 자바 아이템 47. 반환타입으로 스트림보다 컬렉션이 낫다. 반환타입으로 스트림보다 컬렉션이 나은 이유가 둘다 iterable을 구현하고 있지만 스트림은 iterable을 extend 하지 않아서 loop문이 정상적으로 동작 되지 않는다. 그래서 스트림으로 반환하면 무조건 forEach문을 사용해야 된다 그래서 선
11 min read
아이템 46. 스트림에서는 부작용 없는 함수를 사용하라
이펙티브 자바 아이템 46. 스트림에서는 부작용 없는 함수를 사용하라. 스트림 패러다임의 핵심은 계산을 일련의 변환으로 재구성하는 부분이다. 이때 각 단계는 가능한 한 이전 단계의 결과를 받아 처리 하는 순수 함수여야 한다. 순수 함수란 입력만이 결과에 영향을 주는 함수이다. 그래서 side effect가 없어야 된다.
18 min read
아이템 45. 스트림은 주의해서 사용해라
이펙티브 자바 아이템 45. 스트림은 주의해서 사용해라 자바8에 추가된 스트림 API 핵심은 두가지 이다. 스트림은 데이터 원소의 유한 혹은 무한 시퀀스를 뜻한다. 스트림 파이프 라인은 이 원소들이 수행하는 원소 단계를 뜻한다. 스트림 파이프라인은 소스 스트림으로 시작되 종단 연산으로 끝나며, 그 사이에 하나 이상의 중간
13 min read
아이템 44. 표준함수형 인터페이스를 사용하라.
이펙티브 자바 아이템 44. 표준함수형 인터페이스를 사용하라. 자바가 람다를 지원하면서 API를 작성하는 모범사례도 바뀌게 되었다. 상위클래스의 기본 클래스를 재정의 하여 원하는 동작을 하게 만드는 템플릿 메서드 패턴의 매력이 크게 줄었다. 먼저 함수형 인터페이스에 대해서 알아보자 위에 형태가 가장 기본적인 함수형 인터페
5 min read
아이템 43. 람다보다 매서드 참조를 사용하라.
이펙티브 자바 아이템 43. 람다보다 매서드 참조를 사용하라. 람다가 익명 클래스보다 가장 큰 나은점은 간결함이다. 자바에서 람다 보다 더 간결하게 만들수 있는것이 있는데 그것은 메서드 참조이다. 실행결과 위에선 람다를 사용한 경우 코드 이다. 다시 메서드 참조를 사용하면 실행결과 코드가 간결해진다. 그럼 반대의 경우는
3 min read
아이템 42. 익명클래스 보다 람다를 사용하라.
이펙티브 자바 아이템 42. 익명클래스 보다 람다를 사용하라. jdk 1.1부터 익명클래스를 사용했는데 jdk1.8에서 람다식을 적용하면서 코드를 더 짧게 가지고 갈수 있게 되었다. 자질구래한 코드들은 사라지고 어떻게 동작하는지에 초점을 맞추게 될수 있는 코드가 되었다. 자바에서 함수타입을 표현할때 추상메서드 하나만 담은
7 min read
아이템 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라.
이펙티브 자바 아이템 41. 정의하려는 것이 타입(ElementType.TYPE)이라면 마커 인터페이스를 사용하라. 아무 구현이 없고 단지 자기를 구현하는 클래스가 특성 속성을 가짐을 표시해주는것 인터페이스를 마커인터페이스라고 한다. 대표적인 예가 Serializable이다 그럼 코드를 보면 마커인터페이스는 두가지 측면에
4 min read
아이템 40. @Override 에너테이션을 일관성 있게 사용하라.
이펙티브 자바 아이템 40. @Override 에너테이션을 일관성 있게 사용하라. @Override를 달면 재정의를 잘못하는 경우를 알려준다 아래의 예를 보자. 실행결과 위에 코드에서 버그를 찾아 보자 위에서는 equals를 재정의 하려고 한것 처럼 보인다 그래서 일반규약인 hashCode도 재정의 했다. 그런데 위에는
5 min read
아이템 39. 명명 패턴보다는 애너테이션을 사용하라
이펙티브 자바 아이템 39. 명명 패턴보다는 애너테이션을 사용하라 junit3 버전과 junit4 버전에 차이점을 보면 테스트 메소드가 무조건 test라는 단어로 시작이 되어야 되었는데 junit4버전은 @Test 어너테이션으로 대체 되었다. 명명 패턴에 문제점 1. 오타가 나면 안된다. 1. 올바른 프로그램 요소만 사용
10 min read
아이템 38. 확장할수있는 열거 타입이 필요하면 인터페이스를 사용하라.
이펙티브 자바 아이템 38. 확장할수있는 열거 타입이 필요하면 인터페이스를 사용하라. 위에 처럼 인터페이스를 사용하여 Operation을 확장할수 있다. 다시 2개의 오퍼레이션을 확장 시키면 이렇게 확장을 하면 기존 연산에 쓰던 곳에서 계속 확장된것도 사용할수 있다. 테스트 코드를 다시 작성해서 돌려보면 실행결과 위에 코
8 min read
아이템 37. ordinal indexing 대신 EnumMap을 사용하라.
이펙티브 자바 아이템 37. ordinal indexing 대신 EnumMap을 사용하라. 실행결과 위에 코드에는 문제점이 많다 배열을 사용해서 제네릭을 사용하지도 못했고 그래서 문제가 될 소지들이 있고 앞에서 말했던 잘못된 동작을 할수있는 사항이 많다 이런 상황에서는 EnumMap이 존재한다 EnumMap으로 대체한 코
8 min read
아이템 36. 비트필드 대신 EnumSet을 사용하라
이펙티브 자바 아이템 36. 비트필드 대신 EnumSet을 사용하라 실행결과 이렇게 사용하는것을 비트필드라고 한다 이렇게 하는것은 집합연산을 통해서 하나의 값을 쓸려고 하는것이다. 이것은 구닥다리 스타일이다. 이것을 enumset을 이용하면 아래의 코드이다. 실행결과 열거할수 있는 타입을 한데 모아 집합 형태로 사용한다고
2 min read
아이템 35. ordinals 메서드 대신 instance fields를 사용하라
이펙티브 자바 아이템 35. ordinals 메서드 대신 instance fields를 사용하라 실행결과 위에서 ordinal() 메소드를 사용했는데 이것은 문제가 많다 일단 중간에 다른 값이 들어간다고 하면 값이 바뀌게 된다 실행결과 OCTET2를 추가하면 결과값이 바뀌게 된다. java doc를 보면 아래 처럼 Mos
3 min read
아이템 34. int 상수 대신 열거 타입을 사용하라.
이펙티브 자바 아이템 34. int 상수 대신 열거 타입을 사용하라. 위에 정수 열거 패턴에는 단점들이 많다. 실제로 오렌지와 사과의 이름이 동일한것이 있으면 같은것을 구분하기 위해 앞에 명칭에 오렌지를 붙혀야 했다. 실행결과 그리고 위에 코드 처럼 오렌지를 보내야 하는 클래스에 사과를 보내도 문제가 생기지 않는다. 문자
8 min read
아이템 33. 타입안전 이종컨테이너를 고려하라.
이펙티브 자바 아이템 33. 타입안전 이종컨테이너를 고려하라. 실행결과 위에 코드 처럼 간단하게 타입안전 이종 컨테이너를 구현할수있는데 여기서 2가지 문제 점이 있다. 악의적인 클라이언트가 Class객체를 제네릭이 아닌 로타입으로 넘기면 타입안정성이 깨진다. 실행결과 위에 코드에서 f.putFavorite((Class)I
7 min read
아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라.
이펙티브 자바 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라. 가변인수(varargs) 메서드와 제네릭은 자바 5 때 함께 추가되었으므로 서로 시너지 효과가 날꺼라고 예상하는데 그렇지가 않다. 가변인수는 인수의 갯수를 클라이언트에서 조절할수 있게 해주는데 구현방식에서 헛점이 있다. 가변인수를 사용하면 배열이 하
7 min read
아이템 31. 한정적 와일드카드를 사용해 API의 유연성을 높혀라.
이펙티브 자바 아이템 31. 한정적 와일드카드를 사용해 API의 유연성을 높혀라. 컴파일에러 위와 같은 에러가 난다. 보기에는 당연히 되어야 할것 같은데 에러가 난다. 제네릭은 불공변이기 때문이다. 실행결과 위에 처럼 자바에서는 이런상황을 대처하기 위해 와일드 카트 타입을 지원한다. 유연성을 극대화 하기위해서는 생산자나
8 min read
아이템 30. 이왕이면 제네릭 메서드로 만들어라
이펙티브 자바 아이템 30. 이왕이면 제네릭 메서드로 만들어라 컴파일 메시지 위처럼 메시지가 나오는데 수정을 하면 메시지는 없고 정상적으로 나온다. 실행결과 실행결과 참조
4 min read
아이템 29. 이왕이면 제네릭타입으로 만들어라
이펙티브 자바 아이템 29. 이왕이면 제네릭타입으로 만들어라 에서 만들었던 Stack 클래스를 제네릭타입으로 변환하는것이다. 위와 같은 코드가 있는데 배열을 제거 하는 방법이 2가지 있다. 아래는 첫번째 방법으로 elements의 타입을 E로 변환시켜서 하지만 new E[] 배열이 생성되지 않는다 그래서 Object[]을
5 min read
아이템 28. 배열보단 리스트를 사용하라
이펙티브 자바 아이템 28. 배열보단 리스트를 사용하라 배열은 A가 B의 하위 타입이면 A[]이 B[]의 하위타입이다. 하지만 제네릭은 List< A 가 List< B 의 하위타입은 아니다 그래서 불변이다. 어떻게 보면 제네릭이 문제가 있는것 처럼 보이지만 문제는 배열이다. 실행결과 위에 코드는 컴파일시에는 문제가 없지만
3 min read
아이템 27. 비검사 경고를 제거하라
이펙티브 자바 아이템 27. 비검사 경고를 제거하라 제네릭을 사용하면 비검사경고가 많이 보일것이다 가능한 비검사 에러를 제거 하자. 컴파일 명령줄 인수에 Xlint:unchecked를 추가하면 자세한 코멘트가 보인다. 만약 타입 안정성이 확보 되었다고 판단되면 @SuppressWarnings("unchecked") 사용하
2 min read
아이템 26. raw 타입은 사용하지 말자.
이펙티브 자바 아이템 26. raw 타입은 사용하지 말자. 실행결과 위에 처럼 raw 타입을 선언하면 런타임 익셉션에 노출되어 있다. 컴파일시에 에러 위에 코드에서 타입을 선언하면 주석을 선언 할필요없이 코드에 어떤 값이 들어갈지 녹아 들어가있다. 그리고 컴파일시에 타입에러가 나온다 raw타입을 활용하면 제네릭이 주는 안
5 min read
아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라
이펙티브 자바 아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라 소스파일에 톱레벨 클래스를 여러게 만들어도 자바 컴파일러는 문제가 없다. 아래는 Utensil.java 클래스에 톱레벨 클래스를 두개 지정해도 정상적이다. 위처럼 톱레벨클래스를 2개를 하나에 파일에 작성하게 되면 원치 않는 결과를 나타낼수도 있다. 위
3 min read
아이템 24. 맴버클래스는 되도록 static으로 만들자
이펙티브 자바 아이템 24. 맴버클래스는 되도록 static으로 만들자 ava 프로그래밍 언어를 사용하면 다른 클래스에서 클래스를 정의 할 수 있습니다. 이러한 클래스는 중첩 클래스(Nested Classes) 라고하며 여기에 설명되어 있습니다. 중첩 클래스는 정적 및 비 정적이라는 두 가지 범주로 나뉩니다. static
9 min read
아이템 23. 테그달린 클래스보다 클래스 계층구조를 활용하라.
이펙티브 자바 아이템 23. 테그달린 클래스보다 클래스 계층구조를 활용하라. 테그 달린 클래스의 단점은 여러 구현이 하나의 클래스에 담겨서 장황하고 오류를 내기 쉬우며 비효율 적이다. 테그 달린 구조는 클래스 계층구조의 아류일뿐이다. 위에는 테그달린 코드인데 장황하게 쓸때 없는 switch문 그리고 enum등이 들어가게
3 min read
아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라
이펙티브 자바 아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라 상수인터페이스 안티패턴은 인터페이스를 잘못 사용한 예다. java.io.ObjectStreamConstants 등 자바의 상수형 인터페이스 상수형 인터페이스를 삼으면 구현체에서 PhysicalConstants.AVOGADROS NUMBER 이런식으
4 min read
아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라.
이펙티브 자바 아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라. java 8 이전에는 인터페이스를 해치지 않고 메서드를 추가할 방법이 없었지만 지금은 default 메소드가 생겼다. 그렇다고 해서 모든 위험이 사라진것은 아니다. 생각할수 있느 모든상황에서 불변식을 해치지 않는 디폴트메소드를 작성하는것은 어려운 법
6 min read
아이템 20. 추상 클래스 보다는 인터페이스를 우선하라
이펙티브 자바 아이템 20. 추상 클래스 보다는 인터페이스를 우선하라 자바는 단일상속만 되니 추상클래스는 단 하나만 구현할수 있다. 인터페이스는 어떠한 상속을 했던간에 인터페이스가 선언한 메소드를 구현하고 있으면 같은 타입으로 인식한다. 그래서 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을수 있다. 인터페이스의
10 min read
아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라
이펙티브 자바 아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라 상속용 클래스는 재정의 할수 있는 매서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 된다. 이부분은 바로 직전 아이템인 18번에서 나왔듯이 상속을 했지만 내부사용을 상세하게 몰라서 메소드의 오작동을 이르켰다. 이부분은 문서
5 min read
아이템 18. 상속보단 컴포지션을 사용하라
이펙티브 자바 아이템 18. 상속보단 컴포지션을 사용하라 상속은 코드를 재사용하는 강력한 수단이지만 항상 최선은 아니다. 상속의 단점 매서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 실행결과 위에서 실행결과를 3으로 예측했지만 6이 나왔다 문제점은 HashSet의 addAll메소드에 있다. 위에 코드에서 보면 내부적으로 a
7 min read
아이템 17. 변경가능성을 최소화하라.
이펙티브 자바 아이템 17. 변경가능성을 최소화하라. 불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직한 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다. 객체의 상태를 변경하는 매서드를 제공하지 않는다. 클래
7 min read
아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라.
이펙티브 자바 아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라. 위와 같은 클래스는 public fields를 통해서 접근이 가능하다 하지만 저런식으로 작성하면 캡슐화의 이점을 살리지 못하고 이렇게 되면 클라이언트 코드를 수정하지 않고 해당 정보를 수정할수 없다
4 min read
아이템 15. 클래스와 맴버의 접근권한을 최소화 하라.
이펙티브 자바 아이템 15. 클래스와 맴버의 접근권한을 최소화 하라. 잘 설계된 컨포넌트와 어설프게 설계된 컨포넌트에 차이점은 내구 구현 정보와 데이터를 얼마나 잘숨겼는지에 따른다. 이런것을 은닉화라고 한다. 정보 은닉의 장점 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 시스템 관리 비용
5 min read
아이템 14. Comparable을 구현할지 고려하라.
이펙티브 자바 아이템 14. Comparable을 구현할지 고려하라. Comparable 인터페이스의 유일무이한 메서드인 CompareTo메서드는 이번장에서 다룬 다른 메소드들과 달리 Object 메소드가 아니다. 성격은 두가지만 빼면 Object의 equals와 같다. 다른점은 단순 동치성 비교에 더해 순서까지 비교할
7 min read
아이템 13. clone 재정의는 주의해서 진행하라.
이펙티브 자바 아이템 13. clone 재정의는 주의해서 진행하라. Cloneable을 구현한 클래스는 clone 메소드를 public으로 제공하고 사용자는 복제가 당연히 제대로 이뤄 질꺼라고 생각한다. clone 메소드의 일반규약 위에 일반규약으로 만든 클래스를 보겠다. 실행 결과 위에 코드는 일반적인 객체를 참고 하는
10 min read
아이템 12. toString은 항상 재정의 하라.
이펙티브 자바 아이템 12. toString은 항상 재정의 하라. Object의 toString은 우리에게 필요한 정보는 보이는것이 아니라 클래스이름@16진수 해시코드를 반환할뿐이다. equals와 hashcode 처럼 대단히 중요하진 않지만 toString은 항상 재정의 하는것이 좋다. 그럼 PhoneNumber클래스를
5 min read
아이템 11. equals를 재정의 하려면 hashcode도 재정의 하라
이펙티브 자바 아이템 11. equals를 재정의 하려면 hashcode도 재정의 하라 equals를 재정의한 클래스에서 hashcode도 재정의 해야된다 그렇지 않으면 hashcode의 일반규약을 어기게 되어 해당 클래스를 hashmap, hashset 같은 컬렉션의 원소로 사용될때 문제를 일으킬것이다. hashcode
11 min read
아이템 10. equals는 일반규약을 지켜서 재정의 하라
이펙티브 자바 아이템 10. equals는 일반규약을 지켜서 재정의 하라 equals는 재정의 하기 쉬워 보이지만 어렵다. 아래 사항중 하나라도 판단이 되면 재정의 하지 말자 각 인스턴스가 본질적으로 고유하다. 인스턴스의 논리적 동치성을 검사할일이 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에서 들어 맞는다
14 min read
hashcode () 및 equals ()를 사용한 작업
hashcode () 및 equals ()를 사용한 작업 java.lang.Object 에서는 equals () 와 hashcode ()의 2 개의 중요한 오브젝트 비교 메소드를 제공합니다. 기본구현 equals (Object obj) : ava.lang.Object 가 제공하는 메소드 로, 인수로서 건네진 다른 객체가
7 min read
아이템 9. try-finally 보다 try-with-resources 블럭을 사용하세요
이펙티브 자바 아이템 9. try finally 보다 try with resources 블럭을 사용하세요 일단 단점은 코드가 너무 지저분해진다. 두번째는 위에 코드에서 기기에서 문제가 생기면 in.read에서도 문제가 생길수 있고 close 할때도 문제가 생길수 있다. 위에 코드를 변경시키면 Try with Resourc
3 min read
아이템 8. Finalizer와 Cleaner의 사용은 피하라
이펙티브 자바 아이템 8. Finalizer와 Cleaner의 사용은 피하라 finalize() 메소드에 대한 설명 jdk 9 C++에서의 destructor랑 다른것이다 자바에서 자원 반납은 try with resources또는 try finally 블럭을 통해서 한다. 단점 1. 언제 실행 할지 알수가 없다. gc의
11 min read
아이템 7. 다쓴 객체의 참조를 해제하라
이펙티브 자바 아이템 7. 다쓴 객체의 참조를 해제하라 위에 처럼 스텍을 만들어서 객체를 저장하는데 다쓴객체의 참조해제를 하지 않아서 메모리 누수 현상이 있다. 위에 내용을 이해하기 위해서 일반적인 GC의 과정을 알아야 될것 같다. 문제가 될수 있는 부분은 stack.push 하는데 이부분은 Strong reference
3 min read
아이템 6. 불필요한 객체생성을 피하라
이펙티브 자바 아이템 6. 불필요한 객체생성을 피하라 똑같은 기능의 객체를 매번 생성하기 보다는 객체하나를 재사용하는 편이 좋을수도 있다. 결과 위에서 보면 string을 선언 할때 생성자를 통해서 만든 1223과 기능적으로 완전히 똑같은 생성자를 통하지 않은 객체가 있다. 이것은 생성자를 통해서 만드는것은 불필요 한 일
4 min read
아이템 5. 자원을 직접 명시 하지 말고 의존성 객체 주입(dependency injection)을 사용하라
이펙티브 자바 아이템 5. 자원을 직접 명시 하지 말고 의존성 객체 주입(dependency injection)을 사용하라 지금 대부분 자바 개발자들은 spring 프레임워크를 쓰면서 의존성 주입에 대한 이견은 없을 것입니다. 위에 방식으로 구현한 케이스와 비슷하게 아래 처럼 싱글턴방식으로 구현한 케이스 두가지는 흔한 방
3 min read
아이템 4. 인스턴스화를 막으려면 private 생성자를 사용하라
이펙티브 자바 아이템 4. 인스턴스화를 막으려면 private 생성자를 사용하라 정적 팩토리 메소드만 모아 놓은 유틸클래스들은 의도치 않게 인스턴스화가 될수 있다. 그런 것을 막으려면 private 생성자를 사용해서 인스턴스 화를 막으면 좋다. 위에서는 정적팩토리 패턴을 제공하는 dateutil 클래스이다. 인스턴스화를
2 min read
아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라
이펙티브 자바 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라 final 키워드로 싱글톤임을 보장함 위에 코드는 기본적으로 final 키워드로 싱글톤임을 보장한다. 정적 팩토리 패턴으로 싱글턴임을 보장 위에 코드는 싱글톤 구현에 두번째 방법인 정적 팩토리 패턴으로 싱글턴을 구현한 예제이다. 위에 코드
8 min read
아이템 2. 생성자에 매개 변수가 많다면 빌더를 고려하자
이펙티브 자바 아이템 2. 생성자에 매개 변수가 많다면 빌더를 고려하자 정적 팩토리 메소드 패턴과 생성자와는 공통점이 있는데 선택적인 매개변수가 많을때 처리하기 곤란하다는것 이다. 점층적 생성자 패턴(telescoping constuctor pattern) 위와 같은 클래스가 있다. 이것은 광고 노출과 클릭에 대한 통계를
10 min read
아이템 1. 생성자 대신 정적 팩토리 매소드 패턴(static factory method) 사용을 고려 해라
이펙티브 자바 아이템 1. 생성자 대신 정적 팩토리 매소드 패턴(static factory method) 사용을 고려 해라 클라이언트가 클래스의 인스턴스를 얻는 수단은 public 생성자 이다. 하지만 프로그래머가 알아 둬야 할 기법이 하나 있는데 그것이 정적 팩토리 매소드 패턴이다. 장점.1 이름을 가질수 있다. 위 클
13 min read