아래의 글은 pokiwiki (주 현재 pokiwiki는 폐쇠되어 있으며 mdblog로 모두 통합 예정이다)에 적었던 글인데, 위키를 정리하면서 이곳으로 옮겼습니다.

꽤 오래전에 적은 글인데, 처음 C++ 배울때의 진지함(?)과 풋풋함이 있네요 =_=

1. 재사용성

소프트웨어 개발에 있어서의 재사용성에 대한 문서입니다. 재사용이 용이한 코드라는것은 어떤 ‘박스’를 경계로 이 박스를(좀더 잘 만들어진 다른박스와) 교체하기 쉬운 코드라는 의미입니다. 이러한 박스는 크게 블랙박스와 화이트박스가 존재하며, 각각의 박스는 서로다른 특징을 가집니다.

블랙박스 모델

경계를 통과하는 값(파라미터,setter, etc..)만 알면 되므로 화이트박스 모델보다 독립적이고 모듈적이며, 박스의 관리가 쉬운 모델이나, 사용에 있어서 유연성이 부족하다는것이 치명적인 단점입니다. C++에서의 함수를 통해 이러한 블랙박스 모델을 구현할 수 있으며, 함수의 local변수보다 생명주기가 훨씬 긴 멤버변수를 가진 클래스를 통해서도 블랙박스 모델을 구현할 수 있습니다.. 클래스를 통한 블랙박스 모델의 대표적인 사용이 set and construct 기법이며, END프로젝트에서도 이러한 기법을 자주 이용합니다.

화이트박스 모델

보통 클래스의 파생을 통해서 구현되며, MFC등에서 흔히 사용하는 ‘유도하는 아키텍쳐 디자인’에서 많이 쓰입니다. 화이트박스를 잘 사용하기 위해서는 투명한 박스 내부를 잘 알아야 하기 때문에 블랙박스 모델보다 사용하기는 어려우나, 확장 가능한 아키텍쳐를 디자인 하는데 있어서는 필수입니다. 화이트박스 모델을 디자인하는데 있어서는 교체가능한 부분과 서로 약속된 부분을 잘 구분하여 디자인하는것이 중요하며, 디자인패턴은 이러한 디자인에 있어서 큰 도움이 될 수 있습니다.

2. 결합도 줄이기

실용주의 프로그래머의 결합도 줄이기와 디미터 법칙이나 EffectiveC++중에서 4장, 설계 및 선언을 읽으면서 클래스내의 멤버함수에 대한 생각들에 관한 글

멤버함수와 변수(멤버변수 혹은 인자)의 결합도

결합도 줄이기에서 중요한 것은 쓸대없는것을 넘겨서 함수가 그것과 결합되는것을 막자는 것이다. 그런데, 메쏘드들을 짜다보면, 이것들이 멤버들을 건들때는 자연히 함수의 인자값으로 넘기지 조차 않는다. 함수의 인자값을 보고 이 함수가 어떤것들과 결합되어 있는지, 어떤 의미를 갖는지를 알수 있는 함수가 좋은 함수다. 그러나 클래스들을 많이 쓰면서 이렇게 인자를 넘기는 경우가 작아졌다. - 사실 객체지향의 장점중의 하나가 이런 과도한 함수인자를 막는데 있는것이지만…

따라서, 어떤 함수가 어떤 멤버와 결합되었는지 정확하게 알릴 필요가 있다. 그것은 인자를 통해서도 알릴수 있지만, 함수를 멤버 변화에 종속시키도록 세부화 함으로써도 가능하다. 거대한 함수는 환영받지 못한다.

함수명을 동사-영향받는 객체 형식으로 짓는것도, 영향받는것을 명시하기 위해서 일것이다.

강한결합을 가진 함수가 나쁘다고 생각하지 않는다. 그러나 결합이 명확하게 명시되지 않는 함수는 나쁘다.

멤버함수와 멤버함수간의 흐름의 결합도

중요하지만 간혹 생각하지 않는게 이 함수간의 결합도이다. 거대 함수를 쪼개다 보면, 반드시 묶여야 되는 함수가 생길 수 있다. 그러나 이런 경우를 문법적으로 명시하기란 어렵다. 예를들면, 로딩되는 것들의 종류에 따라 UI의 모양이 변해야 되는것을 요구사항으로 가진 프로그램을 생각해보자. 이것을 구현하기 위해 로딩을 하는 함수와 UI의 모양을 변하는 함수 2개를 준비했고 로딩이 되면 어떻게 변해라는 변수를 바꾼다고 생각하면, 이 2개의 함수는 꼭 딸아 다녀야 한다. 그러나, 로딩을 하는 함수가 여러벌이라면 1:1이 아닌 n:1 결합이 되어서 한 함수로 묶기도 난감하고 또, 앞에서 말한 결합이 명확하지 않는 거대함수가 될 수 있다. 이런 흐름이 결합된 함수들끼리는 같은 클래스에 넣고 이것이 아주 클 경우에 다른 객체로 쪼개는것을 고려해 봐야 할 것이다. 한 클래스에는 이러한 큰 흐름이 3개 안으로 들게 설계해 보자.