[이펙티브자바] 9장 일반적인 프로그래밍 원칙(item57-68) 정리

예니·2022년 9월 29일
0

이펙티브자바

목록 보기
8/11
post-thumbnail

아이템 57. 지역변수의 범위를 최소화하라

  • 지역변수 유효범위를 최소로 줄이면 가독성, 유지보수성 높아지고, 오류가능성은 낮아진다
  • 지역변수는 가장 처음 쓰일 때 선언하자, 선언과 동시에 초기화하자
    try-catch는 예외 : 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 있다면 try블록 안에서 초기화, 변수를 try블록 밖에서도 써야한다면 try블록 앞에서 선언
  • while문보다는 for문을 쓰는 것이 낫다
    for문은 반복 변수 범위가 몸체 안으로 제한됨
    복붙 오류도 줄여줌
  • 메서드를 작게, 한가지 일만 하도록 만들자

아이템 58. 전통적인 for 문 보다는 for-each 문을 사용하라

  • for-each를 사용할 수 있다면, for문보다는 for-each를 쓰자
    반복자, 인덱스 없어서 코드 깨끗, 오류 적음
    for문을 최적화한 것이라 성능저하 없음
  • for-each를 사용할 수 없는 상황
    1. destructive filtering : 순회하면서 컬렉션의 원소 제거 (돌면서 제거할 일 있으면 removeIf 쓰세요)
    2. transforming : 순회하면서 원소를 교체할 때
    3. parallel iteration : 여러 컬렉션 병렬로 순회할 때
  • for-each를 사용할 수 없는 사례에 대한 글
    https://github.com/Java-Bom/ReadingRecord/issues/128
  • for-each는 Iterable 인터페이스를 구현한 객체에서 사용 가능

아이템 59. 라이브러리를 익히고 사용하라

  • 표준 라이브러리를 잘 쓰자
  • 전문가의 지식과 경험을 활용할 수 있다.
  • 기능 업데이트도 잘해준다
  • java.lang, util, io 는 프로그래머라면 잘 알자
  • collections, stream, concurrent 도
  • 구아바 같은 고품질 서드파티 라이브러리도 좋다

아이템 60. 정확한 답이 필요하다면 float와 double은 피하라

  • float, double은 부동소수점 연산에 → 돈 관련에 쓰면 큰일남
  • 정확한 실수 표현이 필요하다면 BigDecimal을 사용하자
    int, long을 쓰고 직접 소수점을 관리해주는 방법도 있음
  • BigDecimal은 기본 타입보다 쓰기 불편하고, 훨씬 느리다.
    성능과 필요성 중에서 잘 선택하자
  • 실무에서 결제, 정산 관련 코드에는 BigDecimal을 사용했었음

아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라

  • 기본 타입과 박싱된 기본 타입의 차이
    1. 박싱된 기본 타입은 식별성을 갖는다.
    2. 박싱된 기본 타입은 null을 가질 수 있다.
    3. 기본 타입이 시간, 메모리 면에서 더 효율적이다.
  • 박싱된 기본 타입에 == 연산자를 사용하면 위험하다
  • 기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱이 자동으로 풀린다. 조심하자
  • 박싱된 기본 타입은 언제 쓰는가?
    1. 컬렉션의 원소, 키, 값 → 타입 매개변수에 기본 타입 불가능하므로
    2. 리플렉션

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

  • 문자열로 다른 값 타입을 나타내면 좋지 않다.
    수치라면 int, long 등으로, 예/아니오 같은 거라면 boolean, enum으로 변환하자
  • 문자열로 기본 타입, 열거 타입, 혼합 타입을 대신하지 말자
    전용 클래스를 만드는 것도 좋은 방법
  • 리팩토링할 구석이 많겠군

아이템 63. 문자열 연결은 느리니 주의하라

  • String + 연산은 최적화되어서 내부적으로 StringBuilder를 사용함
    자바 5부터 컴파일 시점에 StringBuilder를 이용하여 바이트 코드를 변경해 최적화
  • 자바 9부터는 invokeDynamic을 사용하도록 변경됨
    컴파일 시점에 바이트코드를 변경하지 않고, 런타임 시점에 String을 연산
  • 근데 항상 StringBuilder로 변환되는 것은 아님
    명시적으로 StringBuilder를 써줘야 좋은 경우도 있음
    https://siyoon210.tistory.com/160
    https://p829911.tistory.com/18

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

  • 적합한 인터페이스가 있다면 생성자로 생성할 때 외에는 모두 인터페이스를 사용하자 (유연성)
  • 적합한 인터페이스가 없다면 클래스로 참조해야함
    1. 값 클래스 (String, BigInteger 등)
    2. 클래스 기반으로 작성된 프레임워크가 제공하는 객체들 (그래도 가급적 기반 클래스쓰자)
    3. 인터페이스에는 없는 특별한 메서드를 제공하는 클래스들 (ex. PriorityQueue)

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

  • 리플렉션은 란타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할때 적합하다. (즉, 컴파일 타임에 알 수 없는 클래스를 사용할때만 사용해야 한다.)
    https://stackoverflow.com/questions/37628/what-is-reflection-and-why-is-it-useful
  • 리플렉션을 사용하면 프로그램에서 임의의 클래스에 접근할 수 있다.
    생성자, 메서드, 필드를 가져올 수 있고, 사용할 수 있음
    컴파일 타임에 존재하지 않던 클래스도 이용할 수 있음
  • 단점
    1. 컴파일 타임 타입 검사가 주는 이점을 누릴 수 없음
    2. 코드가 지저분해짐
    3. 성능이 떨어짐
  • 리플렉션은 꼭 필요한 곳에 제한적으로만 사용하자
    리플렉션을 인스턴스 생성에만 쓰고, 이 인스턴스는 인터페이스나 상위 클래스로 참조해서 사용

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

  • 네이티브 메서드의 주요 쓰임
    1. 레지스트리 같은 플랫폼 특화 기능 사용
    2. 네이티브 코드로 작성된 기존 라이브러리 사용
    3. 성능 개선 목적
  • 근데 요즘 JVM이 많이 발전해서 성능 개선 용도로도 그닥, 잘 비교해보고 꼭 필요할때만 쓰자
  • 네이티브 메서드 단점
    네이티브 언어 자체가 안전하지 않음 (메모리 충돌), 플랫폼 많이 탐, 디버깅 어려움, GC가 메모리 자동회수 안해줌, 네이티브 메서드와 자바 코드 간 글루코드 작성이 귀찮음

아이템 67. 최적화는 신중히 하라

  • 섣부른 최적화가 만악의 근원이다. 하지마라. 아직 하지마라.
  • 빠른 프로그램 < 좋은 프로그램
    설계를 잘하자
  • 깨끗, 명확, 멋진 구조의 프로그램을 완성한 후에나 최적화를 고려해라
  • 각각의 최적화 시도 전후로 성능을 측정하라
    자바의 성능 모델은 정교하지 않아서 성능 측정이 중요함
  • 프로파일링 도구 사용하자.
    jmh 다음에 써봐야지..
    https://ysjee141.github.io/blog/quality/java-benchmark/

아이템 68. 일반적으로 통용되는 명명 규칙을 따르라

  • 이름을 잘 짓자. 알잘딱깔센
  • boolean을 반환하는 메서드는 is, has로 시작하고, 필드명은 이걸 생략해도 괜찮다

0개의 댓글