Effective Java

명료성(clarity)과 단순성(simplicity)은 무엇보다 중요하다. 프로그램을 명확하고, 정확하고, 유용하고, 견고하고, 유연하고, 관리하기 쉽게 짜는 데 집중한다. 이러한 목표를 만족하는 코드를 작성했다면 대부분의 상황에선 원하는 성능에 도달할 수 있을 것이다.

 

1장. 객체 생성과 파괴

1. 생성자 대신 정적 팩토리 메서드를 고려하라   8p

1) Static factory method가 constructor 보다 좋은 장점

• 이름을 가질 수 있다.
  • 반환될 객체의 특성을 쉽게 묘사 가능
• 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.
• 반환할 객체의 클래스를 자유롭게 선택할 수 있는 유연성이 있다.
  • 이 유연성으로 구현 클래스를 공개하지 않고도 그 객체를 반환할 수 있다.
• 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
• 정적 팩토리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

2) 단점

• 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
• 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

2. 생성자에 매개변수가 많다면 빌더를 고려하라  14p

• 생성자나 정적 팩토리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 게 더 낫다.

3. Private 생성자나 열거 타입(enum)으로 싱글턴임을 보증하라  23p

• 대부분의 상황에서는 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이다. 25p

4. 인스턴스화를 막으려거든 private 생성자를 사용하라  26p

• Private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.

5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라  28p

6. 불필요한 객체 생성을 피하라  31p

• 생성자는 호출할 때마다 새로운 객체를 만들지만, 팩토리 메서드는 전혀 그렇지 않다.
• 박싱 된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토 박싱이 숨어들지 않도록 주의하자.

7. 다 쓴 객체 참조를 해제하라  36p

• 객체 참조를 null 처리하는 일은 예외적인 경우여야 한다.
• 예를 들어 Stack과 같이 자기 메모리를 직접 관리하는 경우, 비활성 영역이 되는 순간 null 처리해서 해당 객체를 더는 쓰지 않을 것임을 가비지 컬렉터에 알려야 한다.

8. Finalizer와 cleaner 사용을 피하라  40p

9. Try-finally보다는 try-with-resources를 사용하라  47p

 

2장 모든 객체의 공통 메서드

10. Equals는 일반 규약을 지켜 재정의하라  52p

11. Equals를 재정의하려거든 hashCode도 재정의하라  67p

12. toString을 항상 재정의하라  73p

13. clone 재정의는 주의해서 진행하라  77p

14. Comparable을 구현할지 고려하라  87p  

• 반사성, 대칭성, 추이 성을 충족해야 한다.
• compareTo 메서드에서 관계 연산자 < 와 >를 사용하는 이전 방식은 거추장스럽고 오류를 유발하니, 이제는 추천하지 않는다.

3장. 클래스와 인터페이스

15. 클래스와 멤버의 접근 권한을 최소화하라  96p

• 접근 제한자(private, package-private, public, protected)를 제대로 활용하는 것이 정보 은닉의 핵심이다.
• 모든 클래스와 멤버의 접근성을 가능한 좁혀야 한다.
• 즉, 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다.

16. Public class에서는 public 필드가 아닌 접근자 메서드를 사용하라  102p

17. 변경 가능성을 최소화하라  105p

• Getter 가 있다고 무조건 setter를 만들지는 말 것.
• 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
• 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언할 것.
• 다른 합당한 이유가 없다면 모든 필드는 private final 이어야 한다.

18. 상속보다는 컴포지션을 사용하라  114p

19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라.  122p

20. 추상 클래스보다는 인터페이스를 우선하라  130p

21. 인터페이스는 구현하는 쪽을 생각해 설계하라  136p

22. 인터페이스는 타입을 정의하는 용도로만 사용하라  139p

23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라  142p

24. 멤버 클래스는 되도록 static으로 만들라  146p

25. 톱 레벨 클래스(public class)는 한 파일에 하나만 담으라  150p

 

4장. 제네릭

26. Raw type은 사용하지 말라  154p

• Ex) List<E>의 raw type은 타입 파라미터를 사용하지 않은 그냥 List이다.

27. 비검사 경고를 제거하라  161p

28. 배열보다는 리스트를 사용하라  164p

29. 이왕이면 제네릭 타입으로 만들라  170p

30. 이왕이면 제네릭 메서드로 만들라  176p

31. 한정적 와일드카드를 사용해 API 유연성을 높이라  181p

32. 제네릭과 가변인수를 함께 쓸 때는 신중하라  191p

33. 타입 안전 이종 컨테이너를 고려하라  198p

 

