effective java

A collection of 19 posts

effective java

EJ2E Item 20. 태그가 있는 클래스 대신 클래스 계층구조를 선호하라.

참조: Effective Java 2nd Edition. Prefer class hierarchies to tageed classes 위와 같은 클래스의 단점:– enum, switch 문, 태그 필드로 인해 지져분하다.– 여러 구현체를 하나의 클래스로 합쳐놓았기 때문에 가독성이 떨어진다.– 불필요한 필드까지 가지고 인스턴스를 만들어야 하기 떄문에 메모리 풋프린트가 증가한다.–

effective java

EJ2E Item 17. 상속에 대한 설계와 문서화를 제대로 하지 않을 거면 아예 상속을 허용하지 말라.

참조: Effective Java 2nd Edition Item 17: Design and document for inheritance or else prohibit it. 오버라이딩이 가능한 메소드에는 반드시 문서화를 해야 한다.  – “This implementation ~~” 즉 “이 구현체에서는..” 이라는 식으로 다음 배포 때는 다르게 구현할 수도 있다는 의미를

Composition

EJ2E Item 16. 상속보다 컴포지션을 선호하라

참조: Effective Java 2nd Edition Item 16: Favor composition over inheritence 상속– 상속은 코드 재사용을 하는 강력한 방법이지만 항상 최선의 방법은 아니다. 무분별하게 사용했다가는 연약한 소프트웨어가 된다. – 상속은 동일한 패키지 내에서 하위 클래스와 상위 클래스 구현을 같은 프로그래머가 관리할 때 안전하다. 또한

effective java

EJ2E Item 15. 변경을 최소화하라

참조: Effective Java 2nd Editio Item 15: Minimize mutability 자바에는 다양한 Immutable 클래스들이 있는데, 그 이유는.. 불변 클래스가 변하는(mutable) 클래스보다 설계하고 구현하고 사용하기 쉽기 때문이다. 불변 클래스를 만드는 다섯 가지 규칙 1. 객체의 상태를 바꾸는 메소드를 제공하지 말라. 2. 클래스를 확장할 수 없도록

effective java

EJ2E 14. public 클래스에서는 접근 메소드를 사용하지 public 필드를 사용하지 마라.

참조: Effective Java 2nd Edition. Item 14: In public classes, use accessor methods, not public fields 그런 클래스에 있는 데이터 필드에 바로 접근하면 캡슐화(Item 13) 장점을 제공하지 못하게 된다. 1. 내부를 변경하면 API까지 바뀐다.  2. 필드를 읽을 떄 어떤 보조 행위를 추가하지

effective java

EJ2E Item 13. 클래스와 멤버 접근성을 최소화 하라

참조: Effective Java 2nd Edition. Item 13: Minimize the accessibility of classes and memebers 잘 설계된 모듈은 내부 데이터 및 구체적인 정보는 외부 모듈로부터 숨긴다. 깨끗하게 구현체와 API를 분리해둔다. 그런 다음 오직 API만을 사용해서만 의사소통 하고 내부 동작은 다른 모듈이 알 필요 없게 한다.

Comparable

EJ2E Item 12. Comparable 구현을 고려하라

참조: Effecive Java 2nd Edition. Item 12: Consider implementing Comparable compareTo는 Comparable 인터페이스가 제공한다. Object의 equals와 비슷하지만, 순서 비교가 가능하며, 동일성 여부도 알 수 있고 generic하다.(어떤 의미에서 generic 하다는 거지?) 이 인터페이스를 구현한 클래스는 정렬이 가능한 것으로 인식한다. 따라서 이 클래스 타입의 배열을

Clone

EJ2E Item 11. 적절하게 clone을 재정의하라

참조: Effective Java 2nd Edition Item 11. Override clone judiciously Cloneable 인터페이스는 mixin 인터페이스(Item 18)로 복제가 가능한 객체임을 나타낼 의도로 만들었다. 하지만, 그런 목적을 제공하는데 실패했다. 이번 항목에서는 어떻게 하면 잘 동작하는 clone 메소드를 구현할지에 대한 것이다. 메소드도 없는 Cloneable 인터페이스는 무엇을

effective java

EJ2E Item 9. equals를 재정의할 땐 hashCode도 재정의하라.

참조: Effective Java 2nd Edition Item 9. Always override hashCode when you override equals equals를 재정의한 클래스는 반드시 hashCode를 재정의 해야 한다. 그렇지 않으면 Object.hashCode 일반적인 계약을 위반하게 된다. 이를 위반하면 hash 기반의 컬렉션(HashMap, HashSet, Hashtable)에서 제대로 동작하지 않을 것이다. JavaSE6

effective java

EJ2E Item 7. finalizer 사용 자제하기

참조: Effective Java 2nd Edition Item 7. Avoid finalizers Finalizer는 예측 불가능하고, 위험하며, 별로 필요없다. 자바에서 자원 반납은 try-finally 블럭에서 처리하는게 보통. finalizer의 단점은 바로 실행한다는 보장이 없다는 것이다. 객체를 참조하는 모든 레퍼런스가 없어지는 시점과 실제 finalizer를 실행하는 사이의 텀이 불규칙적이다. 따라서 호출 시기를

effective java

EJ2E Item 4. private 생성자로 객체생성 방지하기

참조: Effective Java 2nd Edition Item 4. Enforce noninstantiability with private constructor 때로는 static 메소드나 static 필드만 가지고 있는 클래스를 작성하고 싶을 떄가 있을 것이다. (ㅇㅇ. XXUtils 같은 클래스들이 그런 경우겠다.) 이때 abstract 클래스로 만드는 건 효과가 없다.– 상속 받아서 객체 생성할 수

Builder 패턴

EJ2E Item 2. 생성자에 매개변수가 너무 많을 때는 빌더를 고려하자.

참조: Effective Java 2nd Edition. Item 2: Consider a builder when faced with many constructor parameters 생성자나 static factory method에 매개 변수가 너무 많고 다양할 때 기존에는 Telescoping constructor 패턴 또는 JavaBeans 패턴을 사용왔다. telescoping constructor 패턴– 생성자에서 다른 생성자 호출하면서 비는 매개변수에는

You've successfully subscribed to Whiteship!
Could not sign up! Invalid sign up link.