코딩 잘하고 싶어

상속은 코드를 재사용하는 강력한 수단이나 항상 최선은 아니다. 다른 패키지의 구체 클래스를 상속하는 일은 위험하다. 캡슐화를 깨뜨리는 상속 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있음 설계자가 확장을 충분히 고려하지 않으면, 하위 클래스는 상위 클래스 변화에 맞춰 수정되어야만 한다. public class InstrumentedHashSet extends HashSet { private int addCount = 0; public InstrumentedHashSet(int initCap, float loadFactor) { super(initCap, loadFactor); } @Override public boolean add(E e) { addCount++; ret..

불변 클래스 그 인스턴스의 내부 값을 수정할 수 없는 클래스 ex)String, 기본 타입 박싱 클래스들, BigInteger, BigDecimal 가변 클래스보다 설계/구현/사용이 쉬움, 오류가 더 적음 불변 클래스를 만들기 위한 규칙 객체의 상태를 변경하는 메서드를 제공하지 않음 클래스를 확장할 수 없음 (하위 클래스에서 객체의 상태를 변하게 만드는 사태를 막기 위함) 모든 필드를 final로 선언 : 여러 스레드에서 접근해도 값이 바뀌지 않음 모든 필드를 private 으로 선언 : 직접 접근해서 수정하지 못하도록 함 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 함 가변 객체를 참조하는 필드가 있다면 클라이언트가 접근하지 못하도록 해야함 접근자 메서드로 반환해서도 안됨. 생성자, 접근자, ..

인스턴스 필드들을 모아놓는 일 외에는 목적없는 클래스를 작성할 때가 있다. class Point { public double x; public double y; } 이런 클래스는 데이터 필드에 직접 접근이 가능하기 때문에 캡슐화의 이점을 제공하지 못한다. API를 수정하지 않고는 내부 표현 수정 불가, 불변식 보장 x, 스레드 안전하지 않음 → 필드를 private으로 바꾸고 getter 메서드를 제공한다. 하지만 package-private 클래스나 private 중첩 클래스라면 데이터 필드를 노출해도 하등의 문제가 없다. (getter 방식보다 깔끔) class Point { private double x; private double y; public Point(double x, double y) {..

잘 설계된 컴포넌트 → 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 잘 숨긴 컴포넌트 (구현과 API를 깔끔하게 분리) API를 통해서만 다른 컴포넌트와 소통하고 서로의 내부 동작 방식에는 참견하지 않음 정보 은닉과 캡슐화는 소프트웨어 설계의 근간이 되는 원리 정보 은닉 시스템 개발 속도를 높임 (여러 컴포넌트를 병렬로 개발할 수 있어서) 시스템 관리 비용을 낮춤. 컴포넌트를 빠르게 파악하여 디버깅이 가능하고, 다른 컴포넌트로 교체하는 부담도 적기 때문 최적화활 컴포넌트를 정한 다음, 다른 컴포넌트에 영향을 주지 않고 그것만 최적화 할 수 있어서 성능 최적화에 도움을 줌 소프트웨어 재사용성을 높임. 외부에 의존하지 않고 독자적으로 동작하는 컴포넌트는 다른 낯선 환경에서도 유용하게 쓰일 수 ..

Comparable 인터페이스의 compareTo compareTo()는 Object의 equals()와 다르게 단순 동치성 비교 뿐만 아니라 순서 비교도 가능하며 제네릭함 Comparable을 구현 → 인스턴스들에 자연적인 순서가 있음 → 손쉽게 정렬 가능 Arrays.sort(a); , 컬렉션 검색/극단값 계산/자동 정렬 비교를 활용하는 정렬된 컬렉션인 TreeSet과 TreeMap이 있고, 검색과 정렬 알고리즘을 활용하는 유틸리티 클래스인 Collections와 Arrays가 있음 규약 순서를 비교할 때 이 객체가 주어진 객체보다 작으면 음의정수(-1), 같으면 (0), 크면 양의정수(+1) 반환 비교할 수 없는 타입의 객체가 주어지면 ClassCastException 을 던짐 1) x.compar..

clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이며, 접근 제한자가 protected 이기 때문에 Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다. 이런 문제점에도 불구하고 Cloneable 방식은 널리 쓰인다. 이에 대해 알아보자. Cloneable 인터페이스 Object의 protected 메서드인 clone의 동작 방식을 결정 Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환, 그렇지 않은 클래스의 인스턴스에서 호출하면 CloneNotSupportedException 을 던짐 clone 메서드의 허술한 일반 규약 x.clone() != x 는 참이어야한다. → 복사한 객..

Object의 기본 toString 메서드가 우리가 작성한 클래스에서 적합한 문자열을 반환하는 경우는 거의 없다. 단순히 클래스 이름@16진수로_표시한_해시코드 를 반환한다. toString은 유익한 정보를 반환할 수 있도록 하위 클래스에서 재정의해야한다. (디버깅에도 용이) toString은 그 객체가 가진 주요 정보 모두를 반환하는게 좋다. /* * 전화번호의 문자열 표현을 반환합니다. * 이 문자열은 XXX-YYYY-ZZZZ 형태의 11글자로 구성됩니다. * XXX는 지역코드, YYYY는 접두사, ZZZZ는 가입자 번호입니다. */ @Override public String toString() { return String.format("%03d-%04d-%04d", areaCode, prefix, ..

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야한다. 그렇지 않으면 HashMap이나 HashSet 같은 컬렉션 원소로 사용할때 문제가 발생한다. Object 명세 규약 equals 비교에 사용되는 정보가 변경되지 않았으면, hashCode 를 호출할때 항상 같은 값을 반환해야한다. equals(Object)가 두 객체가 같다고 판단했다면, 두 객체의 hashCode 반환 값이 같아야한다. 즉, 논리적으로 같은 객체는 같은 해시코드를 반환해야한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hasCode 반환 값이 다를 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블 성능이 좋아진다. Map m = new HashMap(); m.p..

Object 클래스의 equals 메서드는 재정의하지않고 그냥두면 그 클래스는 오직 자기 자신과만 같게 된다. equals 재정의를 추천하지 않는 상황 1) 각 인스턴스가 본질적으로 고유할때 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스일때 ex)Thread 클래스 2) 인스턴스의 논리적 동치성을 검사할 일이 없을때 클라이언트가 논리적 동치성 검사 방식을 원하지 않거나 필요하지 않으면 재정의할 필요가 없다. 3) 상위 클래스에서 재정의한 equals가 하위 클래스에도 들어맞을때 ex) Set 구현체는 AbstractSet로부터, List 구현체들은 AbstractList로부터, Map 구현체들은 AbstractMap으로부터 equals를 상속받아 그대로 사용 4) 클래스가 private이거나 p..

자바 라이브러리에는 close 메서드로 직접 닫아줘야하는 자원이 많다. ex) InputStream, OutputStream, java.sql.Connection 자원 닫기는 예측할 수 없는 성능 문제로 이어질수있다. try-finally 전통적으로 자원을 닫는 수단으로 사용하였다. 예외가 발생하거나 메서드에서 반한되는 경우를 포함해서 말이다. //자원이 하나인 경우 static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } //자원이 둘 이..