5장. 열거 타입과 애너테이션

34. Int 상수 대신 열거 타입을 사용하라  208p

35. Ordinal 메서드 대신 인스턴스 필드를 사용하라  221p

36. 비트 필드 대신 EnumSet을 사용하라  223p

37. Ordinal 인덱싱 대신 EnumMap을 사용하라  226p

38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라  232p

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

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

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

 

6장. 람다와 스트림

42. 익명 클래스보다는 람다를 사용하라  254p

43. 람다보다는 메서드 참조를 사용하라  259p

44. 표준 함수형 인터페이스를 사용하라  263p

45. 스트림은 주의해서 사용하라  268p

46. 스트림에서는 부작용 없는 함수를 사용하라  277p

47. 반환 타입으로는 스트림보다 컬렉션이 낫다  284p

48. 스트림 병렬화는 주의해서 적용하라  291p

 

7장. 메서드

49. 매개변수가 유효한지 검사하라  298p

• 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.
• 이 규칙의 예외는 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때이다.

50. 적시에 방어적 복사본을 만들라  302p

• 어떠한 입력에도 프로그램이 다운되지 않도록 프로그래밍(방어적으로 프로그래밍)

51. 메서드 시그니처를 신중히 설계하라  308p

• 매개변수 목록은 짧게 유지하자.
  • 4개 이하가 좋다.
  • 만약 넘어갈거같으면 여러 메서드로 쪼개서 원래 매개변수 목록의 부분집합을 받는다.

• 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다.

52. 다중정의는 신중히 사용하라  312p

• 오버로딩보단 메서드 이름을 다르게 지어주는 것이 더 좋다.

53. 가변인수는 신중히 사용하라  320p

54. Null이 아닌, 빈 컬렉션이나 배열을 반환하라  323p

• Null을 반환하지 말고 길이가 0인 배열을 반환하라.

55. Optional 반환은 신중히 하라  326p

56. 공개된 API 요소에는 항상 문서화 주석을 작성하라  332p

 

8장. 일반적인 프로그래밍 원칙

57. 지역변수의 범위를 최소화하라  344p

• 거의 모든 지역변수는 선언과 동시에 초기화해야 한다. 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 한다.
• 메서드를 작게 유지하고 한 가지 기능에 집중하는 것

58. 전통적인 for문보다는 for-each문을 사용하라  347p

59. 라이브러리를 익히고 사용하라  351p

60. 정확한 답이 필요하다면 float과 double은 피하라  355p

61. 박싱 된 기본 타입보다는 기본 타입을 사용하라  358p

62. 다른 타입이 적절하다면 문자열 사용을 피하라  362p

63. 문자열 연결은 느리니 주의하라  366p

• 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n2에 비례한다.
• 성능을 생각한다면 String 대신 StringBuilder를 사용.

64. 객체는 인터페이스를 사용해 참조하라  368p

65. 리플렉션보다는 인터페이스를 사용하라  371p

66. 네이티브 메서드는 신중히 사용하라  375p

67. 최적화는 신중히 하라  377p

68. 일반적으로 통용되는 명명 규칙을 따르라  381p

• Boolean 값 반환은 isDigit 처럼 is나 has로 시작.

 

9장. 예외

69. 예외는 진짜 예외 상황에만 사용하라  386p

70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라  390p

71. 필요 없는 검사 예외 사용은 피하라  393p

72. 표준 예외를 사용하라  396p

73. 추상화 수준에 맞는 예외를 던지라  399p

74. 메서드가 던지는 모든 예외를 문서화하라  402p

75. 예외의 상세 메세지에 실패 관련 정보를 담으라  404p

76. 가능한 한 실패 원자적으로 만들라  407p

77. 예외를 무시하라 말라 410p

 

10장. 동시성

78. 공유 중인 가변 데이터는 동기화해 사용하라  414p

79. 과도한 동기화는 피하라  420p

80. 스레드보다는 실행자, 테스크, 스트림을 애용하라  428p

81. Wait와 notify보다는 동시성 유틸리티를 애용하라  431p

82. 스레드 안전성 수준을 문서화하라  438p

83. 지연 초기화는 신중히 사용하라  442p

84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라  446p

 

11장. 직렬화

85. 자바 직렬화의 대안을 찾으라  450p

86. Serializable을 구현할지는 신중히 결정하라  455p

87. 커스텀 직렬화 형태를 고려해보라  459p

88. readObject 메서드는 방어적으로 작성하라  467p

89. 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라  474p

90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라  479p