9장 일반적인 프로그래밍 원칙 (week 8)

[KimYealynn]

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

Schedule : 21.06.30 (수) 9PM

목차

• 아이템 57. 지역변수의 범위를 최소화하라
• 아이템 58. 전통적인 for문보다는 for-each 문을 사용하라
• 아이템 59. 라이브러리를 익히고 사용하라
• 아이템 60. 정확한 답이 필요하다면 float과 double을 피하라
• 아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라
• 아이템 62. 다른 타입이 적절하다면 문자열 사용을 피하라
• 아이템 63. 문자열 연결은 느리니 주의하라
• 아이템 64. 객체는 인터페이스를 사용해 참조하라
• 아이템 65. 리플렉션보다는 인터페이스를 사용하라
• 아이템 66. 네이티브 메서드는 신중히 사용하라
• 아이템 67. 최적화는 신중히 하라
• 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라

[KimYealynn]

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

• 가장 처음 쓰일 때 선언하기 + 동시에 초기화
• for문안에 선언한 변수는 몸체 괄호안으로 제한 되기 때문에 while보다는 for를 써라
• for( int i = 0, n = MAX(), ...) 범위가 정확히 일치하는 두 반복 변수 i, n

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

• for-each 문을 사용할 수 없는 경우
  • destructive filtering : 원소 제거
  • transforming : 원소 값 일부 혹은 전체 교체
  • parallel iteration : 여러 컬렉션 병렬로 순회

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

• 장점
  • 성능이 지속해서 개선되다
  • 독자에게 익숙한 코드가 된다
• 적어도 java.lang, java.util, java.io와 하위 패키지들에 익숙해지자 + (컬렉션 프레임워크, 스트림라이브러리, java.util.concurrent)

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

• float, double 은 근사치, 정확한 계산에는 BigDemical, int, long

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

• 박싱된 기본 타입의 기본타입과의 차이
  • 값 + 식별성
  • 유효하지 않은 값 null 가능
  • 시간고 메모리 사용면에서 덜 효율적
• == 사용시 오류
• 기본타입과 박싱된 기본타입을 혼용한 연산에서는 박싱이 자동으로 풀림

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

• 열거타입이 월등히 낫다

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

• n개를 잇는 시간은 n^2
• 대신 StringBuilder 사용

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

• 객체의 실제 클래스를 사용해야 할 상황은 오직 생성자로 생성할 때뿐이다.
• 적합한 인터페이스가 없는 경우
  • 값 클래스
  • 클래스 기반으로 작성된 프레임 워크가 제공하는 객체
  • 인터페이스에는 없는 특별한 메서드를 제공하는 클래스
• 최대한 덜 구체적인(상위의) 클래스를 사용하자

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

• 리플렉션 ?
• 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할 때 적합
  • 버전이 여러 개 존재하는 외부 패키지를 다룰 때 가장 오래된 버전만을 지원하도록 컴파일 후 리플렉션 기법을 사용한다

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

• 네이티브 메서드의 주요 쓰임
  • 레지스트리 같은 플랫폼 특화 기능 사용
  • 네이티브 코드로 작성된 기존 라이브러리 사용
  • 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만
• GMP(GNU 다중 정밀 연산 라이브러리)
• 단점
  • 메모리 훼손으로 부터 안전하지 못함
  • 낮은 이식성, 어려운 디버깅
  • 메모리 자동 회수, 추적 불가
  • 경계 넘을 때 비용 발생
  • 접착 코드 작성의 번거로움

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

• 하지마라, 아직 하지마라
• 성능 때문에 견고한 구조를 희생하지 말자
• 최적화 전후로 성능을 측정하라
• JMH : 자바 코드의 성능을 보여주는 마이크로 벤치마킹 프레임워크

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

[jin5335]

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

Item57 지역변수의 범위를 최소화하라

지역변수의 범위를 최소화 하는 방법

1. 사용되는 시점에 선언하기

• 옛날 C 에서는 지역변수를 코드블럭의 맨 앞에 선언해야 했는데, Java에서는 어디에서나 변수를 선언할 수 있다. (단, 변수의 범위는 코드블럭이 끝날 때까지)

2. 초기화 할 수 있다면, 선언과 동시에 초기화해라.

• 초기화시, 에러가 날 수 있는 경우는 예외 (try-catch)

3. 메서드를 가능한 작게 유지하고, 한 가지 기능에 집중해라

• 메서드가 크거나 여러가지 기능을 할 경우 지역변수가 많아지며, 자연스레 지역변수의 범위를 최소화하기 어려워진다. (선언 후, 코드블럭이 끝날때까지 유지되므로)

