설계 | 객체 설계

만약 C 프로그래밍이었다면, 설정 파일과 플로우차트를 손에 들고 있는 여러분이 다음으로 해야 할 일은 함수 설계였을 것입니다. 플로우차트가 단순히 코드의 흐름을 절차에 맞춰 나타낸 것이었다면, 각 절차가 어떤 함수들에 의해 구조화되어 수행될지, 또 크게 보면 어떤 절차들을 묶어서 하나의 함수로 만들지 등을 설계하는 것이죠. 그러면 위계가 없는 선형적 흐름이었던 플로우차트가 외관상으로는 규모 있는 함수들에 의해 잘 디자인된 하나의 프로그램으로, 들여다보면 각 함수들도 그보다 작은 함수들에 의해 디자인된 구조물로서 입체감 있는 설계도가 만들어집니다.

하지만 우리가 다루는 것은 C++이고, 객체 지향 프로그래밍입니다. 잘 설계된 객체지향 프로그램은 프로그래머가 세심하게 문제를 해결하는 것이 아니라, 잘 설계한 객체들이 스스로 상호작용하여 문제를 해결해가는 느낌을 줍니다.

저희는 ServerManager라는 객체를 설계하고, manager로 하여금 config 객체와 server 객체들을 소유하도록 했습니다. Server는 URL 패턴에 따른 처리방식을 담는 Location들과 클라이언트와 통신을 담당하는 Connection들을 소유하도록 했고요. Connection은 Request와 Response를 가지도록 했습니다.

돌이켜봤을 때, 이 단계에서 더 세심하게 주의를 기울이지 못한 것이 아쉽습니다. 결과적으로 얘기하자면 7개의 객체만으로는 부족했습니다. 개발을 진행하면서 처음에 예정했던 것보다 Connection 객체의 부피가 커졌고, Connection 객체 안에 들어간 다양한 멤버 변수들을 구조화하거나 객체화하지 않고 그대로 썼습니다.

1차적인 위계에서 객체들로 프로그램을 구성하는 것만 생각하지 않고, 객체 역시 객체들에 의해 구성된다는 관점을 견지하면서 객체설계를 하면 훨씬 객체지향적이고 가독성도 높은 코드를 구현하실 수 있습니다. 멤버 메소드가 많지 않다면 구조체를 적극적으로 이용하는 것도 권장합니다. select의 인자로 사용할 fd_set들, buf와 buf 사용에 필요한 인자들 같은 경우가 적절한 예지요.

저희는 멤버 변수와 메소드를 다음 장인 클래스 명세서 작성 단계에 진행했지만, 원활한 객체 설계를 위해서 멤버 변수는 아래와 같이 현재 단계에서 설계하고 넘어가는 것이 좋습니다.