코딩하는 털보

package me.rockintuna.effectivejava.item;/*인터페이스는 타입을 정의하는 용도로만 사용하자 */public class Item22 implements Item22Interface{ public static void main(String[] args) { //인터페이스를 구현한 클래스의 인스턴스는 그 인터페이스 타입이 된다. Item22Interface demo = new Item22(); }}interface Item22Interface { }class Item22NoConstants implements Item22InterfaceConstants { public static void main(String[] a..

package me.rockintuna.effectivejava.item;import org.apache.commons.collections4.collection.SynchronizedCollection;import java.util.ArrayList;import java.util.Collection;/*인터페이스는 구현하는 쪽을 생각해 설계하자 */public class Item21 implements Item21Interface{ public static void main(String[] args) { /* 모든 상황에 대해 불변식을 지키는 디폴트 메서드를 작성하기는 어렵다. */ Collection memberList = Synchronize..

package me.rockintuna.effectivejava.item;/*상속보다는 컴포지션을 사용하라 */public class Item18 extends Item18SuperClass { /* 내가 제어할 수 없는 다른 패키지의 상위 클래스를 상속받았을 때 문제다. 이 상위 클래스에서 상속받아 사용할 수 있는 내부 구현이 달라지는 경우, 해당 내부 구현을 사용하는 메서드에서 오류가 발생하기 쉽다. 상위 클래스 변화에 따라 하위 클래스 모두 변경해야 할 수 있다. */ @Override public String getName() { return super.getName(); } /* 상위 클래스를 완벽히 이해하지 않는이상 재정..

package me.rockintuna.effectivejava.item;import java.math.BigInteger;/*변경 가능성을 최소화하라 */public final class Item17 { /* 불변 객체 : 생성된 시점부터 파괴될 때 까지 상태가 변경되지 않는 객체 클래스를 불변으로 만들기 1. setter가 없어야함 2. 클래스를 확장할 수 없어야함 (대표적으로 final 클래스) 3. 모든 필드를 private final로 선언 4. 가변 객체를 참조하는 필드가 있다면 해당 필드를 사용하는 생성자, getter, readObject 메서드에서 방어적 복사를 한다. 불변으로 만들 수 없다면 변경할 수 있는 부분을 최소화하자 - 별다른 ..

package me.rockintuna.effectivejava.item;import java.util.List;/*public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 */public class Item16 { public List memberList; /* public class에서 public 필드를 사용하면 1. 내부 표현을 변경하려면 API가 변경되어야 한다. : public class의 public 필드 자체가 API 이면서 내부 표현이기 때문 2. 불변식을 보장할 수 없다 : 클라이언트에서 언제든지 필드의 인스턴스를 변경하거나 수정할 수 있다. 3.부수 작업을 수행할 수 없다. : 접근자 메서드에서는 부가 작업을 추가..

package me.rockintuna.effectivejava.item;import java.util.List;/*클래스와 멤버의 접근 권한을 최소화 하라*/public class Item15 { /* 정보 은닉, 캡슐화의 장점 컴포넌트들을 서로 독립시킨다. => 개발,테스트,최적화,적용,분석,수정을 개별적으로 할 수 있게 해준다. - 개발 속도 (병렬 개발) - 관리 비용 (유지보수 쉬움) - 유닛 테스트를 통한 컴포넌트 성능 최적화 - 재사용성 - 거대한 시스템 개발을 쉽게 해줌 Java의 정보 은닉 장치 [접근 제한자]를 통해 모든 클래스와 멤버의 접근성을 가능한 좁히자. public 접근 제한자 => 외부 접근을 허용한다는 것 (API)..

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

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

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

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