Item58 전통적인 for문보다는 for-each문을 사용하라

• for-each: enhanced for statement

  for (Element e: elements) {
    // logic
  }

• 전통적은 for문보다 명료, 유연, 버그를 예방해준다.
• for-each문은 Iterable 인터페이스를 구현한 객체라면, 무엇이든 순회할 수 있다.

  public interface Iterable<E> {
    Iterator<E> iterator();
  }

  i.e iterator만 정의하면 for-each 사용 가능하므로, \ 컬렉션 형태의 객체를 구현한다면, iterator를 구현하는 것을 고민해봐라.

for-each를 사용할 수 없는 3가지 경우

1. 파괴적인 필터링(destructive filtering): 컬렉션을 순회하면서 선택된 원소를 제거하는 경우.
2. 변형(transforming): 리스트나 배열을 순회하면서, 그 원소의 값 일부 혹은 전체를 교체하는 경우.
3. 병렬 반복(parallel iteration): 여러 컬렉션을 병렬로 순회해야 하는 경우.

iter1 = list1의 iterator
iter2 = list2의 iterator
while (iter1.hasNext() && iter2.hasNext()){
  print(iter1.next(), iter2.next())
}

Item59 라이브러리 익히고 사용해라.

• 필요한 기능이 있다면, 프로페셔널한 다른 사람이 구현한 라이브러리를 사용하는 것을 고려해봐라!!

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

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

• 박싱된 기본 타입간의 ==은 값을 비교하는 게 아닌, 객체를 비교한다.
• 박싱된 기본 타입과 기본 타입을 같이 사용한 연산일 경우, 박싱된 기본 타입이 언박싱된다.
  • 박싱된 기본 타입때변수가 null을 담고 있을때 언박싱되면 NPE가 발생하니 주의!
  • 박싱된 기본 타입과 기본 타입이 연산이 반복될 경우, 오토박싱과 언박싱이 반복되므로, \ 성능에 영향을 준다.

기본 타입과 박싱된 기본 타입의 차이점 3가지

1. 박싱된 기본 타입은 식별성(identify)를 갖는다. (객체 주소..?)

• 식별성(identify): 값이 같아도 다르다고 식별될 수 있음

2. 박싱된 기본 타입은 null을 가질 수 있다서
3. 기본 타입이 박싱된 기본 타입보다 시간 및 메모리면에서 효율적이다.

박싱된 기본 타입을 써야하는 경우

1. 컬렉션의 원소, 키, 값 (컬렉션인 기본 타입을 담을 수 없어서)
2. 리플렉션을 통해 메서드를 호출할 때

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

Item63. 문자열 연결은 느리니 주의하라.

• 문자열 연결 연산자(+)로 문자열 n개를 잇는 시간은 n^2에 비례한다
• 많은 문자열을 연결할 때는 StringBuilder의 append()를 사용해라.

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

• 예시
  • 좋은 예: Set<Son> sonSet = new LinkedHashSet<>();
  • 나쁜 예: LinkedHashSet<Son> sonSet = new LinkedHashSet<>();
• 인터페이스를 타입으로 사용하는 습관이 있으면, 프로그램이 유연해진다.
  • 인터페이스로 선언하면 구현타입을 바꿀 , 클래스를 생성하는 부분만 새로운 구현 타입으로 변경하면 된다
• 적합한 인터페이스가 없다면 클래스를 참조하며, 클래스 계층구조 중 필요한 기능을 만족하는 가장 상위의(덜 구체적인) 클래스를 타입으로 사용해라.

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

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

Item67. 최적화는 신중히 하라.

Item68. 일반적으로 통용되는 명명규칙을 따라라.

[minSW]

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

item 57

• 지역변수 범위 최소화 => 가독성 & 유지보수성 ↑, 오류가능성 ↓
• How to
  • 가장 처음 쓰일때 선언 (not 취향 차이? 🤔)
  • 거의 대부분 선언과 동시에 초기화
  • 메서드를 가능한 작게 유지

item 58

• for-each 문 = 향상된 for 문 (enhanced for statement)
  • 명료, 유연, 버그 예방
  • 성능 동일 (사람이 손으로 최적화하는 것과 동일)
• Don't use when
  • 파괴적인 필터링
  • 변형
  • 병렬 반복

item 59

• "Don't reinvent the wheel"
• 표준 라이브러리 사용 권장
  • 앞선 지식/경험 활용 가능
  • 매 릴리즈마다 추가되는 기능들 & 개선되는 성능
