![규칙15
변경 가능성을 최소화하라
• 규칙76 – readObject 메서드는 방어적으로 구현하라.
• readObject – 바이트 스트림을 인자로 받는 생성자
• (Point)new ObjectInputStream(
new ByteArrayInputStream(new byte[]{0x43,0x23..})
).readObject();
• 규칙39 – 필요하다면 방어적 복사본을 만들라.
…
private Date start;
public Constructor(Date start){
this.start = new Date(start.getTime());
…
}
public Date getStartDate(){
return new Date(this.start.getTime());
}
…](https://image.slidesharecdn.com/effective0703-170703093528/85/Effective-Java-2-320.jpg)
![[자바카페] 자바 객체지향 프로그래밍 (2017)](https://cdn.slidesharecdn.com/ss_thumbnails/javacafejavaoop2017-190419123905-thumbnail.jpg?width=560&fit=bounds)
![[Dev rookie]designpattern](https://cdn.slidesharecdn.com/ss_thumbnails/devrookiedesignpattern-190501095723-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (8)
Similar to Effective Java ~ (20)
More from 영원 서 (6)
Effective Java ~
- 1. 규칙15 변경 가능성을 최소화하라 • 변경 가능성을 최소화하면 결국 변경 불가능 클래스 1. 객체 상태를 변경하는 메서지를 제공하지 않는다. • Setter를 제공하지 않는다. 2. 계승할 수 없도록 한다. • Class를 final로 정의 3. 모든 필드를 final로 선언한다. • 변경불가능한 맴버 4. 모든 필드를 privat로 선언한다. • 맴버변수에 접근 불가능 5. 변경 가능 컴포넌트에 대한 독점적 접근권을 보장한다. • readObject 메서드에서 방어적 복사본 구현
- 2. 규칙15 변경 가능성을 최소화하라 • 규칙76 – readObject 메서드는 방어적으로 구현하라. • readObject – 바이트 스트림을 인자로 받는 생성자 • (Point)new ObjectInputStream( new ByteArrayInputStream(new byte[]{0x43,0x23..}) ).readObject(); • 규칙39 – 필요하다면 방어적 복사본을 만들라. … private Date start; public Constructor(Date start){ this.start = new Date(start.getTime()); … } public Date getStartDate(){ return new Date(this.start.getTime()); } …
- 3. 규칙15 변경 가능성을 최소화하라 • P101 Complex Class • 복소수 사칙연산 결과 반환 시 새로운 인스턴스를 반환 • 함수형 접근법(functional approach) • 상태를 변환시키지 않는다. • 변경 불가능 객체는 단순하다. • 쓰레드에 안전(thread-safe)하다. • 동기화 불필요 • 자유롭게 공유가능, 심지어 public으로 공유가능
- 4. 규칙15 변경 가능성을 최소화하라 • 필요한 값에 따라 계속해서 인스턴스를 생성하면 메모리가 낭 비되지 않을까? • new Point(1,1); new Point(1,2); … 어디선가 new Point(1,1); • 정적 팩터리 메서드를 이용하여 캐싱하는 로직을 구현 • 맴버에 collection을 가지고 있는다. • clone등의 복사 관련 메소드를 override할 필요가 없다.
- 5. 규칙15 변경 가능성을 최소화하라 • 내부(맴버변수) 공유가능 • 다른 객체의 구성요소로도 훌륭하다. • 유일한 단점은 값마다 별도의 객체를 생성하는 것 • 엄청나게 큰 인스턴스의 값에 대해 하나의 비트만 달라도 새로 생성(메 모리에 로드) • 단계적 연산의 결과를 모두 변경 불가능한 클래스에 담으면? • 기본연산 제공 및 사용 • 변경가능/불가능(2가지 종류) 클래스 제공 • BigInteger/BitSet • String/StringBuilder
- 6. 규칙15 변경 가능성을 최소화하라 • 몇 가지 대안적 설계법 • 모든생성자를 privat나 package-private으로 선언하고 public 정적 팩터 리를 제공 • valueOf… valueOfPolar… • 시간이 많이 걸리는 계산결과를 non-final 맴버로 캐시 • 요약하자면, • 변경 가능한 클래스로 만들 타당한 이유가 없다면, 반드시 변경 불가능 클래스로 만들어야 한다. • 변경 불가능한 클래스로 만들 수 없다면, 변경 가능성을 최대한 제한하 라. • 특별한 이유가 없다면 모든 필드는 final로 선언하라.
- 7. 규칙16 계승(상속)하는 대신 구성하라 • 계승이 가능하다면 그에 맞는 문서를 갖춰라. • 인터페이스에 대한 구현(implements)은 제외 • 계승은 캡슐화(encapsulation) 원칙을 위반 • 상위클래스는 릴리즈(release)가 거듭 될수록 변경 가능성이 있는데, 하 위클래스는 코드 수정없이 상위클래스에 의해 망가질 수 있다. • 적절한 문서가 없으면 하위클래스도 상위클래스에 맞춰 바꿔야 한다.
- 8. 규칙16 계승(상속)하는 대신 구성하라 • P111 소스 • HashSet의 addAll 메서드는 add를 통해 구현되어 있다. • 즉 super.addAll에서 add를 3번 호출하는데 하위클래스의 add가 호출된다. • 이 클래스가 정상 동작한다는 것은 HashSet의 addAll 메서드가 add위에서 구 현되었다는 사실에 의존한다. • addAll을 삭제하면 이 문제를 교정(fix)할 수 있지만, 이런 코드는 문제발생 가 능성을 높인다. 시간이 갈수록 문제가 계속 발생한다. • 다음 릴리즈에서 상위클래스에 새로운 메서드가 추가될 경우 • 컬렉션 요소에 입력할 값이 특정 규약을 지켜야 할 경우 입력에 대한 모든 메 소드를 오버라이딩하여 규약 검사를 해야한다. • 문제는 상위 컬렉션에 입력 메소드가 추가되면 하위 클래스에서도 코드가 추 가되어야 한다.
- 9. 규칙16 계승(상속)하는 대신 구성하라 • 하위 클래스의 메소드와 동일 이름을 가지고 반환 타입이 다른 메소드가 상위클래스에 추가될 시 컴파일 에러 • 해결법! • 계승(inheritance)대신 구성(composition) • 전달 메서드(forwarding method)구현 • P114 소스 • 동일한 인터페이스를 구현, 그리고 이것이 가능해야 해결 됨 • 장식자(decorator) 패턴 • 오버라이딩 안하면 결국 전달 클래스의 메소드가 실행됨 • 근데 set에 새로운 메서드가 생성될 경우는? 컴파일에러?
- 10. 규칙16 계승(상속)하는 대신 구성하라 • 장식자(Decorator) 패턴
- 11. 규칙16 계승(상속)하는 대신 구성하라 • 포장 클래스의 단점 • 역호출(callback) 프레임워크와 함께 사용하기에는 적합하지 않다. • wrapped 객체는 wrapper객체에 대해 모른다. wrapped객체는 자기 자신을 넘기는데 이 때 wrapper객체가 제외된다. • SELF문제 • 계승(상속) 시에는 상속할 클래스에 대해 정확한 판단이 필요 • Api 구조 • 그리고 각 함수의 로직에 대한 문제
- 12. 규칙16 계승(상속)하는 대신 구성하라 • IS-A와 HAS-A Person Student Graduate Student Undergraduate Student Computer CPU GPU RAM DISK
- 13. 규칙16 계승(상속)하는 대신 구성하라 • 요약하자면, • Is-a 인가? 아니면 No • 적당한 인터페이스가 있는가? 있으면 No
- 14. 규칙17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 • 메소드를 재정의하면 무슨 일이 생기는지 정확하게 문서로 남 겨야 한다. • Public, protected로 선언된 모든 메서드, 생성자 • 재정의 가능한 메서드가 호출되는 모든 상황을 문서로 작성! • 메서드 주석문 마지막에.. “this implementation” • 무엇을 하는지가 중요하지 어떻게 하는지는 필요없음 • 신중하게 메소드를 살펴본후 protected로 제공
- 15. 규칙17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 • 유일한 검증 방법은 직업 하위 클래스를 만들어 보는 것 • 저자는 경험적으로 3개의 하위클래스만 만들어도 protected여부 결정 에 대한 테스트가 검증된다고 한다. • 그리고 protected로 결정되면 영원히 protected로 고수해야 한다고 한 다.
- 16. 규칙17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 • 계승에 대한 제약사항 • 첫 번째는 생성자는 직/간접적이든 재정의 가능 메서드를 호출해서는 안된다. • 하위클래스에 재정의된 메소드가 상위클래스 생성자에서 실행된다. 오류 혹은 두 번 실행된다. • 두 번째는 Coneable과 Serializable 인터페이스를 사용할 경우 • 하위 클래스를 구현하는 프로그래머에게 과한 책임을 줌 규칙11, 74는 해결법 • 마지막은, Serializable 인터페이스를 구현하는 계승용 클래스에 readResolve와 writeReplace메서가 있다면, 이 두 메서드는 private가 아니라 protected로 선언해야한다.
- 17. 규칙17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 • 계승을 위해 클래스를 설계하면 클래스에 상당한 제약이 가해 진다. • 계승에 맞도록 설계하고 문서화하지 않은 클래스에 대한 하위 클래스는 만들지 않는 것이다.
- 19. API개발 및 오픈소스 분석 • https://github.com/youngwonseo/WebServer-Java • Netty / MINA