코딩 잘하고 싶어

마커 인터페이스 자신을 구현하는 클래스가 특정 속성을 가짐을 나타내는 인터페이스 아무 메서드도 담고 있지 않음 예를 들어 Serializable , Cloneable 인터페이스 마커 인터페이스가 마커 애너테이션보다 좋은점 1) 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있으나 마커 애너테이션은 그렇지 않다. → 컴파일타임에 오류 검출 가능 Serializable의 writeObject() : 매개변수에서 Serializable 타입인지 확인을 안하고, Object 로 받아 instanceof로 타입검사를 하고 있다. → 직렬화할 수 없는 객체를 넘기면 런타임 오류로 발견할 수가 있다. → 마커 인터페이스의 장점인 컴파일 오류 검출을 살리지 못한 케이스이다. 2) 적용 대..

@Override 자바가 기본으로 제공하는 애너테이션 중 중요한 애너테이션 메서드 선언에만 달 수 있는 애너테이션 상위 타입의 메서드를 재정의했음을 뜻함 → 버그 예방 만약, equals 메서드를 다음과 같이 재정의하였다면? public boolean equals(Bigram bigram) { return bigram.first == this.first && bigram.second == this.second; } 위의 equals 메서드는 재정의(overriding)한게 아니라 다중정의(overloading) 해버렸다. Object의 equals 를 재정의하려면 매개변수 타입을 Object로 해야하는데 그렇게 하지 않았다. 실수로 별개인 equals를 새로 정의한 꼴이 되었다. 만약 그냥 위와 같이 코..

명명 패턴 전통적으로 도구나 프레임워크가 특별히 다뤄야할 프로그램 요소에는 딱 구분되는 명명패턴을 적용해왔다. ex) JUnit3의 테스트 메서드 이름을 test로 시작하게함 //JUnit3 : 메서드 이름을 test로 시작해야함 public class helloTest extends TestCase { public void testHello(){ String hello = "hello" } } //JUnit4 : @Test 애너테이션을 사용해 테스트 public class helloTest { @Test public void testHello(){ String hello = "hello" } } 명명 패턴의 단점 오타가 나면 안됨 올바른 프로그램 요소에서만 사용될 보증 없음 프로그램 요소를 매개변수로 ..

열거타입을 확장하는 것은 대부분의 상황에서 좋지 않다. 그러나, 어울리는 쓰임이 최소한 하나는 있는데 연산 코드다. API가 제공하는 기본 연산 외에 사용자 확장 연산을 추가할 수 있도록 열어줘야할 때가 있다. 열거 타입 자체로는 확장을 할 수 없지만, 인터페이스와 그 인터페이스를 구현하는 열거타입을 이용하여 그 효과를 낼 수 있다. (열거 타입이 인터페이스를 구현할 수 있다는 사실 이용) public interface Operation { double apply(double x, double y); } public enum BasicOperation implements Operation { PLUS("+") { public double apply(double x, double y) { return x ..

ordinal 메서드로 인덱스를 얻는 코드가 있다. Set[] plantsByLifeCycle = new Set[Plant.LifeCycle.values().length]; for (int i = 0; i < plantsByLifeCycle.length; i++) { plantsByLifeCycle[i] = new HashSet(); } for (Plant p : garden) { plantsByLifeCycle[p.lifeCycle.ordinal()].add(p); } // 인덱스의 의미를 알 수 없어 직접 레이블을 달아 데이터 확인 작업 필요 for (int i = 0; i < plantsByLifeCycle.length; i++) { System.out.printf("%s: %s%n", Plant...

열거한 값들이 집합으로 사용될 경우, 예전에는 각 상수에 서로 다른 2의 거듭제곱 값을 할당한 정수 열거 패턴을 사용해왔다. //비트 필드 열거 상수 - 구닥다리 기법! public class Text { public static final int BOLD = 1

대부분의 열거 타입 상수는 자연스럽게 하나의 정숫값에 대응됨 모든 열거 타입의 ordinal 메서드 : 해당 상수가 그 열거 타입에서 몇번쨰 위치인지 반환 public enum Number { ONE, TWO, THREE, FOUR pbulic int convertInt() { return ordinal() + 1; } } 위 코드는 유지보수에 안좋다. 상수 선언 순서를 바꾸면 converInt가 오동작하고, 이미 사용중인 정수와 값이 같은 상수는 추가할 방법이 없다. 그리고 중간에 비워놓지도 못한다. 해결책은 열거 타입 상수에 연결된 값은 ordinal 메서드로 얻지 말고 인스턴스 필드에 저장해라. puplic enum Number { ONE(1), TWO(2), THREE(3), FOUR(4) pri..

열거 타입은 고정된 상수의 집합으로, 그 외의 값은 허용하지 않는 타입이다. ex) 계절 열거 타입이 자바에 추가되기 전엔 정수 상수를 열거하는 취약한 방법 사용 public static final int APPLE_FUJI = 0; public static final int APPLE_PIPPIN = 1; public static final int APPLE_GRANNY_SMITH = 2; public static final int ORANGE_NAVEL = 0; public static final int ORANGE_TEMPLE = 1; public static final int ORANGE_BLOOD = 2; 위와 같은 방식은 상당히 취약 타입 안전 보장 x 표현력 좋지 않음. 컴파일러가 이해하는 ..