• 그러나 제공하는 기능은 유한하기 마련 => 대안 사용
  • 고품질의 서드파티 라이브러리 (ex. Guava)
  • 직접 구현

item 60

• float, double 은 공학 계산용으로 설계. 정밀한 '근사치'
• 금융 계산 (정밀한 계산) 시에는 BigDecimal, int, long 사용할 것
  • BigDecimal : 정확하지만 사용이 불편하고 느림
  • int / long : 정확하고 빠르지만 값의 크기가 제한. 소수점관리는 직접
  • 십진수 기준) 9자리 => int, 18자리 => long, 그 이상 => BigDecimal

item 61

• 기본 타입 vs 박싱된 기본 타입 (참조 타입)
  • 기본타입 : int, double, boolean
  • 박싱된 기본 타입 : Integer, Double, Boolean
• 차이점
  • 기본은 값만 vs 박싱은 값+식별성
  • 가본의 값은 언제나 유효 vs 박싱은 nullable
  • 기본이 박싱보다 시간/메모리 더 효율적
• 주의점
  • 박싱된 기본타입에 == 불가
  • 기본타입과 박싱된 기본타입 혼용 연산 => 오토 언박싱 (NPE 위험)
  • 박싱과 언박싱의 반복 => 성능 저하

item 62

• 문자열은 잘못 사용하면 번거롭고, 느리고, 오류 가능성이 큼
• 문자열로 ~ 를 대신하는 것은 지양
  • 다른 값 타입 (boolean, int, long ..)
  • 열거 타입
  • 혼합 타입 (ex. className + "#" + i.next())
  • 권한 표현

item 63

• 문자열 연결 연산자 (+)
  • n개의 문자를 잇는 시간 = O(n^2)
• 성능을 위해서는 String 대신 StringBuilder 사용 권장
  • String + => StringBuilder.append()
• String vs StringBuffer vs StringBuilder
  • String : immutable, thread-safe
  • StringBuffer : muable, thread-safe
  • StringBuilder : mutable, not thread-safe, 단일쓰레드 성능이 더 뛰어남
• 하지만 어차피 JDK1.5 이상에서는 String => StringBuilder 사용하지 않나 🤔
  • => 항상 StringBuilder로 변환되는것은 아님
  • 반복문이나 여러줄에 걸쳐서 연산하는 경우는 성능최적화 필요
  • ref. https://siyoon210.tistory.com/160
• 즉, 한줄 연산이 아니면 StringBuilder 쓸 것

item 64

• 매개변수, 반환값, 변수 필드 등 가능하면 인터페이스 타입으로 선언하라
  • 실제 클래스를 사용해야하는 상황은 오직 생성자를 통한 생성 뿐
  • 프로그램 유연성 ↑
• 적합한 인터페이스가 없는 경우
  • 가장 덜 구체적인 (상위의) 클래스로 참조
  • 특정 구현 클래스보다는 (보통 추상 클래스인) 기반 클래스 사용

item 65

• 리플렉션 (java.lang.reflect)
  • 임의 클래스 접근 가능
• Class 객체
  • => 클래스의 Constructor, Method, Field 인스턴스
  • => 클래스의 멤버 이름, 필드 타입, 메서드 시그니처
• 리플렉션의 단점
  • 컴파일 타임의 타입 검사 이점을 누릴 수 없음
  • 코드가 지저분하고 장황
  • 성능 저하 (일반 메서드 호출보다 리플렉션 통한 호출이 훨씬 느림)
• 리플렉션 사용 케이스?
  • 컴파일 타임에 알 수 없는 클래스 사용 시
  • 런타임에 존재하지 않을 수도있는 다른 클래스, 메서드, 필드와의 의존성 관리에 유용
  • 단 사용하더라도,
  • "되도록 객체생성에만 사용하고, 생성할 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환 해 사용하라"
  • 아주 제한된 형태로 사용해야 단점을 피하고 장점만 취할 수 있음

item 66

• 자바 네이티브 인터페이스 (JNI, Java Native Interface)
  • 자바 프로그램이 네이티브 메서드를 호출하는 기술
  • 네이티브 메서드 : 네이티브 프로그래밍 언어 (C, C++) 로 작성한 메서드
