본문 바로가기

Dev Book Review/Effective Java

Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] Item20. 추상 클래스 보다는 인터페이스를 우선하라 자바의 다중 구현 메커니즘 : 둘다 인스턴스 메서드를 구현 형태로 제공할 수 있다 (default method) 인터페이스 : 다중 상속, 같은 타입 취급 추상클래스 : 단일 상속, 하위 클래스 (상하 관계) 1. 인터페이스의 장점 a. 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을 수 있다. 인터페이스 : 요구하는 메서드를 추가하고, 클래스 선언에 implements 구문만 추가하면 끝이다. 추상클래스 : 계층 구조상 확장시킨 클래스의 공통 조상이 되어, 클래스 계층 구조를 생각해야한다. b. 믹스인 정의에 안성맞춤이다. 믹스인 : 클래스가 구현할 수 있는 타입. 믹스인을 구현한 클래스에 원래의 '주된 타입'외에도 선택적 기능을 '혼합'하여 사용한다. 추상클래스 : 기존 클래스에 덧씌울 수 없..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item 19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았다면 상속을 금지하라 1. 재정의 메서드의 문서화 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야한다. 재정의 가능 메서드 : 호출 메서드의 API 설명에 기술, 호출 순서, 각각의 호출 결과 처리 영향 기술 호출할 수 있는 모든 상황을 남긴다. 백그라운드 스레드, 정적 초기화 과정에서 호출이 일어날 수 있는 상황 등 API 문서의 Implementation Requirements : 메서드의 내부 동작 방식 설명 메서드 주석에 @ImplSpec 태그를 붙여주면 자바독 도구가 생성된다. 좋은 API문서란 '어떻게'란 '무엇'을 하는지를 설명해야한다. 대치된다 : 그러나 상속이 캡슐화를 해치기 때문에 어쩔수 없다 - 클래스를 안전하게 상속할 수 있게 해야하기 때문 2. 상속 설..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] Item18. 상속보다는 컴포지션을 사용하라 상속이 안전 할 때 상위 클래스와 하위클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서 사용한다. 확장할 목적으로 설계되었고 문서화도 잘되었다. 상속이 안전하지 않을때 다른 패키지의 구체 클래스를 상속하는 것은 위험하다. 1. 하위 클래스가 깨지기 쉬운 이유 상속은 캡슐화를 깨뜨린다. 상위클래스의 구현에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상위클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 하위 클래스가 오동작할 수 있다. a. 자신이 다른 부분을 사용하는 자가사용 여부 public class InstrumentedHashSet extends HashSet{ private int addCount = 0; @Overrid public boolean add(E e){ add..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item17. 변경가능성을 최소화하라 불변 클래스 : 그 인스턴스의 내부 값을 수정할 수 없는 클래스 예 ) String, Wrapper Class, BigInteger, BigDecimal - 설계 구현 사용이 쉽다. 오류 여지가 적고 안전하다. 1. 불변 클래스 5가지 규칙 ㄱ. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. (setter) ㄴ. 클래스를 확장할 수 없게 한다. (extend X) ㄷ. 모든 필드를 final로 선언한다 ㄹ. 모든 필드를 private으로 선언한다. ​ [아이템 15] : 클래스와 멤버의 접근권한을 최소화하라 ​ [아이템 16] : public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 ㅁ. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 객체 참조 X - ge..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] Item16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 1. public 클래스의 가변 필드 절대 가변 필드를 public으로 노출하면 안된다. 캡슐화의 이점을 제공하지 못한다. API를 수정하지 않고는 내부 표현을 바꿀 수 없다. 불변식을 보장할 수 없다. 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. 패키지 바깥에서 접근할 수 있는 클래스라면 접근자(getter)를 제공하자. 클래스 내부 표현 방식을 언제든 바꿀 수 있다. package-private 클래스, private 중첩 클래스 는 데이터 필드를 노출해도 하등의 문제가 없다. package-private : 패키지 바깥 코드를 손대지 않고 데이터 표현 방식을 바꿀 수 있다. private 중첩 : 이 클래스를 포함하는 외부 클래스까지로 제한한다. 2. public 클래스의 불변 필드 ..
Dev Book Review/Effective Java 2020. 5. 5. [Effective Java] item 15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트 : 클래스 내부 데이터와 내부 구현정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는가 오직 API를 통해서만 다른 컴포넌트와 소통한다. [정보은닉, 캡슐화] 1. 정보 은닉의 장점 시스템 개발 속도를 높인다 - 여러 컴포넌트 병렬 개발 시스템 관리 비용을 낮춘다 - 컴포넌트 교체 비용 하락 성능 최적화에 도움이 된다 - 완성된 시스템을 프로파일리하고 최적화할 컴포넌트만 가능하다. [아이템 67 - 최적화는 신중히 하라] 소프트웨어 재사용성을 높인다 - 의존성이 낮은 컴포넌트라면 다른 환경에서도 유용 큰 시스템을 제작하는 난이도를 낮춘다 - 개별 컴포넌트 동작 검증 2. 정보 은닉 기본원칙 모든 클래스와 멤버의 접근성을 가능한 한 좁힌다 (최대한 public을 지양하는 듯) 접근성 : 요소가..
Dev Book Review/Effective Java 2020. 4. 19. [Effective Java] Chapter 3: 모든 객체의 공통 메서드 Item10. equals는 일반 규약을 지켜 재정의하라 필요한 경우가 아니라면 equals를 재정의 하지말자. 많은 경우에 Object의 equals가 우리가 원하는 비교를 정확히 수행해준다. 재정의해야 할 때는 그 클래스의 핵심필드 모두를 빠짐없이 5가지 규약을 지켜가며 비교해야한다. equals의 5가지 규약 : 반사성, 대칭성, 추이성, 일관성, null-아님 Link : https://jyami.tistory.com/66 item10. equals는 일반 규약을 지켜 재 정의하라 1. equals를 재정의 하면 안되는 경우 equals는 재정의하기 쉬워보이지만 곳곳에 함정이 있다. 문제를 회피하는 가장 쉬운 길은 아예 재정의하지 않는 것 a. 각 인스턴스가 본질적으로 고유할 때 값 표현 객체가...
Dev Book Review/Effective Java 2020. 4. 19. [Effective Java] item 14. Comparable을 구현할지 고려하라 1. compareTo()와 equals()의 차이 compareTo는 Object의 메서드가 아니다. 성격은 두가지만 빼면 Object의 equals와 같다. compareTo는 단순 동치성 비교에 더해 순서까지 비교 가능하다. 그 클래스의 인스턴스들에 자연적인 순서가 있음을 뜻할 수 있다. 그래서 Comparable을 구현한 객체들의 배열은 손쉬운 정렬이 가능하다. 알파벳, 숫자, 연대 등 순서가 명확한 값 클래스 작성할땐 구현하자. 2. CompareTo() 메서드 규약 equals와 같은 내용이다 (주의점, 우회법 모두 같다.) this object : 1 ㄱ. 반사성, 대칭성, 추이성을 충족해야한다 ● sgn(x.compar..

티스토리툴바