잘 설계된 컴포넌트와 그렇지 못한 컴포넌트의 가장 큰 차이는 내부 데이터와 구현 정보를 외부로부터 얼마나 잘 숨겼느냐에 있습니다. 잘 설계된 컴포넌트는 모든 내부 구현을 숨기고, 구현과 API를 깔끔하게 분리합니다. 1. 정보 은닉(캡슐화)의 장점 개발 속도 증가: 여러 컴포넌트를 병렬로 개발할 수 있어 시스템 개발 속도가 빨라집니다. 관리 비용 절감: 각 컴포넌트를 더 빨리 파악할 수 있어 디버깅과 교체 비용이 낮아집니다. 성능 최적화: 특정 컴포넌트만 최적화할 수 있어 성능 향상에 도움이 됩니다....
Effective Java 3E
[아이템 14] Comparable를 구현할지 고려하라
자바에서는 Comparable과 Comparator라는 두 가지 정렬 인터페이스를 제공합니다. Comparable은 기본 정렬 기준을 구현하는 데 사용되고, Comparator는 다른 기준으로 정렬하고자 할 때 사용됩니다. 이번 포스트에서는 Comparable 인터페이스의 유일한 메서드인 compareTo에 대해 알아보겠습니다. 1. Comparable의 의미 Comparable을 구현했다는 것은 해당 클래스의 인스턴스들이 natural order를 갖는다는 것을 의미합니다. 이를 통해 Comparable을 구현한 객체들의 배열은 다음과 같이 정렬할 수 있습니다: 1 Arrays.sort(a); 2. compareTo 메서드의 규약 compareTo 메서드는 다음과 같은 규칙을 따릅니다:...
[아이템 13] clone 재정의는 주의해서 진행하라
1. clone과 Cloneable의 문제점 Cloneable 인터페이스를 구현한 클래스는 clone 메서드를 public으로 제공하며, 사용자는 이를 통해 객체의 복제가 제대로 이루어지리라 기대합니다. 하지만 clone 메서드의 일반 규약은 몇 가지 허점이 있어, 이를 주의 깊게 다루지 않으면 의도치 않은 결과를 초래할 수 있습니다. 다음은 Object 클래스의 clone 메서드에 대한 명세입니다. 이 객체의 복사본을 생성해 반환합니다. 복사의 정확한 의미는 그 객체를 구현한 클래스에 따라 달라질 수 있지만, 일반적인 의도는 다음과 같습니다. 어떤 객체 x에 대해 다음 조건을 만족해야 합니다...
[아이템 12] toString을 항상 재정의하라
1. 기본 toString의 한계 기본적으로 자바 객체는 toString 메서드를 재정의하지 않으면 클래스 이름@해시코드(16진수) 형태로 문자열을 반환합니다. 이는 객체의 고유한 정보나 상태를 파악하는 데 적합하지 않습니다. 예를 들어, 다음과 같은 코드가 있다고 가정해봅시다. 1 2 Student student = new Student("kim", 16); System.out.println(student); 위 코드를 실행하면 Student@abcd 같은 형태로 출력됩니다. 이는 객체의 중요한 정보인 name과 age에 대한 내용을 알 수 없으므로, 객체의 상태를 파악하는 데 불편함을 줍니다. 2. toString을 재정의하는 좋은 방법 1) 객체의 주요 정보를 모두 포함하라 객체의 상태를 잘 표현할 수 있는 주요 필드나 속성을 toString 메서드에 포함해야 합니다....
[아이템 11] equals를 재정의하려거든 hashCode도 재정의하라
1. 왜 hashCode도 재정의해야 할까? 자바의 HashMap, HashSet 같은 해시 기반 컬렉션은 객체의 고유한 해시값을 사용하여 저장, 검색, 비교를 수행합니다. 따라서 equals를 재정의하고도 hashCode를 재정의하지 않으면, 두 객체가 논리적으로는 같아도 해시값이 다를 수 있어 중복이 발생하거나 의도치 않게 검색에 실패할 수 있습니다. equals와 hasoCode를 재정의 하지 않으면 HashMap이나 HashSet에서 같은 원소를 사용할 때 문제가 발생합니다. Object 명세에서 정의한 hashCode 규약 일관성: equals로 비교되는 정보가 변하지 않는 한, 애플리케이션 실행 동안 여러 번 hashCode를 호출해도 일관된 값을 반환해야 합니다....