• 주요 쓰임 3가지
  • 1) (레지스트리 같은) 플랫폼 특화 기능
  • 그러나 자바도 성숙해지면서 os같은 하부플랫폼 기능 흡수 중
  • ex. Java9 의 process API
  • 2) 네이티브 코드로 작성된 기존 라이브러리 사용
  • 대체할만한 자바 라이브러리가 없는 네이티브 라이브러리 사용 시
  • 3) 성능 개선
  • 권장하지 않음 (Java3 이전쯤의 이야기..)
  • 지금의 자바는 발전을 거쳐 원래 네이티브 구현보다 더 좋은 성능
  • BigInteger 처럼 네이티브 라이브러리 쪽이 더 개선되는 경우도 있음
    • GNU 다중 정밀 연산 라이브러리 (GMP, GNU Multiple Precision Arithmetic Library)
• 네이티브 메서드의 단점
  • 안전하지 않음 (메모리 훼손 오류)
  • 플랫폼을 많이타서 이식성 ↓
  • 디버깅의 어려움
  • 자바 코드와 네이티브 코드의 경계 이동 시마다 비용 추가
  • 접착 코드 (glue code) => 작업량 ↑ 가독성 ↓
• 즉, 진짜 웬만하면 사용하지 말것
  • 저수준 자원이나 어쩔 수 없이 사용해야하는 경우도 최소한만 사용

item 67

• 최적화 격언 3가지가 뜻하는 의미
  • "하지마라" & "(전문가 라면) 아직 하지마라"
  • 좋은 결과보단 해로운 결과로 이어지기 쉽다
  • 빠르지도 않고 제대로 동작하지도 않고 유지보수는 어려운.. ☠️
• "빠른 프로그램보다는 좋은 프로그램을 작성하라"
  • 좋은 프로그램의 아키텍처 자체가 좋은 성능으로 안내해줄 것
  • 정보 은닉 원칙 => 개별 구성요소 내부를 독립적 설계/변경 가능
• 아키텍처 설계 단계 고려 사항
  • 성능을 제한하는 설계 지양 (소통 방식 등)
  • API 설계 시 성능에 주는 영향 고려
  • 성능을 위해 API를 왜곡하지 말 것
  • 신중히 설계하여 깨끗하고 명확한 멋진 구조를 갖춘 이후에 최적화 고려
  • 각각의 최적화 시도 전후로 성능 측정
• 정보 은닉 원칙 (Stealth Information)
  • "외부의 접근은 제한하고, 내부에서의 접근만을 허용하여 정보 은닉의 원칙을 수행 한다."
  • 자바의 객체지향 원칙에 포함. 클래스 내부에서만 접근 허용한다는 의미
  • ref. https://velog.io/@ym1085/Chapter-04
• "충분히 빠르면 그것으로 끝이다"

item 68

• 철자 규칙
  • 패키지 이름
  • 각 요소는 점(.)으로 구분하여 계층적으로
  • 소문자 알파벳 or 숫자로 구성 (🤔- 나 _는?)
  • 8자 이하 짧은 단어 사용 (줄여쓰기 권장)
  • 인터넷 도메인 이름을 역순으로 사용
  • 클래스, 인터페이스 이름
  • 첫글자는 대문자로 시작
  • 하나 이상의 단어로 구성
  • 통용되는 줄임말이 아니라면 줄여쓰지말것
  • 메서드, 필드 이름
  • 첫글자는 소문자로 시작
  • 그 외에는 클래스 명명 규칙과 동일
  • 첫 단어가 약자면 단어 전체가 소문자여야함
  • 상수 필드 (static final 필드) 이름
  • 모두 대문자 사용
  • 단어 사이는 밑줄로 구분
  • 지역 변수 이름 (+ 입력 매개변수)
  • 다른 멤버와 비슷한 명명 규칙 적용
  • 약어 사용 가능
  • 타입 매개변수 이름
  • 보통 대문자 한 문자
  • T (Type), E (Element), K (Key), V (Value), X (eXception), R (Return)
• 문법 규칙
  • 철자 규칙보다 유연
  • 패키지 이름 : 규칙 x
  • 클래스, 인터페이스 이름
  • 객체 생성 가능한 클래스 (+열거) : 단수 명사나 명사구 사용
  • 객체 생성 불가 클래스 : 복수형 명사
  • 인터페이스 : 클래스와 동일하거나 형용사 (-able, -ible)
  • 애너테이션 : 두루 쓰여 지배적 규칙 x
  • 메서드, 필드 이름 : 동사구
  • 명사구를 사용하는 메서드 vs get- (JavaBeans 스타일)
  • toType, asType
  • 메서드 이름 짓기 너무힘듦... 꿀팁? 🤔
  • 필드 이름 : 덜 중요함 (필드 직접 노출 케이스가 잘 없어야함)