[Effective Java] Chapter 4: 클래스와 인터페이스

item15. 클래스와 멤버의 접근 권한을 최소화 하라

• 프로그램 요소의 접근성은 가능한 한 최소한으로 하라.
• 꼭 필요한 것만 골라 최소한의 public API를 설계하자.
• 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야한다.
• public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드를 가져서는 안 된다.
• public static final 필드가 참조하는 객체가 불변인지 확인하라.
• Link : https://jyami.tistory.com/77

[Effective Java] item 15. 클래스와 멤버의 접근 권한을 최소화하라

 

item16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

• public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다.
• 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.
• 하지만 Package-private 클래스나 private 중첩 클래스에서는 종종(불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.
• Link : https://jyami.tistory.com/78

[Effective Java] Item16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

 

item17. 변경 가능성을 최소화하라

• 클래스가 꼭 필요한 경우가 아니면 불변이어야 한다. (getter가 있다고 해서 setter를 무조껀 만들지는 말자)
• 무거운 값객체의 경우 성능때문에 어쩔수 없다면, 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하자.
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자
• 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야한다.
• Link : https://jyami.tistory.com/79

[Effective Java] item17. 변경가능성을 최소화하라

 

item18. 상속보다는 컴포지션을 사용하라

• 상속은 강력하지만 캡슐화를 깨진다.
• 상속은 상위 클래스와 하위 클래스가 순수한 is-a 관계일 때만 사용해야한다.
• is-a 관계여도 안심할 수만은 없다 : 하위 클래스의 패키지가 상위클래스와 다르고, 상위클래스가 확장을 위해 설계되지 않았다면 문제가 될 수 있다.
• 상속의 취약점을 피하려면 상속대신 컴포지션과 전달을 사용하자
• 래퍼 클래스로 구현할 적당한 인터페이스가 있으면 컴포지션을 특히 더 사용하자
• 래퍼클래스는 해위 클래스보다 견고하고 강력하다.
• Link : https://jyami.tistory.com/80

[Effective Java] Item18. 상속보다는 컴포지션을 사용하라

 

item19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았다면 상속을 금지하라

• 상속용 클래스를 설계하는건 만만치 않다.
• 클래스 내부에서 스스로를 어떻게 사용하는지 (자기 사용패턴) 모두 문서로 남겨야한다.
• 문서화 한 것은 그 클래스가 쓰이는 한 반드시 지킨다.
• 지키지 않으면 그 내부 구현 방식을 믿고 활용하던 하위클래스를 오동작하게 만들 수 있다.
• 다른 이가 효율좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공할 수도 있다.
• 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하자
• 상속을 금지하려면 클래스를 final로 선언하거나, 생성자 모두를 외부에서 접근할 수 없게 만들면 된다.
• Link : https://jyami.tistory.com/81

[Effective Java] item 19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았다면 상속을 금지하라

 

item20. 추상 클래스 보다는 인터페이스를 우선하라

• 다중 구현용 타입으로 인터페이스가 적합하다.
• 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 고려해보자
• 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다.
• '가능한 한'의 이유는, 인터페이스에 걸려잇는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.
• Link : https://jyami.tistory.com/82

[Effective Java] Item20. 추상 클래스 보다는 인터페이스를 우선하라

 

item21. 인터페이스는 구현하는 쪽을 생각해 설계하라

• 디폴트 메서드는 구현 클래스에 대해 아무것도 모른채 합의 없이 무작정 '삽입'될 뿐이다
• 범용적으로 구현하겠지만, 모든 구현체와 어울리는 것은 아니기 때문이다.
• 꼭 필요한 경우가 아니라면 디폴트메서드를 기존인터페이스에서 추가하는건 금하자.
• 새 인터페이스 만들때는 유용하다
• 인터페이스 설계는 세심한 주의를 기울이자 : 3가지 구현체 만들어보기
• Link : https://jyami.tistory.com/83

[Effective Java] item21. 인터페이스는 구현하는 쪽을 생각해 설계하라

 

item22. 인터페이스는 타입을 정의하는 용도로만 사용하라

• 인터페이스는 타입을 정의하는 용도로만 사용해야한다. 상수 공개용 수단으로 사용하지 말자ㄴ
• 상수 인터페이스는 만들지 말자
• 상수 공개를 원하면, 연관 클래스, 이넘, 인스턴스화 불가 유틸 클래스를 이용하자
• Link : https://jyami.tistory.com/84

[Effective Java] item22. 인터페이스는 타입을 정의하는 용도로만 사용하라

 

item23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

• 태그달린 클래스를 써야하는 상황은 거의 없다.
• 새로운 클래스를 작성하는데 태그 필드가 등장한다면 태그를 없애고 계층 구조로 대체하는 방법을 생각해보자.
• 기존 클래스가 태그 필드를 사용하고 있다면 계층 구조로 리팩터링 하는걸 고민하자
• Link : https://jyami.tistory.com/85

[Effective Java] item23. 태그 달린 클래스보다는 클래스 계층 구조를 활용하라하라

 

item24. 멤버 클래스는 되도록 static으로 만들어라

• 중첩 클래스에는 4가지가 있으며 각각의 쓰임이 다르다
• 멤버 클래스 : 메서드 밖에서도 사용해야하거나, 메서드 안에 정의하기 너무 길때
• 비정적 멤버 클래스 : 멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조할 때 / 그렇지 않으면 정적 멤버 클래스
• 익명 클래스 : 중첩 클래스가 한 메서드 안에서만 쓰이면서 그 인스턴스를 생성하는 지점이 단 한곳이고, 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 있을 때 / 그렇지 않으면 지역 클래스
• Link : https://jyami.tistory.com/86

[Effective Java] item24. 멤버 클래스는 되도록 static으로 만들어라용도로만 사용하라

 

item25. 톱레벨 클래스는 한 파일에 하나만 담으라

• 소스파일 하나에는 반드시 톱레벨 클래스(인터페이스)를 하나만 담자
• 이규칙만 따른다면 컴파일러가 한 클래스에 대한 정의를 여러개 만들어내는 일은 사라진다.
• 소스 파일을 어떤 순서로 컴파일하든 바이너리 파일이나 프로그램의 동작이 달라지는 일은 결코 일어나지 않는다.
• Link : https://jyami.tistory.com/87

[Effective Java] item25. 톱레벨 클래스는 한 파일에 하나만 담으라