본문 바로가기

Reading Record/이펙티브자바

ㅤㅤㅤㅤㅤ
By 쟈 미
아이템 [18] - 상속보다는 컴포지션을 사용하라 1. 구체클래스 상속의 위험성 다른 패키지의 구체 클래스를 상속하는 일은 위험하다 (인터페이스 상속말고, 구현 상속에서) 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. - 상위 클래스에 따라 하위클래스의 동작에 문제가 생기기 때문 (상위클래스의 릴리즈가 이뤄진다면?) '자기사용' : 자신의 다른 부분을 사용 > 내부 구현 방식이므로 오픈 api가 아니라 다름 릴리즈 변경, 삭제가능 하위 클래스가 깨지기 쉬운 이유 ㄱ. 상위 클래스의 메서드를 재정의 하여 하위클래스의 로직을 방어한다 (HashSet addAll() 예제) 상위클래스의 메서드 동작을 다시 구현하는게 어렵다. 시간도 더든다. 오류나 성능을 떨어뜨릴 수 있다. 하위클래스에서 접근 불가한 private 클래스를 써야하면 구현이 불가능하다. ㄴ. .. Reading Record/이펙티브자바 2020. 2. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
아이템 [17] - 변경 가능성을 최소화하라 불변 클래스 : 그 인스턴스의 내부 값을 수정할 수 없는 클래스 예 ) String, Wrapper Class, BigInteger, BigDecimal - 설계 구현 사용이 쉽다. - 오류 여지가 적고 안전하다. 1. 불변 클래스 5가지 규칙 ㄱ. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. (setter) ㄴ. 클래스를 확장할 수 없게 한다. (extend X) ㄷ. 모든 필드를 final로 선언한다 ㄹ. 모든 필드를 private으로 선언한다. [아이템 15] : 클래스와 멤버의 접근권한을 최소화하라 [아이템 16] : public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 ㅁ. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. - 객체 참조 X - ge.. Reading Record/이펙티브자바 2020. 2. 26.
ㅤㅤㅤㅤㅤ
By 오늘의 개발
[아이템 15] 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트란? 1. 캡슐화가 얼마나 잘 되었는지. 2. 노출되는 API 와 실제 구현이 얼마나 잘 분리되었는지. 3. 메시지를 주고받는 두 컴포넌트가 서로의 내부 동작을 신경쓰지 않는지. 캡슐화를 잘 지켰을 때의 장점 1. 서로의 구현을 몰라도 되기 때문에 병렬로 개발이 가능하여 개발 속도가 빨라진다. 2. 잘 분리되어있는 컴포넌트는 관리포인트가 작다. 디버깅도 빨리 할 수 있고 다른 컴포넌트로의 교체도 빠르게 할 수 있다. 3. 잘 분리되어있는 컴포넌트는 최적화도 그 컴포넌트만 하면 되기 때문에 좋다. 4. 외부 컴포넌트에 종속되지 않기 때문에 재사용성이 높다. 5. 전체 시스템이 완성되지 않아도 개별 컴포넌트를 검증할 수 있기 때문에 큰 시스템을 개발하는 난이도를 낮춰준다. 캡슐화의 핵심은 .. Reading Record/이펙티브자바 2020. 2. 12.
ㅤㅤㅤㅤㅤ
By gobukgol
아이템[13] - clone 재정의는 주의해서 진행하라 클래스에서 clone을 재정의 하기위해선 해당 클래스에 Cloneable 인터페이스를 상속받아 구현하여야 한다. 그런데 정작 clone 메소드는 Cloneable 인터페이스가 아닌 Object에 선언되어있다. Cloneable 인터페이스에는 아무것도 선언되어있지 않은 빈 인터페이스이다. 그렇다면 Cloneable 인터페이스의 역할은 무엇일까? Cloneable 인터페이스의 역할 Cloneable 인터페이스는 상속받은 클래스가 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스이다. Cloneable 인터페이스의 역할은 Object의 clone의 동작 방식을 결정한다. Cloneable을 상속한 클래스의 clone 메소드를 호출하면 해당 클래스를 필드 단위로 복사하여 반환한다. 만약, Cloneab.. Reading Record/이펙티브자바 2020. 2. 9.
ㅤㅤㅤㅤㅤ
By 오늘의 개발
아이템 [7] - 다 쓴 객체 참조를 해제하라 자바를 사용할 때 "GC"에 의존하여 메모리 자원 관리에 소홀해서는 안된다. GC 의 손이 닿지 않는 자원이 생기지 않도록 주의해야한다. GC 관련 포스팅은> https://javabom.tistory.com/7 Memory Leak 예시 다 쓴 참조(obselete reference) 더이상 사용하지 않지만 참조되어있어 수거되지 않음. 뿐만 아니라 그 객체가 참조하고 있는 또 다른 객체까지 수거되지 않기 때문에 큰 문제가 발생할 수 있음. 메모리 누수 케이스 1. 자기 자신의 자원을 관리하는 클래스 이펙티브 자바 책에서는 Stack 을 예시로 든다. Stack이 자원을 pop 하기만 한다고 GC 대상이 되지는 않는다. 일반적으로 구현하는 pop 의 로직에는 stack size 를 -1 해줄 뿐이기 때문.. Reading Record/이펙티브자바 2020. 2. 8.
ㅤㅤㅤㅤㅤ
By 오늘의 개발
아이템 [3] - private 생성자나 열거타입으로 싱글턴임을 보증하라 싱글턴 인스턴스를 오직 하나만 생성할 수 있는 클래스 ex) 함수 싱글턴의 한계? 싱글턴을 사용하는 클라이언트 테스트가 어렵다. 하나의 자원을 공유하기 때문에 테스트로 써도 되는 클래스인가를 판별해야 하는 것 같다. 예를들어, 실 DB에 접근하는 싱글턴을 테스트에 적용하면 안된다. 싱글턴을 만드는 방법 1. 싱글턴 인스턴스를 public static final 필드로 만들고 생성자를 private 으로 한다. public class Foo{ public static final Foo INSTANCE = new Foo(); private Foo(){}; } @Test public void 싱글턴테스트(){ Foo foo1 = Foo.INSTANCE; Foo foo2 = Foo.INSTANCE; assert.. Reading Record/이펙티브자바 2020. 2. 8.
ㅤㅤㅤㅤㅤ
By ds_chanin
아이템[14] - Comparable을 구현할지 고려하라 아이템[14] - Comparable을 구현할지 고려하라 Comaparable을 구현하면 compareTo를 재정의 하여 손쉽게 컬렉션을 정렬할 수 있다. 따라서 알파벳, 숫자, 연대와 같이 순서가 명확한 클래스를 작성한다면 반드시 Comparable을 구현하도록 하자. Comparable은 compareTo만 가지고 있어 Functional Interface로 착각할 수 있지만 그렇지 않다. Functional Interface은 람다식에 적합한 구조여야 하기 때문이다. * 람다식은 객체 내부의 멤버변수를 우선 순위에 따라 비교하는 Comaprable을 구현하기에 적합하지 않기때문이다. compareTo 메서드의 일반 규약 앞장에서 살펴본 equals의 규약과 비슷하다. 먼저 짚고 넘어갈 compare.. Reading Record/이펙티브자바 2020. 2. 7.
ㅤㅤㅤㅤㅤ
By crud
아이템[11] - equals를 재정의 하려거든 hashCode도 재정의하라 1. equals를 재정의한 클래스는 hashCode도 재정의 해야한다. HashMap이나 HashSet같은 컬렉션의 원소로 사용할 때 문제가 발생한다. 해쉬코드 재정의 조건 equals 비교에 사용되는 정보가 변경되지 않는다면, hashCode는 변하면 안된다. equals가 두 객체가 같다 판단한다면, 두 객체의 hashCode는 똑같은 값을 반환한다. equals가 두 객체가 다르다고 판단해도, hashCode는 꼭 다를 필요는 없다. 하지만 성능을 챙기려면 hashCode값이 달라야 한다. public V get(Object key) { Node e; return (e = getNode(hash(key), key)) == null ? null : e.value; } static final int .. Reading Record/이펙티브자바 2020. 1. 26.

티스토리툴바