프로그램이 조금만 커지면 많으면 수십개로 불어나는 Dlg......그렇다면 이 많은 Dlg들을 효과적으로 관리 할 수는 없는 것일까...?

중간에 관리 클래스를 만들어야 하는 것일까??

클래스를 만들때에는 최소한의 완벽한 인터페이스를 갖춘 클래스를 만들어야 한다. 이걸 설계하는 것 또한 만만치 않다. 먼저 만들 클래스의 상속 관계를 따저보아야 한다. 과연 이것이 상속의 부모 클래스가 될 것인가, 아니면 이것이 자식 클래스가 될 것인가...

완벽한 인터페이스를 갖춘거니까 상속관계가 생기면, 거기에 대한 가상함수의 기본적인 지원을 모두해줘야 한다. 언제 어느때 자식이 오버라이딩 할지 모른다. 또한 외부와 내부, 그리고 자식에게만 상속하는 권한 설정 또한 명백하게 해주어야 한다.

여기서 끝이라면 마음 편하다. 아직 갈길은 많다. 복사 생성자와 생성자, 소멸자에 대해서도 생각해줘야 한다. 만일 클래스 맴버 변수에서 동적으로 메모리를 할당한다면, 그것에 대한 뉴핸들러(new연산이 실패했을때 핸들링하는, 일종의 new연산자의 A/S이다-_- 참고로 전역 함수로 작업해야 한다.)의 작업도 해줘야 한다.

여기까지만 봐도 기초작업만 하는데 적어도 대여섯시간은 걸릴꺼 같다. 하지만 아직 기초가 다 끝난게 아니다. 이제 반 왔다. -_-;;; 자 그럼 원래 이야기로 돌아가서 수십가지로 불어나는 Dlg와 수십가지로 늘어나는 클래스....(Dlg 클래스 말고, 자신이 만든 클래스)

분명 비슷한 처리를 하는 루틴이 중복될 것이며, 또한 데이터를 주고 받는데에 있어서 미스도 난다. 이것이 설계도가 없을때에는 심각한 삽질이 된다.

각 클래스 간에 상속관계와, 상속에 있어서 어떤 속성들을 가지고 있는지 정확하게 설계해야 된다. 또한 애초에 기획서에서 나온 것에 바탕으로 설계도를 만들면 최대 한계점의 예상 Dlg 개수와 최대 예상 클래스 개수가 나온다.

즉 클래스는 총 7개가 들어갈것 같으며, Dlg는 아마 23개 정도 들어갈것 같다. 당연히 이 모든 것들은 거미줄 처럼 다시 서로간에 관계를 설계해야 한다.

나도 이런 설계도 안에서 코딩 해보고 싶다. ~ ~

기획의 중요성은 아무리 강조해도 지나치지 않다.

설계도의 중요성은 아무리 강조해도 지나치지 않다.

이런 설계를 아키텍트라 하고 하는 인간을 아키텍처라 한다.

물론 위에는 내 짧은 지식의 한계선에서 쓰여진 것이다. 코드리펙토링 같은건 아직 지식이 없기 때문에 클래스 안에서 어떻게 코드 리펙토링이 이루어지는지는 모르겠다.

아마도 중복되는 부분을 줄이는 것이 리펙토링이려나?