20201109 - java-squid/effective-java GitHub Wiki

회고

Sunny

• 적용할 수 있는 부분이 더 많은 것 같아서 재미있었다.

Han

• 아이템 6개는 버거운 느낌...
• 스터디 시간을 월요일로 옮긴 건 좋은 거 같다.

Henry

• 한 번만 읽을 책은 아니기 때문에 아이템 하나 하나 정리하기 보다는 훑어보는 느낌으로 해봤다.

David

• 무슨 질문을 해야할지 모르겠다...
• 너무 어렵거나 조금 동떨어진 내용은 마킹을 해서 물어보자.
• 내용적으로는 매우 재밌었다.

Items

[아이템 15] 클래스와 멤버의 접근 권한을 최소화하라

• 접근 제어자는 클라이언트단 코드가 아닌 라이브러리에서 사용될 때 더 큰 의미를 갖게된다.
• 클래스의 멤버 (특히 가변 객체나 배열)에 대한 접근 제어를 최소화함으로서 캡슐화와 디커플링, 그리고 스레드 안전성을 보장할 수 있다.
• 테스트 코드가 소스 코드와 동일한 패키지 구조에 속해있는 이유가 접근제어자의 동작방식에 있다.
• 모듈 시스템의 도입에 대해서는 보수적으로 지켜보자.

[아이템 16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

• 객체의 필드의 접근 제어자를 private으로 설정하고 getter와 setter를 제공하는 것이 베스트 프랙티스가 된 이유가 무엇인지에 대해 생각해보자.
• public 클래스가 아닌 경우 (특히 불변 필드인 경우)에는 public하게 열어놓아도 무관하다!

[아이템 17] 변경 가능성을 최소화하라

• 불변객체는 상태의 일관성이 보장되기 때문에 본질적으로 스레스 안전성을 보장하며 또한 예상치 못한 상태 변화로 인해 생기는 버그 및 문제점들로부터 안전하다.
• 불변객체의 단점은 많은 객체 생성이 강요된다는 점인데 성능 최적화를 위해 동반 클래스를 활용하거나 (e.g. StringBuilder) 객체 외부적으로만 불변성을 유지하고 내부적으로는 lazy 생성, 캐싱 등을 활용해 성능을 향상시키는 방법 등이 있다.
• 객체는 가능하면 불변객체로 정의하고, 불가능한 경우 가변성을 최소화하고 재사용을 금지하는 것을 지향한다 (e.g. CountDownLatch).

[아이템 18] 상속보다는 컴포지션을 사용하라

• 상속은 캡슐화를 해친다! 하위 클래스는 원천적으로 상위 클래스의 구현에 의존적일 수 밖에 없다.
• 컴포지션이라는 개념은 단순하게, 넓게 보자면 객체가 다른 객체를 포함하는 개념이다.
• 아이템에서 제안하는 객체의 확장은 정확히 말하자면 컴포지션만이 아닌 wrapper class 패턴 / Decorator 패턴을 통해 구현하는 것이다.
• 아이템의 핵심은 wrapper class 패턴을 활용하여 객체를 확장하면 캡슐화를 해치지 않으면서도 더 유연한 객체를 만들 수 있다는 것이다.

[아이템 19] 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

• 상속 관계에 있을 때 상위 클래스의 생성자가 하위 클래스 생성사보다 먼저 실행된다. 그렇기 때문에 상위 클래스의 생성자에서는 오버라이드 될 수 있는 메소드를 호출하면 안 된다.
• 객체의 확장은 가능하면 상속이 아닌 wrapper class 패턴을 활용해서 구현하자.
• 상속을 해야하는 경우에는 그에 맞춰 설계하고 문서화를 철저히 해야한다.

[아이템 20] 추상 클래스보다는 인터페이스를 우선하라

• 인터페이스와 추상 클래스의 자세한 차이는 이 문서를 참고해보면 좋을 거 같다.
• 인터페이스의 독보적인 장점은 다중상속을 통해 유연하게 객체를 확장할 수 있다는 것이다.
• 골격 구현과 같이 공유 로직을 추가하고 싶은 경우에는 추상 클래스와 같이 활용하는 것이 코드 재사용성과 확장성을 높여준다.