Page Index - ksw6169/effective-java GitHub Wiki

94 page(s) in this GitHub Wiki:

• Home
• Effective Java 3/E
• ## 문자열을 쓰지 말아야 하는 경우 ### 1. 문자열은 다른 값 타입을 대신하기에 적합하지 않다. 입력 데이터가 진짜 문자열일 때만 String 타입을 사용해야 한다. 만약 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. '예 아니오' 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다. 기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하라. ### 2. 문자열은 열거 타입을 대신하기에 적합하지 않다. 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다. ### 3. 문자열은 혼합 타입을 대신하기에 적합하지 않다. 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않다. 다음은 혼합 데이터를 키로 사용하는 예제로 많은 단점을 내포하고 있다. java ** * [혼합 데이터를 문자열로 사용하는 코드의 단점] * 1. 구분자 '#' 이 두 요소 중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. * 2. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. * 3. 적절한 equals, toString, compareTo 메소드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 한다. * String compoundKey = className "#" i.next(); ### 4. 문자열은 권한(capacity)을 표현하기에 적합하지 않다. 권한(여기서는 '키' 를 의미한다.) 을 문자열로 표현하는 경우가 종종 있다. 예컨대 각 스레드가 자신만의 변수를 갖게 하는 기능을 만들기 위해 사용자가 제공하는 문자열 키로 스레드별 지역변수를 식별하게 하는 경우, 문자열 키는 고유할 수 없으므로 다른 사용자가 의도적으로 같은 키를 사용하여 다른 사용자의 값을 가져올 수도 있다. 이 경우에는 문자열 대신 위조할 수 없는 클래스의 객체를 별도로 만들어 각 스레드별로 고유한 키를 사용할 수 있게끔 하는 것이 좋다. (객체는 고유하므로 문자열처럼 다른 사용자가 의도적을로 같은 키를 사용할 수 없게 되기 때문이다.) ## 핵심 정리 더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면 문자열을 쓰지 말자. 문자열은 잘못 사용하면 번거롭고, 덜 유연하고, 오류 가능성도 크다. 문자열을 잘못 사용하는 흔한 예로는 기본 타입, 열거 타입, 혼합 타입이 있다.
• ## 문자열을 쓰지 말아야 하는 경우 ### 1. 문자열은 다른 값 타입을 대신하기에 적합하지 않다. 입력 데이터가 진짜 문자열일 때만 String 타입을 사용해야 한다. 만약 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. '예 아니오' 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다. 기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고, 없다면 새로 하나 작성하라. ### 2. 문자열은 열거 타입을 대신하기에 적합하지 않다. 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다. ### 3. 문자열은 혼합 타입을 대신하기에 적합하지 않다. 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않다. 다음은 혼합 데이터를 키로 사용하는 예제로 많은 단점을 내포하고 있다. java ** * [혼합 데이터를 문자열로 사용하는 코드의 단점] * 1. 구분자 '#' 이 두 요소 중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. * 2. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. * 3. 적절한 equals, toString, compareTo 메소드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 한다. * String compoundKey = className "#" i.next(); ### 4. 문자열은 권한(capacity)을 표현하기에 적합하지 않다. 권한(여기서는 '키' 를 의미한다.) 을 문자열로 표현하는 경우가 종종 있다. 예컨대 각 스레드가 자신만의 변수를 갖게 하는 기능을 만들기 위해 사용자가 제공하는 문자열 키로 스레드별 지역변수를 식별하게 하는 경우, 문자열 키는 고유할 수 없으므로 다른 사용자가 의도적으로 같은 키를 사용하여 다른 사용자의 값을 가져올 수도 있다. 이 경우에는 문자열 대신 위조할 수 없는 클래스의 객체를 별도로 만들어 각 스레드별로 고유한 키를 사용할 수 있게끔 하는 것이 좋다. (객체는 고유하므로 문자열처럼 다른 사용자가 의도적을로 같은 키를 사용할 수 없게 되기 때문이다.) ## 핵심 정리 더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면 문자열을 쓰지 말자. 문자열은 잘못 사용하면 번거롭고, 덜 유연하고, 오류 가능성도 크다. 문자열을 잘못 사용하는 흔한 예로는 기본 타입, 열거 타입, 혼합 타입이 있다..
• 아이템 1. 생성자 대신 정적 팩토리 메소드를 고려하라.
• 아이템 10. equals는 일반 규약을 지켜 재정의하라.
• 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라.
• 아이템 12. toString을 항상 재정의하라.
• 아이템 13. clone 재정의는 주의해서 진행하라.
• 아이템 14. Comparable을 구현할지 고려하라.
• 아이템 15. 클래스와 멤버의 접근 권한을 최소화하라.
• 아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메소드를 사용하라.
• 아이템 17. 변경 가능성을 최소화하라.
• 아이템 18. 상속보다는 컴포지션을 사용하라.
• 아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라.
• 아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라.
• 아이템 20. 추상 클래스보다는 인터페이스를 우선하라.
• 아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라.
• 아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라.
• 아이템 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라.
• 아이템 24. 멤버 클래스는 되도록 static으로 만들라.
• 아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라.
• 아이템 26. 로 타입은 사용하지 말라.
• 아이템 27. 비검사 경고를 제거하라.
• 아이템 28. 배열보다는 리스트를 사용하라.
• 아이템 29. 이왕이면 제네릭 타입으로 만들라.
• 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라.
• 아이템 30. 이왕이면 제네릭 메소드로 만들라.
• 아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라.
• 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라.
• 아이템 33. 다중 안전 이종 컨테이너를 고려하라.
• 아이템 34. int 상수 대신 열거 타입을 사용하라.
• 아이템 35. ordinal 메소드 대신 인스턴스 필드를 사용하라.
• 아이템 36. 비트 필드 대신 EnumSet을 사용하라.
• 아이템 37. ordinal 인덱싱 대신 EnumMap을 사용하라.
• 아이템 38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라.
• 아이템 39. 명명 패턴보다 어노테이션을 사용하라.
• 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라.
• 아이템 40. @Override 어노테이션을 일관되게 사용하라.
• 아이템 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라.
• 아이템 42. 익명 클래스보다는 람다를 사용하라.
• 아이템 43. 람다보다는 메소드 참조를 사용하라.
• 아이템 44. 표준 함수형 인터페이스를 사용하라.
• 아이템 45. 스트림은 주의해서 사용하라.
• 아이템 46. 스트림에서는 부작용 없는 함수를 사용하라.
• 아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다.
• 아이템 48. 스트림 병렬화는 주의해서 적용하라.
• 아이템 49. 매개변수가 유효한지 검사하라.
• 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라.
• 아이템 50. 적시에 방어적 복사본을 만들라.
• 아이템 51. 메소드 시그니처를 신중히 설계하라.
• 아이템 52. 다중정의(overloading)는 신중히 사용하라.
• 아이템 53. 가변인수는 신중히 사용하라.
• 아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라.
• 아이템 55. 옵셔널 반환은 신중히 하라.
• 아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라.
• 아이템 57. 지역변수의 범위를 최소화하라.
• 아이템 58. 전통적인 for문 보다는 for each문을 사용하라.
• 아이템 59. 라이브러리를 익히고 사용하라.
• 아이템 6. 불필요한 객체 생성을 피하라.
• 아이템 60. 정확한 답이 필요하면 float와 double 은 피하라.
• 아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라.
• 아이템 62. 다른 타입이 적절하다면 문자열 사용을 피하라.
• 아이템 63. 문자열 연결은 느리니 주의하라.
• 아이템 64. 객체는 인터페이스를 사용해 참조하라.
• 아이템 65. 리플렉션보다는 인터페이스를 사용하라.
• 아이템 66. 네이티브 메소드는 신중히 사용하라.
• 아이템 67. 최적화는 신중히 하라.
• 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라.
• 아이템 69. 예외는 진짜 예외 상황에만 사용하라.
• 아이템 7. 다 쓴 객체 참조를 해제하라.
• 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라.
• 아이템 71. 필요 없는 검사 예외 사용은 피하라.
• 아이템 72. 표준 예외를 사용하라.
• 아이템 73. 추상화 수준에 맞는 예외를 던지라.
• 아이템 74. 메소드가 던지는 모든 예외를 문서화하라.
• 아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라.
• 아이템 76. 가능한 한 실패 원자적으로 만들라.
• 아이템 77. 예외를 무시하지 말라.
• 아이템 78. 공유 중인 가변 데이터는 동기화해서 사용하라.
• 아이템 79. 과도한 동기화는 피하라.
• 아이템 8. finalizer와 cleaner 사용을 피하라.
• 아이템 80. 스레드보다는 실행자, 태스트, 스트림을 애용하라.
• 아이템 81. wait과 notify 보다는 동시성 유틸리티를 애용하라.
• 아이템 82. 스레드 안전성 수준을 문서화하라.
• 아이템 83. 지연 초기화는 신중히 사용하라.
• 아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라.
• 아이템 85. 자바 직렬화의 대안을 찾으라.
• 아이템 86. Serializable을 구현할지는 신중히 결정하라.
• 아이템 87. 커스텀 직렬화 형태를 고려해보라.
• 아이템 88. readObject 메소드는 방어적으로 작성하라.
• 아이템 89. 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라.
• 아이템 9. try finally 보다는 try with resources를 사용하라.
• 아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라.