Book Review/effective-java

Book Review/effective-java

[ITEM42] 익명 클래스보다는 람다를 사용하라

ITEM 42 익명 클래스보다는 람다를 사용하라 자바 8 이전에는 다음과 같이 익명 클래스를 사용했다. @Test @DisplayName("자바8 이전에 사용하던 익명클래스") void anonymousClass() { List word = new ArrayList(List.of("ab","abc","a")); Collections.sort(word, new Comparator() { @Override public int compare(String o1, String o2) { return Integer.compare(o1.length(), o2.length()); } }); } 하지만 자바 8 이후부터 인터페이스 내에 추상 메서드가 단 하나만 존재하면 람다식을 사용할 수 있게 되었다. 위에서 사용하던 ..

Book Review/effective-java

[ITEM22] 인터페이스는 타입을 정의하는 용도로만 사용하라

ITEM 22 인터페이스는 타입을 정의하는 용도로만 사용하라 서론 클래스가 어떤 인터페이스를 구현한다는 것은 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는 용도로만 사용해야 한다. 용도에 맞지 않은 인터페이스 사용 예를 들어 상수 인터페이스가 있다. public interface PhysicalConstants { // 아보가드로 수 (1/몰) double AVOCADOS_NUMBER = 6.022_140_857e23; // 볼츠만 상수 (J/K) double BOLTZMANN_CONSTANT = 1.380_648_52e-23; // 전자 질량(kg) double ELECTRON_MASS = 9.109_383_56e-31; } 클래스 내부에서 사용하는 상수는 외부 인터페이스(상수 인터페..

Book Review/effective-java

[ITEM21] 인터페이스는 구현하는 쪽을 생각해 설계하라

서론 자바 8 이전에 인터페이스에 새로운 메서드를 추가하게 되면 메서드를 추가한 인터페이스를 구현하고 있는 하위 클래스에서 대부분 컴파일 오류가 날 것이다. 하지만 자바 8이후 default 메서드를 추가할 수 있게 되었다. 따라서 인터페이스내에 default 메서드를 추가해도 하위 클래스에서는 컴파일 오류는 발생하지 않는다. 그렇다면 default 메서드를 추가함으로써 발생하는 위험은 없을까? 기존 인터페이스에 default 메서드를 추가함으로써 발생하는 위험 자바 8 이전의 모든 클래스는 인터페이스에 새로운 메서드가 추가 될일 없다고 가정하고 작성됐었다. 디폴트 메서드는 구현 클래스에 대해 아무것도 모른채 메서드가 추가가 되는 것이다. 이러한 경우 대부분 상황에서 잘 작동하지만 모든 상황에서 불변식을..

Book Review/effective-java

[ITEM20] 추상 클래스보다는 인터페이스를 우선하라.

ITEM 20 추상 클래스보다는 인터페이스를 우선하라. 서론 자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스이다. 두 메커니즘의 차이점은 다음과 같다. 추상 클래스: 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다. 인터페이스:선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다. 이러한 차이점이 생기는 이유는 자바는 다중 상속을 지원하지 않기 때문이다. 해당 부분은 백기선 라이브 스터디 8 주차 인터페이스에서 자세히 설명했습니다. 인터페이스의 장점 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을 수 있다. 인터페이스가 요구하는 메서드를 추가하고 클래스 선언에 impleme..

Book Review/effective-java

[ITEM18] 상속보다는 컴포지션을 사용하라

ITEM 18 상속보다는 컴포지션을 사용하라. 서론 메서드 호출과 달리 상속은 캡슐화를 깨트린다. -> 상위 클래스의 구현에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 당장 문제가 발생하지 않아도 상위 클래스의 릴리즈마다 내부 구현이 변함에 따라 오작동할 수 있다. 의도하지 않은 오류 예제. public class InstrumentedHashSet extends HashSet { private int count; public InstrumentedHashSet(){ } public InstrumentedHashSet(int initialCapacity, float loadFactor) { super(initialCapacity, loadFactor); } @Override public boole..

Book Review/effective-java

[ITEM17]변경 가능성을 최소화하라

ITEM 17 변경 가능성을 최소화하라 서론 불변 클래스는 가변 클래스보다 설계, 구현하기가 쉽다. 또한 오류가 생길 여지도 적고 훨씬 안전하다. 클래스를 불변으로 만드는 5가지 규칙 객체 상태를 변경하는 메서드(변경자)를 제공하지 않는다.( ex: setter 메서드 ) 클래스를 확장할 수 없도록 한다. 모든 필드를 final로 선언한다. 모든 필드를 private 으로 선언한다. 자신 외에는 내부 가변 컴포넌트에 접근할 수 없도록 한다. -> 만약 접근자 메서드를 통해 내부 가변 값을 반환해야 한다면 방어적 복사를 수행하자. 불변 객체의 장점 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다. -> 객체의 변동이 없으니 여러 스레드에서 접근해도 절대 훼손되지 않는다. 한번 만든 인스턴스..

Book Review/effective-java

[ITEM16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

ITEM 16 public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 서론 public 필드를 통한 데이터의 접근은 캡슐화의 이점을 제공해주지 못한다. 또한 불변 식을 보장할 수 없으며 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. 접근자 메서드를 통해 접근하자! public 클래스라면 패키지 바깥에서 접근할 수 있는 getter 메서드를 만들어주자. 만약 public 필드로 노출하게 되면 다음과 같은 문제점이 발생한다. 캡슐화의 이점을 제공해줄 수 없다. API를 수정하지 않고는 내부 표현을 바꿀 수 없다.(해당 문구는 Setter를 이용하면 유연하게 변경할 수 있다는 뜻인 것 같다.) 불변식을 보장할 수 없다.(이 부분도 public 필드로 들어갈 값들에 대한 검증을 ..

Book Review/effective-java

[ITEM15] 클래스와 맴버의 접근 권한을 최소화하라

ITEM 15 클래스와 멤버의 접근 권한을 최소화하라. 서론 잘 설계된 컴포넌트와 어설프게 설계된 컴포넌트의 차이는 클래스의 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 은닉화을 했는가 이 부분에서 결정된다 (정보은닉 , 캡슐화) 정보 은닉의 장점. 시스템 개발속도를 높인다(여러 컴포넌트를 병렬로 개발할 수 있기 때문) 시스템 관리 비용을 낮춘다.(컴포넌트가 분리되어있기 때문에 디버깅과 교체가 쉬움) 정보은닉 자체가 성능을 높여주지는 않지만 성능 최적화에 도움을 준다.(아이템 67) 소프트웨어 재사용성을 높인다(컴포넌트 간 의존성이 낮아지기 때문에) 큰 시스템을 제작하는 난이도를 낮춰준다(개별 컴포넌트의 동작을 검증할 수 있기 때문 1번 장점이랑 비슷한 느낌? ) 자바에서 정보은닉을 위한 ..

jay Joon
'Book Review/effective-java' 카테고리의 글 목록