객체지향의 사실과 오해 3~4장

3장은 추상화와 타입에 대해 설명하고 객체와의 관계에 대해서 이야기한다.

4장은 앞서 이야기한 것들을 바탕으로 역할, 책임, 협력이 구체적으로 어떻게 이뤄지는지 그리고 우리가 객체지향 프로그램을 설계할 때 어떤 식으로 접근해야 하는지 좀 더 구체적으로 이야기해준다.

3장에서 먼저 복잡성을 다루기 위해 추상화가 이뤄지는 두 단계를 설명한다.

첫 번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것이다.
두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것이다.
page 77

객체지향 패러다임은 객체라는 추상화를 통해 현실의 복잡성을 극복하고 위의 두 차원을 올바르게 이해하고 적용하는 것이라고 한다.

위에서 말한 첫 번째 차원을 적용하기 위해 '개념'이라는 그릇을 사용하는데 공통점을 찾아 객체들을 묶는다. 쉽게 말하면 나 그리고 주변의 모든 사람들을 사람으로 묶는, 우리가 흔히 아는 분류를 하는 기반이 된다고 보면 될 거 같다. 이 그룹의 일원이 되면 인스턴스라고 한다.

개념을 3가지 관점으로 보는데 첫째가 심볼, 둘째가 내연, 셋째가 외연이다. 심볼은 개념을 가리키는 명칭이고 내연은 우리가 생각할 때 개념의 정의를 말하고 외연은 그러한 내연에 해당되는 객체의 집합을 이야기한다. 결론적으로 분류를 통해서 추상화를 할 수 있는데, 이건 직관적으로 받아들일 수 있을 거 같다.

다음으로 타입에 대해서 이야기 한다.

여기서 타입은 개념이랑 정의가 완전히 동일하다. 책에서는 타입의 배경을 설명하기 위해 컴퓨터 시스템에서 사용하는 타입에 대해서 간략하게 설명한다. 결국엔 타입도 두 가지 중요한 사실로 결론을 내리는데, 첫째는 어떻게 사용되느냐에 관한 것이고, 둘째는 타입에 속한 데이터를 메모리에 어떻게 표현하는지는 외부로부터 철저하게 감춰진다는 것이다. 이 특징만 봐도 우리가 앞에서 이야기한 객체랑 너무나도 닮았다. 앞에서 이야기한 내용들이 또 나오는데 객체는 행동이 무조건 우선이라는 점이다. 여기서도 객체가 어떻게 행동하냐에 따라 객체의 타입이 정해진다고 한다. 내부의 데이터 표현 방식이 다르고 처리 방식이 달라도 결과적으로는 동일한 타입의 계층에 속한다고 볼 수 있다. 다형성 이야기랑 연관이 있다. 타입에도 계층이 있는데, 일반적인 계층 특수한 계층 나눠서 표현하는데 이거는 우리가 아는 상속 관계로 보면 설명이 될 거 같다.

그럼 결국에는 타입을 왜 사용하는가?

객체는 동적으로 상태가 변하기 때문에 이러한 객체를 어떠한 정적인 상태로 추상화하기 위해서 쓰인다고 한다. 쉽게 말하면 일반화를 시키는 거 같다. 정리하자면 타입은 객체의 상태 변화라는 복잡성을 단순하게 해주는 추상화의 방법이고, 우리는 객체지향 애플리케이션을 설계할 때 객체의 동적인 모델과 정적인 타입 모델 둘 다 고려하면서 설계해야 한다. 또한 클래스는 이러한 타입을 구현하기 위한 하나의 방법일 뿐이다.

4장은 소제목 처럼 역할, 책임, 협력에 관해서 이야기하는데 책임부터 시작한다.

정의를 하나씩 정리해 가보면, 협력은 다수의 요청과 응답으로 구성되어 연쇄적인 요청과 응답의 흐름으로 구성된다. 이러한 협력을 할 수 있게 각자의 객체는 책임이 주어지는데 객체의 책임은 무엇을 알고 있는지와 무엇을 할 수 있는가 로 나뉜다고 한다. 객체의 책임을 이야기할 때는 일반적으로 외부에서 접근 가능한 공용 서비스의 관점에서 이야기한다. 책임은 객체의 외부에 제공해 줄 수 있는 정보(아는 것 )와 외부에 제공해 줄 수 있는 서비스(하는 것)의 목록이다. 책임은 객체의 공용 인터페이스를 제공한다. 주의할 점은 전에 말한 메시지 수준과 객체의 책임 수준은 같지 않다는 것이다. 책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것이다. 즉 하나의 책임이 나중에 여러 메시지로 분할되는 경우가 많다.

마지막으로 역할은 책임의 집합인데,

여러 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화 할 수 있다는 점이 기억에 남았다. 책에서 이야기해주는 예시 따라서 판사의 역할은 다른 객체(왕, 왕비)들로 바뀔 수 있다. 이렇게 구체적인 객체를 추상적인 역할로 대체함으로써 협력의 양상을 단순화한다.

뒤에서는 저번에 말한 객체의 상태가 중요한 게 아니라 협력 속에서 어떤 책임을 어떻게 나눌지가 더 중요하다는 이야기를 하고 이게 객체지향의 설계의 품질을 결정한다고 한다. 마지막으로 설계 기법 소개를 하면서 책임 주도 설계, 디자인 패턴, 테스트 주도 개발에 대해서 이야기해주는데 예전부터 TDD에 대해서 공부하고 싶었는데, 여기서 살짝 방향성을 가르쳐 준거 같아서 기뻤다.

책에서 초보자들은 개발을 주도하기 위해 어떤 테스트를 어떤 식으로 작성해야 하는지를 결정하는데 큰 어려움을 느낀다고 한다. 나도 그랬다. 테스트-주도 개발은 객체가 이미 존재한다고 가정하고 객체에게 어떤 메세지를 전송할 것인가에 관해 먼저 생각하라고 충고한다. 결국엔 테스트-주도 개발도 책임-주도 설계의 기본 개념을 따른다고 한다. 결론적으로는 테스트-주도 개발도 역할, 책임, 협력에 집중하고 객체지향의 원칙을 적용하려는 깊이 있는 고민과 노력을 통해서만 이뤄 낼 수 있다고 한다.

앞장에서부터 이야기해온 내용을 좀 더 구체적으로 풀어준 장들이었다. 지금 보고 있는 코드들을 볼 때 배운 내용을 기반으로 역할, 책임, 협력에 대해서 좀 더 생각해 보면서 작업을 해야겠다. 얼른 끝내고 TDD도 공부하고 싶다.

참고 및 출처: <객체지향의 사실과 오해 역할, 책임, 협력 관점에서 본 객체지향> (조영호 지음, 위키북스 , 2015)