반응형 Java/Effective Java 3E61 [이펙티브자바 3판] ITEM18. 상속보다는 컴포지션을 사용하라 이번장의 핵심은... 상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다 잘못 사용하면 오류를 내기 쉬운 소프트웨어를 만들게 된다 안전한 상속과 위험한 상속이란? 안전한 상속 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서 상속을 뜻한다 확장할 목적으로 설계되었고 문서화도 잘 된 클래스이다 위험한 상속 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일을 뜻한다 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다 확장을 충분히 고려하지 않으면 하위 클래스는 상위 클래스의 변화에 발맞춰 수정돼야만 한다 예제) HashSet을 만들어 추가된 원소의 수를 저장.. 2020. 9. 20. [이펙티브자바 3판] ITEM17. 변경 가능성을 최소화하라 이번장의 핵심은... Getter가 있다고 무조건 Setter를 만들지 말자 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자 다른 합당한 이유가 없다면 모든 필드는 private final 이어야 한다 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다 확실한 이유가 없다면 생성자와 정적 팩토리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다 불변 클래스? 불변 클래스란 그 인스턴스 내부 값을 수정할 수 없는 클래스이다 (간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다) 자바 플랫폼 라.. 2020. 9. 19. [이펙티브자바 3판] ITEM16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 이번장의 핵심은... public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다 하지만, package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다 우선 아래의 퇴보한 클래스를 보자 class Point { public double x; public double y; } 왜 퇴보한 클래스인가? 단순히 인스턴스 필드들을 모아놓는 일 외에는 아무 목적이 없는 퇴보한 클래스이다 데이터 필드에 직접 접근할 수 있으니 캡슐화 이점도 없다 API를 수정하지 않고도 내부 표현을 바꿀 수 있고, 불변식을 보장할 수 없다 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다 .. 2020. 9. 18. [이펙티브자바 3판] ITEM15. 클래스와 멤버의 접근 권한을 최소화하라 이번장의 핵심은... 프로그램 요소의 접근성은 가능한 한 최소한으로 하자 꼭 필요한 것만 골라 최소한의 public API를 설계하자 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다 public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드를 가져서는 안 된다 public static final 필드가 참조하는 객체가 불변인지 확인하자 정보 은닉(캡슐화)의 장점 컴포넌트를 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해 준다 1. 시스템 개발 속도를 높인다 (여러 컴포넌트를 병렬로 개발할 수 있다) 2. 시스템 관리 비용을 낮춘다 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있.. 2020. 9. 16. [이펙티브자바 3판] ITEM14. Comparable을 구현할지 고려하라 이번장의 핵심은... 순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인터페이스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야 한다 compareTo() 메서드에서 필드의 값을 비교할 때, ""연산자는 쓰지 말도록 하자 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare() 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자 Comparable 인터페이스 compareTo()는 Object의 메서드가 아니다 성격은 2가지만 빼면 Object의 equals()와 같다 compareTo()는 단순 동치성 비교에 더해 순서까지 비교할 수 있다 Comparable을 구현했다는 것은 해당 클래스의 .. 2020. 9. 14. [이펙티브자바 3판] ITEM13. clone 재정의는 주의해서 진행하라 이번장의 핵심은... 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안되며, 새로운 클래스도 이를 구현해서는 안 된다. final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야 한다. 기본 원칙은 '복제 기능은 생성자와 팩토리를 이용하는 게 최고'라는 것이다. 단, 배열만은 clone 메서드 방식이 가장 깔끔하고, 이 규칙의 합당한 예외로 볼 수 있다. Cloneable 인터페이스 클래스에서 clone을 재정의 하기 위해선 해당 클래스에 Cloneable 인터페이스를 상속받아 구현해야 한다 그런데 clone 메소드는 Cloneable 인터페이스가 아닌 Object에 선언되어 있다 Cloneable .. 2020. 9. 13. [이펙티브자바 3판] ITEM12. toString을 항상 재정의하라 이번장의 핵심은... 모든 구체 클래스에서 Object의 toString을 재정의하자 상위 클래스에서 이미 알맞게 재정의한 경우는 예외이다 toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다 Object의 Default toString 메서드는 작성한 클래스의 적합한 문자열을 반환하는 경우는 거의 없다 1. Object의 Default toString 메서드는 단순히 클래스 이름@16진수 해쉬 코드를 반환한다 ex) 클래스 이름이 Jackcoding이면, Jackcoding@adbbd 2. toString의 일반 규약에 따르면 '간결하고 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다 3. toString을 잘 구현한 클래스는 사용하기에 즐겁고, 디버깅이 쉽.. 2020. 9. 12. 이전 1 ··· 4 5 6 7 8 9 다음 반응형
