이펙티브 자바

정적 팩터리 메서드가 생성자보다 좋은 이유 이름을 가질 수 있다. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다. 반환타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

빌더를 사용해야 하는 이유 빌더의 단점, @Builder

(참고) 싱글톤의 단점 1. 테스트가 어려움 > 23p. 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 타입을 인터페이스로 정의한 다음 그 인터페이스를 구현해서 싱글턴이 아니라면 싱글턴 인스턴스를 가짜(mock) 구현으로 대체할

정적 메서드, 정적 필드만을 담은 클래스가 간혹 존재한다. 정적 메서드만 있는 유틸리티 클래스(ex. Date)는 인스턴스를 만들어서 쓸 클래스가 아니다! 인스턴스화를 막는 방법 추상클래스로 만든다, → 상속받아 인스턴스 만들고 부모타입으로 바꾸면 그만임. (별로

SpellChecker라는 클래스에서 Dictionary 객체가 사용되는 상황을 생각해보자. 그런데 SpellChecker에서 언어별로 사전이 따로 있을 수도 있고, 특수 어휘용 사전을 별도로 두는 상황이 있을 수 있다. 이런 식으로 자원을 명시 (new로 생성)하

이렇게 new로 String 객체 생성을 하는 경우엔 이 문장이 실행될 때 마다 새로운 객체가 만들어진다. s1과 s2는 값도 같고 기능적으로 동일하지만 s1 == s2 했을 때 false가 나온다.이를 해결하기 위해서는 값이 같다면 하나의 인스턴스를 사용하면 된다.이

equals를 재정의하지 않아도 되는 상황에서는 재정의를 안하는 게 최선이다.각 인스턴스가 싱글톤처럼 고유할 경우인스턴스의 논리적 동치성을 검사할 일이 없는 경우상위 타입에서 재정의한 equals로 충분한 경우클래스가 private or package-private이고

아이템11을 이해하기 위해서는 HashMap의 동작원리에 대해 알아야 한다. HashMap은 데이터를 담는 공간 버킷 배열(크기 16이고 나중에 필요하다면 늘림)로 만들어져 있다. 그리고 버킷에 Node 들이 LinkedList로 연결되어 있다. 그럼 HashMap에

toString을 재정의하지 않으면 Object의 기본 toString 메서드를 사용하게 된다. Object의 기본 toString은 클래스이름@16진수로\_표시한\_해시코드가 출력된다. PhoneNumber클래스의 toString은 다음과 같이 재정의 해주면 된다.7

원본 객체의 필드 값과 동일한 값을 가지는 새로운 객체를 생성해주는 메서드clone 메서드는 Cloneable이라는 인터페이스를 implements 해야 쓸 수 있다.하지만 아이러니하게도 clone 메서드는 Cloneable에 선언되어 있지 않고 Object에 선언되어

compareTo 메서드란? Comparable 인터페이스의 유일무이한 메서드 equals와 비슷하지만 단순 동치성 비교에 더해 순서까지 비교할 수 있고 제네릭하다. Comparable을 구현했다는 건 객체 간의 순서가 있다는 것이다. 순서를 고려해야 하는 값 클래스를

public 클래스에서 필드를 public으로 노출하지 말자! 위 예제 처럼 필드를 public으로 노출하면 어떤 문제가 있을까? 클라이언트 코드가 필드를 직접 사용하게 된다. 필드 이름을 바꾼다면, 클라이언트 코드를 다 고쳐야 한다. Point 객체를 만들고

⭐ 인터페이스와 추상클래스의 차이 > 추상클래스: "~이다" 인터페이스 : "~을 할 수 있다" Kebin은 사람이다. 그래서 Human이라는 추상클래스를 상속받아 Human의 자식이 된다. 당연하게도 Human은 Creature를 상속받기 때문에 Kebin은

136p. 디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 ‘삽입’될 뿐이다.동기화와 관련된 코드가 전혀 없다.Collection를 구현하는 (동기화를 제공하는) SynchronizedCollection 에서 디폴트 메서드 removeIf가 제