항목 37 : 일체적 클래스의 해악, 1부 : std::string의 사례 ( 난이도 : 3 )

이번 항목은 std::string 의 스타일을 알아보고, 한가지 설계 지침을 통하여, 이 스타일을 간략하게 비평해 본다.

1 ) 일체적(monolithic) 클래스란 무엇이며, 왜 나쁜지 설명하라.

일체적(monolithic) 클래스란?

클래스가 매우 크고 무거워 더 이상 나눌 수 없는 클래스를 뜻한다. 매우 크다고 무겁다는 뜻은, 코드가 매우 방대하다는 뜻이다.

이게 왜 나쁜가?

코드의 량이 방대하면, 우선, 사용하기 힘들고, 수정하기 힘들며, 추가하기 힘들다. 이는 유지 보수가 무척이나 까다롭다는 것을 뜻한다.

예를 들자면,

1. 잠재적으로 개별적인 가능성을 한 클래스 안에서 집어 넣는다.  이는 다른 형식들과 함께 사용 할 가능성을 막아 버리는 것이므로, 사용 범위가 무척이나 좁아 진다.

2. 새로운 기능성을 위해 클래스를 확장하기가 어렵다. 그런데, 일부 사람들은 비멤버 함수로 확장 시킬 수 있다고 이야기 하지만, 허브셔터는 그런 생각은 설계상에 문제가 있다고 지적한다. 왜냐하면, 멤버 함수들은 특정한 일관성을 유지하며 사용 되어지지만, 비멤버 함수는 그러지 못하기 때문이다. 결국 프로그래머들은 비멤버 보단 멤버 함수를 선호하게 되면서, 멤버로써 확장 시키려 한다.

.. 그러므로 비멤버든 멤버든 결국 확장하기 까다로워 진다.

허브 셔터는 "클래스 하나 당 하나의 책임" 을 선호해야 하고, 가능하다면, 비멤버, 비친구 함수로 작성하는 것을 선호하는게 더 좋을 것이라고 이야기 한다.

2 ) std::basic_string의 모든 멤버 함수들을 나열 하라.

.. xstring 에 std::basic_string 이 있으니 한번 봐보기 바란다. MSVC 2005

총평

일반적으로 조각 내어서 관리 하는 것을 좋아 한다. 일전에 socket 클래스를 만들 때, 그 클래스에 모두다 넣는 바람에, 크게 낭패보았던 적이 있었따. 이 낭패는 바로 위에서 설명하는 것들과 일맥 상통한다.

허브 셔터는 각 조각을 내어, 관리하면, 더 잘 집중 할 수 잇고, 수정 또한 용이하다고, 말한다. 이번 항목은 "클래스든 함수든 각 책임은 하나씩만 부여 하는게 좋다" 라는 이야기로 요약 될 수 잇겠다.