4장) 클래스와 인터페이스(16~18)

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

class Point{
	public double x;
    public double y;
}

>> 위와 같은 클래스는 직접 필드에 접근할 수 있으므로 캡슐화의 이점을 살릴 수 없다. 따라서 모든 필드를 private으로 바꾸고 public 접근자의 getter/setter를 추가한다.

 

정리 : public 클래스는 절대 가변 필드를 노출해선 안된다. 불변 필드라면..크게 상관없긴 하다. package-private 클래스나 private 중첩 클래스는 불변 필드를 노출하는게 나은 경우도 있다.

 

변경 가능성을 최소화하라

>> 불변 클래스를 정의할 때 다섯 가지의 규칙을 따라야 한다.

 

• 객체의 상태를 변경하는 메서드를 제공하지 않는다.
• 클래스를 확장할 수 없도록 한다.(상속막기)
• 모든 필드를 final로 선언한다.
• 모든 필드를 private으로 선언한다.
• 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

정리 : getter가 있다고 해서 setter를 무조건 만들지 말자. 클래스는 꼭 필요한 경우가 아니면 불변이어야 한다. 불변으로 만들 수 없다고 해도 변경할 수 있는 부분을 최소화하자. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다. 생성자는 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.

 

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

>> 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다.(상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있음)

기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private필드로 기존 클래스의 인스턴스를 참조하게 만들자. 상속은 반드시 하위 클래스가 상위 클래스의 '진짜' 하위 타입인 경우에만 스여야 한다.(is-a관계)

 

정리 : 상속은 강력하지만 캡슐화를 해치는 문제가 있다. 상위 클래스와 하위클래스가 is-a관계인 경우에만 상속을 사용하자. 그렇다하더라도 확장을 고려해서 설계가 되어있는지, 패키지가 같은지도 확인해야 한다. 상속의 취약점을 피하기 위해 컴포지션과 전달을 사용하자.