클래스와 인터페이스

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

객체지향언어 및 최근에 나온 언어를 접하게 되면 반드시 접하게 되는 개념이 있다. 바로 '가시성'에 대한 개념인데, 흔히 private, protected, public 등과 같은 키워드와 함께 설명된다.

저자는 컴포넌트의 설계 수준에 대한 기준점 중 하나로 객체가 얼마나 외부와 잘 격리되었는지, 즉 캡슐화를 다음과 같은 이유로 제안한다.

• 여러 컴포넌트는 병렬로 개발할 수 있다.
• 관리 비용을 낮춘다.
• 성능 최적화가 쉽다.
• 재사용성이 높아진다.
• 개별 컴포넌트에 대한 동작을 검증할 수 있다.

이는 비단 메서드에 국한되지 않는다. 클래스 필드 또한 가시성에 유의해야 한다. 만약 필드가 public으로 외부에서 직접 접근한 경우 해당 필드에 대한 변경 및 제어에 대한 제한이 생기고, 스레드 안전하지 않게 된다.

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

필드를 외부로 노출하는 방법은 필드 자체의 가시성을 public으로 두는 방법 또는 접근자 메서드를 제공하는 방법 두 가지가 존재한다. 이 중 필드를 직접 노출하는 방법은 어떨까?

프로그래밍을 막 접한 당시의 나는 불필요한 함수 호출 비용이 발생하는 getter, 즉 접근자 메서드에 대한 신뢰가 낮았다. age라는 필드를 10000번 호출하면 함수를 10000번 호출하는 것이 아닌가? 하지만, 이는 1%는 맞고, 99%는 틀린 생각이다.

함수가 호출되는 것은 비용이 맞다. 하지만, 특별한 상황이 아닌 대부분의 상황에서 개발자가 신경 써야 하는 것은 소프트웨어의 확장성과 변경 가능성이다. 그리고 수직적 함수 호출(재귀함수)이 아닌 수평적 함수 호출은 많은 비용이 발생하지 않는다.

변경 가능성을 최소화하라

이 장은 객체지향적으로 중요한 장이라 생각된다. 객체의 상태는 온전히 그 객체가 책임이다. 이를 수정할 수 있는 여지를 외부로 노출하게 되면 그 객체의 변경은 추적하기 어렵게 만든다. 따라서 저자는 다음과 같은 규칙은 제안한다.

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

그리고 불변 객체를 추가적으로 제안한다. 불변 객체는 객체 그 자체의 변경이 없는 객체를 의미한다. 즉 한 번 생성된 상태를 프로그램이 종료되는 순간까지 유지되는 객체다.

변경이 없다는 것은 큰 제약으로 다가올 수 있다. 값이 조금만 달라도 새로운 인스턴스를 생성해야 하기 때문이다. 하지만 그 외에는 굉장히 안전장치가 되어준다.

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

객체지향을 처음 공부하게 되면 가장 흔히 접하는 개념이 상속이다. 흔히 상속을 설명하는 문법책 또는 강의에서 기능 확장에 중점을 두고 설명하는데, 앞서 저자가 설명했듯 상속은 많은 비용을 지불해야 한다.

객체지향언어에서 상속된 메서드는 overwrite가 가능하다. 즉 부모의 메서드를 자식이 필요한 형태로 변경이 가능하다. 여기서 문제가 발생하는데 만약 overwrite 한 메서드가 부모가 호출하는 메서드인 경우 예상하지 못한 동작을 하게 된다.