객체지향 시스템의 근간을 이루는 것은 메세지이지만 가장 명시적으로 드러나는 것은 클래스이기 때문에 이번 장에서는 ‘무엇이 클래스에 속하는지’, ‘어떻게 알 수 있는지’에 집중해봅시다.

클래스는 단순해야 한다

클래스를 만들 때에는 항상 어떻게 만들어야 할지 고민이 됩니다. 여기서 클래스는 단순해야 한다라는 말을 기억합시다.

수정하기 쉽도록 코드를 구성하기

디자인이란 완벽함을 추구하는 행위라기보다 코드의 수정가능성을 보존하는 기술입니다. 코드가 수정하기 쉬워야 한다고 누구든지 말할 수 있고 대부분의 사람들이 동의합니다. 하지만 ‘수정하기 쉽다’라는 표현은 애매하기 때문에 명확한 정의와 구체적인 기준이 필요합니다.

‘수정하기 쉽다’의 정의

1. 수정이 예상치 못한 부작용을 낳지 않는다.
2. 요구사항이 조금 변했을 때 연관된 코드들을 조금만 수정하면 된다.
3. 현재 코드를 다시 사용하기 쉽다.
4. 코드를 수정하는 가장 쉬운 방법은 이미 수정하기 쉬운 코드에 새로운 코드를 추가하는 것이다.

‘수정하기 쉽다’의 기준

1. 투명하다: 수정된 코드와 그 연관된 코드에서 수정의 결과가 뚜렷하게 드러나야 한다.
2. 적절하다: 모든 수정 비용은 수정 결과를 통해 얻은 이득에 비례해야 한다.
3. 사용가능하다: 예상치 못한 상황에서도 현재 코드를 사용할 수 있어야 한다.
4. 모범이 된다: 코드 자체가 나중에 수정하는 사람이 위의 특징을 이어갈 수 있도록 도와줘야한다.

하나의 책임만 지는 클래스 만들기

클래스는 최대한 작으면서도 유용한 일만 해야합니다. 다시 말해서, 하나의 책임만 있어야 합니다.

단일 책임 원칙은 왜 중요한가

한 개 이상의 책임이 있는 클래스는 재사용이 어렵습니다. 클래스에서 여러 책임들은 서로 얽혀 있을 가능성이 높습니다. 수정하고자 하는 클래스 전체가 아니라 특정 메서드만 재사용하고 싶어도 우리가 원하는 부분만 수정하기 어렵습니다. 또한 어플리케이션이 너무 많은 것을 하는 클래스에 기대고 있으면 예상치 못한 오류가 발생할 가능성도 높아집니다.

변화를 받아들일 수 있는 코드 작성하기

변화는 피할 수 없기 때문에 수정하기 쉬운 방식으로 코드를 작성하면 언젠가는 그 값어치를 합니다. 이런 코드를 작성하는 데 몇 가지 잘 알려진 기술이 있습니다.

DRY

행동은 메서드 속에 담겨 있고 메세지를 보내는 행위를 통해 실행됩니다. 하나의 책임을 지는 클래스의 행동들은 단 한 곳에만 존재합니다. “반복하지 말 것(DRY)”라는 문구는 이런 아이디어를 나타냅니다. DRY한 코드는 변화를 잘 견뎌 내는데, 클래스의 행동을 수정하기 위해 코드의 오직 한 부분만 수정하면 되기 때문입니다.

데이터가 아니라 행동에 기반한 코드를 작성

객체는 행동과 함께 데이터를 갖습니다. 이 데이터에는 두 가지 방법으로 접근할 수 있는데 인스턴스 변수를 직접 참조하거나 또는 인스턴스 변수를 감싸는 엑세서 메서드(getter, setter)를 만들어 이 메서드를 통해 접근하는 방법이 있습니다. 인스턴스 변수를 직접 참조하는 것 보다는 엑세서 메서드를 만들어 이 메서드를 통해 접근하는 벙법이 좀 더 효율적입니다.

데이터 구조 숨기기

인스턴스 변수를 직접 참조하는 것이 안 좋은 방법이라면 데이터 구조에 의존하는 방식은 더더욱 좋지 않습니다.
e.g 배열의 구조에 의존적인 코드. array[0], dict["key"]

참고

• 위키백과
• 루비로 배우는 객체지향 디자인
• GoF의 디자인 패턴