IT/Programming

<Effective Java> RULE 55 신중하게 최적화 하라

서론 · 최적화는 좋을 때 보다 나쁠 때가 더 많으며, 섣불리 시도하면 더욱 나쁘다는 것이다. · 잘못된 최적화는 빠르지도 정확하지도 않으며 쉽게 고칠 수도 없는 시스템으로 이어진다. 본론 · 빠른 프로그램이 아닌 좋은 프로그램을 만들려 노력하라. · 설계할 때는 성능을 제약할 가능성이 있는 결정들은 피하라. ㄴ 모듈간 상호작용이나 외부와의 상호작용을 명시한 부분은 성능을 고치기가 까다롭다. · API를 설계할 때 내리는 결정들이 성능에 어떤 영향을 끼칠지를 생각하라. ㄴ public자료형을 변경 가능하게 만들면 쓸데없이 방어적 복사를 많이해야 할 수 있다. · 좋은 성능을 내기 위해 API를 급진적으로 바꾸는 것은 바람직 하지 않다. ㄴ 다음번 릴리즈때 플랫폼이나 기타 내부 소프트웨어가 바뀌면 성능문제..

2023. 4. 26. 13:34
IT/Programming

<Effective Java> RULE 56 일반적으로 통용되는 작명 관습을 따르라

철자에 관계된 작명 관습 패키지 · 패키지 이름은 마침표를 구분점으로 사용하는 계층적이름이어야한다. · 이름을 구성하는 각각 컴포넌트는 알파벳 소문자로 구성, 숫자는 거의 사용하지 않는다. · 해당 조직의 도메인 이름으로 시작한다. ㄴ ex) edu.cmu, com.sun.. · 패키지 이름의 나머지 부분은 하나 이상의 컴포넌트로 구성 ㄴ ex) util, awt 클래스 · 첫 글자는 대문자 · 약어 사용은 피하도록 인터페이스 · 클래스와 비슷한 작명 규칙 · 추가로 able, ible 형용사격 도 추가 ㄴ ex) Runnable, Iterable 메서드 · 첫 글자는 소문자 필드 · 상수 필드의 이름은 하나 이상의 대문자, 단어 사이에는 _ ㄴ ex) NEGATIVE_INFINITY · 지역 변수의 이..

2023. 4. 26. 13:33
IT/Programming

<Effective Java> RULE 57 예외는 예외적 상황에만 사용하라

예외는 예외적 상황에만사용해야 한다. 평상시 흐름제어에 이용해서는 안된다. 잘 설계된 API는 클라이언트에게 평상시 제어 흐름의 일부로 예외를 사용하도록 강요해서는 안된다. 상태검사 메서드 ㄴ ex) Iterator interface // for문을 통해 Iterator i의 값을 불러온다. // hasNext()를 통해 다음 값으로 넘어간다. for (Iterator i = collection.iterator(); i.hasNext();){ Foo foo = i.next(); }... // while문의 흐름제어로 Exception을 사용하고 있다. // 이러면 곤란하다. try{ Iterator i = collection.iterator(); while(true){ Foo foo = i.next();..

2023. 4. 26. 13:32
IT/Programming

<Effective Java> RULE 58 복구가능상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행 지점 예외를 이용하라.

자바의 세가지 종류의 'throwable' · 점검 지정 예외(checked exception) ㄴ 반드시 처리해야하며 컴파일 시점에 확인된다. ㄴ ex) exception의 상속 받는 하위 클래스 중 Runtime Exception을 제외한 모든 예외 · 실행 시점 예외(runtime exception) ㄴ 명시적으로 처리하지 않아도 되며 런타임 시점에 확인된다. ㄴ ex) runtime exception 하위 예외 · 오류(error) 점검지정 예외 언제 사용해야 하나? · 호출자(caller)측에서 복구할 것으로 여겨지는 상황에 대해서는 점검지정 예외를 이용해야 한다. · 점검 지정 예외를 던지는 곳은 해당 예외를 catch절에서 처리 무점검 예외와 실행시점예외는 오류 두가지가 있다. · 둘다 ca..

2023. 4. 26. 13:32
IT/Programming

<Effective Java> RULE 59 불필요한 점검지정 예외 사용은 피하라

점검지정 예외는 프로그래머로 하여금 예외적인 상황을 처리하도록 강제함으로써 안정성을 높인다. 하지만 너무 자주 사용하게 된다면 처리해야하는 상황이 많아지기 때문에 불편한 API가 되어 버릴 수가 있다. 메서드가 던지는 점검지정 예외가 하나뿐일 때 하나의 예외때문에 try문안에 메소드를 호출해야 하는 것이 불편할 것이다. 이러한 상황에 처하면, 점검지정 예외를 없앨 방법이 없을지 고민해봐야 한다. 하나이상의 점검지정 예외를 던지는 메서드를 호출할 때에는 예외를 받아 처리하는 catch블록을 하나 이상을 만들거나 예외를 다시 밖으로 던진다고 선언하고 외부로 전파해야 한다. 결론 · API사용자가 점검지정 예외를 하나만 사용하는것은 부담이 된다. · 점검지정 예외를 무점검 지정으로 바꾸는 방법을 통해 해결한다..

2023. 4. 26. 13:31
IT/Programming

<Effective Java> RULE 60 표준 예외를 사용하라

프로그래밍 전문가는 코드 재사용을 위해 노력할 뿐만 아니라 높은 수준으로 코드를 재사용한다. 이미 있는 예외를 사용하는 좋은 장점 · 배우기 쉽고 사용하기 편리한 API를 만들기 쉽다. · 구현된 API는 가독성이 높아진다. 가장 많이 사용되는 예외 · IllegalArgumentException : 잘못된 인자를 던졌을 시 · IllegalStateException : 현재 객체 상태로는 호출할 수 없는 메서드를 호출 했을 때 · NullPointerException : null값을 받으면 안되는 인자에 null값이 전달 되었을 때 · ConcurrentModificationException : 하나의 스레드만 사용하도록 설계된 객체나 외부적인 동기화 수단과 함께 이용되어야 하는 객체를 여러 스레드가 ..

2023. 4. 26. 13:31
반응형