'Effective Java 2nd'에 해당되는 글 9건
- [Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자. 2009/10/30
- [Effective Java] 15. 가변성을 최소화하자. (2) 2009/10/19
- [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) 2009/10/15
- [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. 2009/09/28
- [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) 2009/09/24
- [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) 2009/09/23
- [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 2009/09/17
- [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) 2009/08/26
- [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. (3) 2009/07/31
[Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.
Posted at 2009/10/30 10:14// Posted in 나만의 작업/Java
[Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.
제네릭을 사용하면 각 컬렉션에 어떤 타입의 객체를 허용할 것인지 컴파일러에게 알려주게 되며, 캐스트 코드를 컴파일러가 자동으로 만들어준다. 또한 잘못된 타입의 객체를 추가하려고 하면 컴파일 시에 알려준다.
하나 이상의 타입 매개변수(type parameter)를 선언하고 있는 클래스나 인터페이스를 제네릭 클래스, 또는 제네릭 인터페이스라고 한다.
자바 1.5를 기준으로 List 인터페이스에는 하나의 타입 매개변수로 E가 있는데, 여기서 E는 List에 저장되는 요소의 타입을 나타낸다.
각 제네릭 타입에서는 원천(raw) 타입을 정의하는데 원천 타입이란 실 타입 매개변수가 없이 사용되는 제네릭 타입의 이름을 말한다.
예를 들어, List<E>에 대한 원천 타입은 List로써, 마치 타입 선언에서 제네릭 타입 정보가 지워진
것처럼 동작하는데, 실제로는 제네릭이 추가되기 전에 인터페이스 타입 List가 했던 것과 같은 방법으로 동작한다.
앞으로 작성하는 새 코드에 List와 같은 원천 타입을 사용하면 안 되지만, List<Object>처럼 어떤
객체도 List에 추가 할 수 있는 매개변수화 타입은 사용해도 좋다. 그렇다면, 원천 타입인 List와 매개변수화 타입인
List<Object>의 차이는 무엇일까? 전자는 제네릭 타입의 검사가 생략되는 반면, 후자는 어떤 타입의 객체도
저장할 수 있다는 것을 컴파일러에게 명시적으로 알려주려는 것이다. 따라서 List<String> 타입은 List의
매개변수로 전달할 수 있지만, List<Object>의 매개변수로는 전달할 수 없다. 제네릭에는 서브 타입 규칙이
있어서 List<String>은 원천 타입인 List의 서브타입이지만 매개변수 타입인
List<Object>의 서브타입은 아니다.
그런이유로, List와 같은 원천 타입을 사용하면 타입의 안전성을 상실하게 되지만, List<Object>과 같은 매개변수 타입을 사용하면 그렇지 않다.
타입 안전의 대안으로 언바운드 와일드 카드(unbound wildcard type)을 제공하고 있다. 제네릭 타입은
사용하고 싶지만 실 타입 매개변수를 모르거나, 어떤 타입이든 관계없다면 타입 대신 물음표(?)를 사용하면 된다. 예를 들어
제네릭 타입 Set<E>의 언바운드 와일드 카드 타입은 Set<?>.
이것은 어떤 타입의 객체(Set포함)도 저장할 수 있는 가장 보편화된 매개변수화 Set 타입이다.
언바운드 와일드 카드 타입인 Set<?>과 원천 타입인 Set의 차이는 무엇일까? 와일드 카드 타입은 안전하고 원천 타입은 그렇지 않다.
원천 타입의 컬렉션에는 어떤 타입의 요소도 추가할 수 있지만, 해당 컬렉션의 타입불변성을 쉽게 무너뜨릴 수 있다.
향후에 작성하는 새 코드에는 원천 타입을 사용하지 않는다는 규칙에도 두 가지 예외가 있는데, 런타임 시에는 제네릭 타입의 정보가 없어진다는 것 때문에 가능하다.
첫번째로, 원천 타입은 클래스 리터럴(class literal)의 형태로 사용해야 한다. List.class,
String[].class, int.class는 모두 적법하지만, List<String>.class,
List<?>.class는 허용되지 않는다.
두번째로, instanceof 연산자와 관련. 제네리 타입의 정보는 런타임시에 없어지므로 언바운드 와일드 카드 타입이
아닌 다른 매개변수화 타입에 대해 instanceof 연산자를 사용할 수 없다. 원천 타입 대신 언바운드 와일드 카드 타입을
사용할 때는 instanceof 연산자의 동작에 영향을 주지 않으며, 이 경우 <>와 물음표(?)는 아무 의미가
없다. 제네릭 타입과 함께 instanceof 연산자를 사용할 때는 다음과 같이..
// Legitimate use of raw type - instanceof operator
if (o instanceof Set) { // Raw type
Set<?> m = (Set<?>) o; // Wildcard type
...
}
if (o instanceof Set) { // Raw type
Set<?> m = (Set<?>) o; // Wildcard type
...
}
o가 Set타입이라는 것이 결정되면, o의 타입을 원천타입(Set)이 아닌 언바운드 와일드 카드
타입(Set<?>)으로 캐스팅해야 한다. 그리고 이런 캐스팅은 타입을 확인하고 하는 것이므로 컴파일 시 경고 메시지가
나오지 않을 것이다.
'나만의 작업 > Java' 카테고리의 다른 글
| throw new UnsupportedOperationException() (4) | 2009/10/30 |
|---|---|
| [Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자. (0) | 2009/10/30 |
| [Effective Java] 19. 타입을 정의할 때만 인터페이스를 사용하자. (2) | 2009/10/27 |
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
[Effective Java] 15. 가변성을 최소화하자.
Posted at 2009/10/19 10:08// Posted in 나만의 작업/Java[Effective Java] 15. 가변성을 최소화하자.
불변(immutable) 클래스는 자신의 인스턴스가 갖는 값을 변경할 수 없는 클래스이다. 각 인스턴스가 갖는 모든 정보는 그것이 생성될 때 제공되며 객체로 살아있는동안 변경되지 않는다. 자바의 불변 클래스는 String, 박스화 기본형(boxed primitive) 클래스, BigInteger, BigDecimal 등등이 있다.
불변 클래스는 가변 클래스에 비해 설계와 구현 및 사용이 더 쉽다. 또한 에러 발생이 적으며 보안이나 사용 측변에서 더 안전하다.
불변 클래스 만들때 다섯 가지 규칙
1) 객체의 상태를 변경하는 그 어떤 메소드(변경자라고 하는)도 제공하지 않는다.
2) 상속을 할 수 없도록 하자. 일반적으로는 클래스를 final로 지정하면 상속을 막을 수 있다.
3) 모든 필드를 final로 지정한다. 새로 생성된 불변 클래스 인스턴스의 참조가 스레드간의 동기화를 하지 않고 하나의 스레드에서
다른 스레드로 확실하게 전달되도록 하는데도 필요하다.
4) 모든 필드를 private으로 지정한다. 필드로 참조되는 가변 객체를 클라이언트가 직접 접근하여 객체의 내용을 변경하는 것을 막기위함이다. 불변 클래스의 public final필드에서 기본형 데이터 값이나 불변 객체의 참조를 갖는 것이 기술적으로는 가능하다. 그러나 향후에 그 클래스의 내부 구조를 변경하기 어렵기 때문에 바람직하지 않다.
5) 가변 컴포넌트의 직접적인 외부 접근을 막자. 만일 가변 객체를 참조하는 필드가 클래스에 있다면, 그 클래스의 클라이언트가 해당 가변 객체의 참조를 획득할 수 없게 하자. 즉, 클라이언트가 주는 객체 참조로 그런 필드를 초기화해서는 절대 안되며, 접근자 메소드에서 객체 참조를 반환해도 안된다. 그대신 생성자와 접근자 메소드 및 readObject메소드에서 해당 객체의 방어 복사본(defensive copy)을 만들어 사용하도록 하자.
'나만의 작업 > Java' 카테고리의 다른 글
| throw new UnsupportedOperationException() (4) | 2009/10/30 |
|---|---|
| [Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자. (0) | 2009/10/30 |
| [Effective Java] 19. 타입을 정의할 때만 인터페이스를 사용하자. (2) | 2009/10/27 |
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
[Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자.
Posted at 2009/10/15 10:03// Posted in 나만의 작업/Java
[Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자.
Cloneable 인터페이스는 복제를 허용하는 객체라는 것을 알리는 목적으로 사용하는 믹스인 인터페이스(mixin interface)
아무런 method도 없는 Cloneable 인터페이스는 어디에 쓰이는 것일까?
이 인터페이스는 Object 클래스의 protected 메소드인 clone의 행동 방식을 규정한다. 만약, clone 메소드가 호출된 객체가 Cloneable 타입이라면, Object.clone 메소드는 이 객체의 모든 필드를 그대로 복사한 복제본을 리턴한다. 하지만 Cloneable 타입이 아니라면 CloneNotSupportedException을 던진다.
이 인터페이스는 Object 클래스의 protected 메소드인 clone의 행동 방식을 규정한다. 만약, clone 메소드가 호출된 객체가 Cloneable 타입이라면, Object.clone 메소드는 이 객체의 모든 필드를 그대로 복사한 복제본을 리턴한다. 하지만 Cloneable 타입이 아니라면 CloneNotSupportedException을 던진다.
java.lang.Object.clone의 명세(Specification)
this 객체의 복제본을 생성하여 리턴한다. "복제본"의 정확한 의미는 this 객체의 클래스마다 달라질 수 있다.
보통 모든 객체 x에 대하여, 다음 식
보통 모든 객체 x에 대하여, 다음 식
x.clone() != x는 true 이고, 또 다음 식
x.clone().getClass() == x.getClass()
도 true이지만 반드시 지켜야 할 사항은 아니다. 또 다음 식
x.clone().equals(x)
도 true이지만 반드시 지켜야 할 사항은 아니다. 어떤 객체를 복제할 때 보통 이 객체 클래스의 새로운 인스턴스는 반드시 생성해야 하지만, 내부 데이터 구조도 역시 복제해야 할지도 모른다. 이 메소드는 어떤 생성자도 호출하면 안 된다.
이 경우 슈퍼 클래스에서 그렇게 할 수 있는 유일한 방법은, 자신의 clone 메소드에서 super.clone을 호출하여 얻은 객체를 반환하는 것이다.
만일, 슈퍼 클래스의 clone 메소드에서 또 다시 super.clone을 호출하지 않고 생성자를 호출하여 생성된 객체를 반환한다면 잘못된 클래스(타입)의 객체가 될 것이다.
그러므로 final이 아닌 수퍼 클래스의 clone 메소드를 오버라이드 할 경우, 서브 클래스의 clone에서 반드시 super.clone을 호출하여 얻은 객체를 반환해야 한다.
일반적인 Class의 clone() method
- field가 모두 기본형 타입일 경우
public Object clone() {
try {
return super.clone();
} catch(CloneNotSupportedException e) {
throw new Error("Assertion failuer");
}
}
try {
return super.clone();
} catch(CloneNotSupportedException e) {
throw new Error("Assertion failuer");
}
}
어떤 객체가 가변 객체를 참조하는 필드를 갖고 있는 Stack클래스를 생각해 보자.
Stack 클래스의 clone 메소드가 올바르게 동작하려면, 원본 객체가 내부적으로 포함하고 있는 객체까지도 복제해주어야 한다.
그리고 그렇게 하는 가장 쉬운 방법은, elements 배열에 대해 재귀적으로 clone 메소드를 호출하는 것이다.
Cloneable을 implements 하는 클래스의 서브 클래스에서는 clone 메소드를 잘 구현해야한다.
객체를 복제하는 다른 방법을 제공하거나, 또는 복제할 수 없도록 하는 것이 좋다.
예를 들어, 불변 클래스의 객체 복제를 지원하는 것은 바람직하지 않다. 사실상 복제본이 원본과 같기 때문이다.
객체를 복제하는 좋은 방법은 복제 생성자나 복제 팩토리 메소드를 제공하는 것이다. 복제 생성자는 그냥 생성자로써, 그 생성자를 포함하는 클래스를 타입으로 하는
인자를 하나만 갖는다.
public Yum(Yum yum);
복제 팩토리는 복제 생성자와 유사한 static 팩토리 메소드로 다음과 같다.
public static Yum newInstance(Yum yum);
복제 생성자와 복제 팩토리 메소드를 사용하는 방법은 Cloneable 과 Clone을 사용하는 것에 대해 많은 장점을 갖고 있다.
'나만의 작업 > Java' 카테고리의 다른 글
| throw new UnsupportedOperationException() (4) | 2009/10/30 |
|---|---|
| [Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자. (0) | 2009/10/30 |
| [Effective Java] 19. 타입을 정의할 때만 인터페이스를 사용하자. (2) | 2009/10/27 |
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
[Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자.
Posted at 2009/09/28 13:24// Posted in 나만의 작업/Java
9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자.
Java API Object.hashCode 메소드 spec에 명시
- 애플리케이션 실행 중에 같은 객체에 대해 한 번 이상 호출되더라도 hashCode 메소드는 같은 정수를 일관성있게 반환해야 한다.
- equals(Object) 메소드 호출 결과 두 객체가 동일하다면, 두 객체 각각에 대해 hashCode 메소드를 호출했을 때 같은 정수 값이 나와야 한다.
- equals(Object) 메소드 호출 결과 두 객체가 다르다고 해서 두 객체 각각에 대해 hashCode 메소드를 호출했을 때 반드시 다른 정수 값이 나올 필요는 없다.
그러나 같지 않은 객체들에 대해 hashCode 메소드에서 서로 다른 정수 값을 반환하면, 이 메소드를 사용하는 해시 컬렉션(HashMap, HashSet, Hashtable)의
성능을 향상시킬 수 있음을 알아야 한다.
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자. (0) | 2009/10/30 |
|---|---|
| [Effective Java] 19. 타입을 정의할 때만 인터페이스를 사용하자. (2) | 2009/10/27 |
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
[Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자.
Posted at 2009/09/24 11:07// Posted in 나만의 작업/Java
8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자.
equals메소드를 오버라이드 하지 않고 써야할때
- 클래스의 각 인스턴스가 본래부터 유일한 경우
- 두 인스턴스가 논리적으로 같은지 검사하지 않아도 되는 클래스의 경우
- 수퍼 클래스에서 equals를 이미 오버라이딩 했고, 그 메소드를 그대로 사용해도 좋은 경우
- private나 패키지 전용 클래스라서 이 클래스의 equals 메소드가 절대 호출되지 않아야 할 경우
그럼 언제 해야하나?
객체 참조만으로 인스턴스의 동일 여부를 판단하는 것이 아니라, 인스턴스가 갖는 값을 비교하여 논리적으로 같은지 판단할 필요가 있는 클래스로써,
자신의 수퍼클래스에서 equals 메소드를 오버라이드하지 않았을 때다. 일반적으로 값(value) 클래스가 해당된다.
객체의 참조 여부보다 객체가 갖는 값이 논리적으로 같은지가 관심사일때, 또한 Map의 키나 Set의 요소로 객체를 저장하고 사용할 수 있게 하려면 equals 메소드의
오버라이딩이 꼭 필요하다. 같은 객체가 이미 있는지 비교하는 수단을 제공해야 하기 때문이다.
equals 메소드를 오버라이드 할 필요 없는 값 클래스는 각 값 당 최대 하나의 객체만 존재하도록 인스턴스 제어를 사용하는 클래스
열거형이 그런 부류에 속하는데 그런 클래스들의 경우는 논리적인 일치와 객체 참조 일치가 동일한 의미가 된다.
equals 메소드를 만드는 방법
1) 객체의 값을 비교할 필요 없고 참조만으로 같은 객체인지 비교 가능하다면 == 연산자를 사용하자.
2) instanceof 연산자를 사용해서 전달된 인자가 올바른 타입인지 확인하자.
대개의 경우 올바른 타입이란 호출된 equals 메소드가 정의된 클래스를 말하지만, 그 클래스가 구현하는 인터페이스도 올바른 타입이 될 수 있다.
따라서 어떤 인터페이스를 구현하는 클래스들이 여러 개 있고, 각 클래스들은 equals 계약에 맞게 equals 메소드를 오버라이딩 하고 있다면,
그 인터페이스 타입으로 각 클래스들의 객체를 비교할 수 있다. 예를 들어 Set, List, Map, Map.Entry 같은 컬렉션 인터페이스가 그런 형태이다.
3) 인자 타입을 올바른 타입으로 변환한다. 이러한 타입 변환은 instanceof 검사 후에 행하게 되므로 예외가 생기지 않고 안전하게 처리된다.
4) 클래스의 "중요한(꼭 비교해야 하는)" 필드 각각에 대해서는 인자로 전달된 객체의 필드와 현재 객체(equals 메소드가 호출된)의 필드가 모두 같은지 빠뜨리지 말고 비교한다.
5) equals 메소드가 대칭적이며 이행적이며 일관성이 있는지 확인한다.
대칭적(Symmetric) : y.equals(x) 가 true이면, x.equals(y)도 true 여야한다.
이행적(Transitive) : x.equals(y) 가 true이면, y.equals(z)가 true이면 x.equals(z)도 true
일관성(Consistent) : x.equals(y)를 여러번 호출해도 일관성있게 값을 리턴해야한다.
유의점.
equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 한다.
너무 지나치게 동일 여부를 비교하려는건 좀... 동일 파일을 참조하는 심볼릭 링크 객체들이 같은지 File 클래스의 equals 에서 비교하려고 하면 안 된다.
equals 메소드의 인자 타입을 Object 대신 다른 타입으로 바꾸지 말자.
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 19. 타입을 정의할 때만 인터페이스를 사용하자. (2) | 2009/10/27 |
|---|---|
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
| [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) | 2009/08/26 |
[Effective Java] 5. 불필요한 객체 생성을 피하자
Posted at 2009/09/23 11:33// Posted in 나만의 작업/Java
5. 불필요한 객체 생성을 피하자
불변(immutable) 객체는 항상 재사용가능하다.
String s = new String("buri");
이렇게 쓰지 말고
String s = "buri";
이렇게 쓰자는거
실행될 때마다 새로운 인스턴스를 생성하지 않고 하나의 String 인스턴스를 사용하며 같은 JVM에서 실행되는 어떤 코드에서도 동일한 문자열 리터럴(literal)을 갖도록 재사용될 것이다.
불변 클래스의 불필요한 객체 생성을 막으려면 생성자보다는 static 팩토리 메소드를 사용하는 것이 좋다.
생성자인 Boolean(String)보다는 static 팩토리 메소드인 Boolean.valueOf(String)을 사용하는 것이 더 좋다.
생성자는 호출될 때마다 새 객체를 만드는 반면, static 팩토리 메소드는 결코 그럴 필요가 없고 실제로 그렇게 하지도 않는다.
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 15. 가변성을 최소화하자. (2) | 2009/10/19 |
|---|---|
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
| [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) | 2009/08/26 |
| [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. (3) | 2009/07/31 |
-
2009/09/24 11:18 [Edit/Del] [Reply]흠... String s = "abc" 해도
결국 new String('a', 'b', 'c') 하는 거니까...
객체 생성 한다는 측면에선 별 차이가 없는...
문제가 되는 건 new String(antoherString)하는 과정에서 불필요한 메모리 복사가 발생한다는... 정도...^^-
2009/09/28 13:28 [Edit/Del]^^ 자주 등장하는 String 객체생성.
말씀해주셨다시피 String s = "abc"도 결국 내부적으론 new String 을 하는거니 성능상의 문제는 비슷하죠.
불필요한 작업을 피하자는 것~ ^^
-
-
[Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자
Posted at 2009/09/17 10:23// Posted in 나만의 작업/Java
4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자
static 메소드나 static 필드만을 모아 놓은 클래스를 만들필요가 있는 유틸리티성 클래스는 인스턴스 생성이 무의미하다.
그러나 그런 클래스라도 명시적으로 지정한 생성자가 없을때 컴파일러가 디폴트 생성자 (public 이며 매개변수가 없는)를 만들어주기 때문에 javadoc 프로그램으로 생성하는 API 문서에도 나타나기 때문에 인스턴스 생성이 가능한 클래스로 오인될 수 있다.
생성자 호출을 통한 인스턴스 생성을 방지하고 API 문서에도 나타나지 않도록 하려면?
private 생성자를 정의하면 인스턴스 생성이 불가능한 클래스를 만들 수 있다.
public class UtilityClass {
//이 클래스는 인스턴스 생성이 불가능하다라는 주석을 다는게 좋겠다.
private UtilityClass(){
throw new AssertionError(
}
}
명시적으로 정의한 생성자가 private 이므로 클래스 외부에서는 생성자 호출이 불가능하고 AssertionError는 이 생성자가 클래스 내부에서 우연히 호출될 경우를 대비.
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 11. clone 메소드는 신중하게 오버라이드 하자. (2) | 2009/10/15 |
|---|---|
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
| [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) | 2009/08/26 |
| [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. (3) | 2009/07/31 |
| [Java] 자바 코딩하다가 실수하는 부분들 (8) | 2008/03/03 |
[Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자.
Posted at 2009/08/26 11:07// Posted in 나만의 작업/Java
3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자.
싱글톤(singleton)은 정확히 하나의 인스턴스만 생성되는 클래스. 싱글톤은 본질적으로 유일한 시스템 컴포넌트를 나타낸다.
예를 들면, 윈도우 매니저나 파일 시스템 등
자바 1.5 이후 싱글톤 구현하는 가장 좋은 방법
//열거형( Enum) 싱글톤
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
복잡한 직렬화나 리플렉션 상황에서도 직렬화가 자동으로 지원되고, 인스턴스가 여러 개 생기지 않도록 확실하게 보장해준다.
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
|---|---|
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
| [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) | 2009/08/26 |
| [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. (3) | 2009/07/31 |
| [Java] 자바 코딩하다가 실수하는 부분들 (8) | 2008/03/03 |
| [java] java.util.Properties 클래스 (4) | 2007/05/10 |
-
2009/08/30 17:07 [Edit/Del] [Reply]오... enum 으로 싱글턴을... 신기하네요~
INSTANCE; 구문도 첨 본거고...
자바도 아직 공부할 게 많이 남았네요 ^^;;-
버리2009/09/01 12:17 [Edit/Del]Heart님 올만이에요~^^
저도 이번에 effective java 2nd 책 보면서 싱글턴으로 하는거 알아서..^^
메소드에 접근하고 싶다면,
Elvis.INSTACE.leaveTheBuilding();
이렇게 접근하면 된답니다.^^
-
[Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자.
Posted at 2009/07/31 11:05// Posted in 나만의 작업/Java
Static 팩토리 메소드와 생성자의 공통적인 제약은 선택 가능한 매개변수가 많아질 경우 신축성 있게 처리하지 못한다는 것인데, 흔히 나도 그러한데 텔리스코핑 생성자(telescoping constructor)패턴을 사용한다.
필수 매개변수들만 갖는 생성자, 필수 매개변수들과 선택 매개변수 하나를 갖는 생성자, 선택 매개변수 두개를 갖는 생성자 등등의 형태로 오버로딩을 통해 여러개의 생성자를 겹겹이 만드는 것이다.
public class User{
private String id;
private String pw;
private String address;
// .......15 more field
public User(String id, String pw){
this(id, pw, null);
}
public User(String id, String pw, String address){
this(id,pw,address);
}
//..... more constructor
}
이런식으로 필요한 매개변수만큼의 생성자를 만드는 방법.
매개변수가 몇개 안된다면 문제가 그리 되지 않지만 많으면 많을수록 가독성도 떨어지고 생성자를 찾아가고 또 찾아가고는 하다보면 실수를 유발할 수도 있다.
그럼 자바빈즈(JavaBeans)패턴 사용은 어떨까?
Class에 Setter method를 만들고,
User user = new User();
user.setId("id");
user.setPw("pw");
user.setAddress("address");
...//more setter method
코드는 길어지지만 인스턴스 생성이 간단하고 코드의 가독성도 좋다..
하지만, 단점은 불변(immutable) 클래스를 만들 수 있는 가능성을 배제하고 스레드(thread)에서 안정성을 유지하려면 다른 작업이 필요하다.
그럼 조금 더 우아한 방법은? Builder pattern!
public class NutritionFacts {
public class Builder {
public Builder(String name, int servingSize, int servingsPerContainer) { ... }
public Builder totalFat(int val) { ... }
public Builder saturatedFat(int val) { ... }
public Builder transFat(int val) { ... }
public Builder cholesterol(int val) { ... }
... // 15 more setters
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder) { ... }
}
}
이렇게 선언을 해놓고
NutritionFacts twoLiterDietCoke = new NutritionFacts.Builder("Diet Coke", 240, 8).sodium(1).build();
Builder의 setter method는 연속적으로 여러 번 호출될 수 있도록 빌더 자신의 객체를 반환한다.
코드 작성도 쉽고 가독성도 좋다!!!!
생성자처럼 빌더는 자신의 매개변수에 불변규칙(invariants : 매개 변수나 필드가 가질 수 있는 값의 약속된 범위나 타입 및 형태를 말한다.)을 적용할 수 있고 build method는 불변 규칙을 검사할 수 있다.
매개변수들의 값이 빌더로부터 객체에 복사된 후 빌더의 필드가 아닌 객체의 필드에 대해 불변 규칙 검사를 수행된다.
또 다른 장점은 여러개의 가변인자(varargs) 매개변수를 가질 수 있고, 유연성이 좋다.
단점은, 어떤 객체를 생성하려면 우선 그것의 빌더를 생성해야 하기 때문에 빌더 객체의 생성 비용이 많이는 아니지만 성능이 매우 중요한 상황에서는 문제가 될 수 있다.
결론은 생성자나 static 팩토리 메소드에서 많은 매개변수를 갖게 될 클래스를 설계할 때 빌더 패턴이 좋다는거~~위의 두 패턴보다 가독성도 좋고 자바빈즈 패턴보다 안전하다는 거~~
참고
Effective Java 2nd book
Effective Java Reloaded : http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-1512.pdf?
'나만의 작업 > Java' 카테고리의 다른 글
| [Effective Java] 9. equals 메소드를 오버라이드 할 땐 hashCode 메소드도 항상 오버라이드 하자. (0) | 2009/09/28 |
|---|---|
| [Effective Java] 8. equals 메소드를 오버라이딩 할 때는 보편적 계약을 따르자. (3) | 2009/09/24 |
| [Effective Java] 5. 불필요한 객체 생성을 피하자 (4) | 2009/09/23 |
| [Effective Java] 4. private 생성자를 사용해서 인스턴스 생성을 못하게 하자 (0) | 2009/09/17 |
| Eclipse Galileo에 어떤 프로젝트가 있을까? (2) | 2009/08/26 |
| [Effective Java] 3. private 생성자나 enum 타입을 사용해서 싱글톤의 특성을 유지하자. (3) | 2009/08/26 |
| [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. (3) | 2009/07/31 |
| [Java] 자바 코딩하다가 실수하는 부분들 (8) | 2008/03/03 |
| [java] java.util.Properties 클래스 (4) | 2007/05/10 |
-
-
sebah2010/08/03 15:21 [Edit/Del] [Reply]좋은 책이죠. 저도 잘 보고 있습니다. 한가지.. public class Builder -> public static class Builder 로 변경해야 겠죠? ^^
