코딩하는 털보

이펙티브 자바, 아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하는 것음 어렵다. 예를 들면 자바 8 Collection 인터페이스에 추가된 디폴트 메서드는 여러 서드파티 컬렉션 구현체에서 재정의 되지 않은 경우가 많기 때문에 동기화를 하지 못하는 등 여러 문제가 발생한다. 디폴트 메서드는 기존 구현체이 런타임 오류를 일으킬 수 있다. 디폴트 메서드를 추가하면 기존 구현체에 영향을 줄 수 있다. 기존 인터페이스에 새로운 디폴트 메서드를 추가하는 일은 꼭 필요한 경우가 아니라면 피해야한다. 핵심은 디폴트 메서드라는 도구가 있지만 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야 한다는 것. 새로운 인터페이스라면 릴리스 ..

이펙티브 자바, 아이템 20. 추상 클래스보다는 인터페이스를 우선하라 인터페이스를 우선해야 하는 이유 추상 클래스를 구현하려면 추상 클래스를 상속해야 한다. 자바는 단일 상속만 지원하므로 이 방식은 새로운 타입을 정의하는 데 커다란 제약을 안게 된다. 인터페이스는 기존 클래스에서 손쉽게 구현해넣을 수 있다. 인터페이스는 믹스인(mixin) 정의에 안성맞춤이다. mixin : 클래스가 구현할 수 있는 타입, 믹스인을 구현한 클래스에 원래의 '주된 타입'외에 특정 선택적 행위를 제공한다고 선언하는 효과를 준다. (ex Comparable, Serializable, ...) 추상 클래스는 위에 나온 제약 때문에 믹스인을 정의할 수 없다. 인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 ..

이펙티브 자바, 아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 상속을 고려한 설계와 문서화가 뜻하는 것. 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다. 상속용 클래스의 메서드에서 자신의 다른 메서드를 호출할 수도 있는데(자기사용) 호출되는 메서드가 재정의될 수 있다면 클래스를 상속하여 메서드를 재정의할 때 문제가 발생할 수 있다. 때문에 자기사용에 대한 내용을 API 설명에 적시해야 한다. 백그라운드 스레드나 정적 초기화 과정에서도 메서드가 호출되어 자기사용이 발생할 수 있다. @implSpec 어노테이션은 자바독 도구가 API문서에 Implementation Requirements로 시작하는 메서드 내부 동작 방식 설명..

이펙티브 자바, 아이템 18. 상속보다는 컴포지션을 사용하라 동일한 패키지 안에서의 상속이나 확장할 목적으로 설계되었고 문서화도 잘 된 클래스의 상속은 안전하다. 그러나 일반적인 콘크리트 클래스를 패키지 경계를 넘어서 다른 패키지의 콘크리트 클래스를 상속하는 일은 위험하다. 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 다르게 말하면, 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 특히 상위 클래스의 메서드를 재정의해서 사용했을 때 문제가 발생하기 쉽다. 또는 하위 클래스에서 새로운 메서드를 만들때도 상위 클래스의 변경으로 인한 영향이 없다고 할 수는 없다. 상속 대신 컴포지션을 사용하자. 기존 클래스를 확장하는 대신 새로운 클래스에서 private 필드로 기존 클래..

이펙티브 자바, 아이템 17. 변경 가능성을 최소화하라 불변 객체는 단순하다. 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉽고 오류가 생길 여지가 적어 안전하다. 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소화하자. 불변 클래스 만들기 규칙 setter를 제공하지 않는다. getter가 있다고 해서 무조건 setter를 만들지는 말자. 클래스를 확장할 수 없게 막는다. 가장 쉬운 방법은 final 클래스로 만들기. 또는 모든 생성자를 private 또는 package-private으로 만들고 정적 팩토리를 제공하기. 모든 필드를 final로 선언한다. 모든 필드를 pr..

이펙티브 자바, 아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 public 클래스의 public 필드는 API를 수정하지 않고는 (API를 사용하는 클라이언트에 피해를 줄 수 있으므로)내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. 필드를 private으로 바꾸고 접근자 및 변경자 메서드를 활용하자. public class Point { private final int x; private final int y; public Point(int x, int y) { this.x = x; this.y = y; } public int getX() { return x; } public int getY()..

이펙티브 자바, 아이템 15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 정보 은닉의 장점 각 컴포넌트를 병렬로 개발할 수 있기 때문에 개발 속도를 높인다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고 교체하는 부담도 적기 때문에 관리 비용을 낮춘다. 다른 컴포넌트에 영향을 주지 않고 최적화할 수 있기 때문에 성능 최적화에 도움을 준다. 외부에 의존하지 않고 독자적으로 동작하는 컴포넌트는 재사용성이 높다. 개별 컴포넌트 동작 검증으로 큰 시스템을 제작하는 난이도를 낮춰준다. 접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심이다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다. 클래스의 접근 제한자 톱레벨 ..

이펙티브 자바, 아이템 14. Comparable을 구현할지 고려하라 Comparable 인터페이스의 compareTo를 구현하여 사용하는 것을 고려해 볼 수 있다. compareTo 메서드는 Object의 equals와 두 가지 차이가 있다. 단순 동치성 비교에 더해 순서까지 비교할 수 있다. Comparable을 구현했다는 것은 인스턴스들에 자연적인 순서가 있음을 뜻한다. 알파벳, 숫자, 연대 처럼 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자. compareTo 규약을 지키지 못하면 비교를 활용하는 클래스와 어울리지 못한다. (ex. TreeSet, TreeMap 또는 Collections와 Arrays의 정렬) compareTo 메서드로 수행하는 동치성 검사..

이펙티브 자바, 아이템 13. clone 재정의는 주의해서 진행하라 Java 제공 인터페이스 Cloneable는 아무 메서드도 가지고 있지 않지만 이 인터페이스를 구현하는 인스턴스에서는 Object의 clone 메서드의 동작이 바뀐다. Cloneable을 구현한 인스턴스에서 clone 메서드를 호출하게 되면, 해당 객체를 복사한 객체를 반환하게 된다. Object의 clone 메서드는 protected이기 때문에 외부 객체에서 사용하려면 재정의가 필요하다. Object clone()은 Object 타입을 반환하기 때문에 공변 반환 타입을 통해서 Object 대신 재정의하는 클래스 타입으로 캐스팅하여 반환하도록 재정의하는게 좋다. 공변 반환 타입 : 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반..

이펙티브 자바, 아이템 12. toString을 항상 재정의하라 toString의 일반 규약, 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보, 모든 하위 클래스에서 이 메서드를 재정의하라. Object의 기본 toString은 클래스이름@16진수해시코드를 반환하며, 그다지 쓸모 없는 메시지를 출력하게 된다. toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. toString은 우리가 직접 호출하지 않아도 다른 어딘가에서 쓰일 수 있다. 실전에서 toString은 그 객체가 가진 주요 정보를 모두 반환하는 게 좋다. PhoneNumber에서 지역 번호만 toString에 담았다고 가정한다. @Override public String toString..