목차
1.
  
2.
  
3.
  
4.
  
5.
  


1. 소개

 윈도우 폼 디자인을 클래스 개념으로 세분화 해서 제작하여 프로그래밍 할 수 있는 폼프로세싱 저작도구로 비교적 많은 폼을 제작하고 관리하는 시스템에 적용해 볼 것을 권해드립니다.

1) 일반적인 윈도우 폼 디자인

  일반적으로 윈도우 프로그램을 제작할 경우를 생각을 해볼까요?
  이 글을 쓰고 있는 필자 역시 개발자이지만, 보통의 경우에는 각 화면마다 개별적인 폼을 디자인을 할 것입니다.
  화면 개수가 몇 개가 되는 수십 개가 되든 아니면, 그 이상이 되든 프로그래밍 TOOL이 제공하는 디자이너를 이용해서 폼을 제작하겠죠.
  물론, 어떤 개발자는 폼 개수가 수십, 수백 개가 될 경우 앞으로 겪게 될 작업량의 공포(?)에 질려 다른 방법을 강구할지도 모릅니다.

  이 글에서 소개하는 폼프로젝트는 순전히 개발자였던 필자의 개인적인 어려움을 극복하기 위해서 고안해낸 궁여지책이었습니다.
  개인적인 궁여지책이 프로젝트를 선도하게 될 줄은 꿈에도 몰랐었지만 다행히(?) 고객사는 저의 제안에 선뜻 응해주었습니다. 그리하여 2년 동안 여러 명의 소중한 개인적인 아이디어가 합쳐져서 제가 생각하기에 꽤 쓸만한 물건이 탄생하였습니다.
  목 마른 자가 먼저 우물을 판다고 했던가요? 천 개의 폼을 프로그래밍 TOOL을 이용해서 제작할 뻔 했던 개인적인 고충은 그렇게 해결되었던 것입니다.

  이제, 필자의 개인적인 이야기는 이쯤에서 접고 10년 전, 궁여지책의 산물이었던 폼프로젝트를 소개해 드립니다.
  그러면, 폼프로젝트는 어떤 방식으로 천 개가 넘었던 수 많은 폼을 제작할 수 있었을 까요?

2) 폼프로젝트가 지향하는 폼 디자인

  프로그래밍을 하는 친구들은 늘 이런 고민을 합니다.
  작업을 단순화할 수 없을까? 개발 기간은 촉박한데 많은 시간을 투입하지 않으면서 효율성과 정확성을 높일 수 있는 방법이 있지 않을까 하는.
  물론, 그렇지 않고 편하게 생각하는 친구도 있습니다.
  그냥, 무조건 열심히 생각나는 대로 만들다 보면 끝이 보인다는……
  어느 쪽이든 프로젝트를 문제없이 끝내면 누이 좋고 매부 좋은 법이긴 합니다.
  억지로 강요하기는 싫지만 분명히 좋은 방법이 있는 법입니다.
  첫 번째 방법이 되었든 두 번째 방법이 되었든 개인적인 취향이거나 나름대로의 노하우 일 수도 있을 테니까요.
  하지만, 필자는 개발자로서 어떻게 보면 귀찮은 길을 찾았습니다.
  첫 번째 방법을 생각한 것이지요. 절대 자랑은 아닙니다. 일명 ‘귀차니즘’이 부른 궁여지책으로 출발했으니까요.

  그럼, 소개 글이 길어지면 지겨운 법이니까요 이쯤에서 마무리하고 다음 장(2. 클래스 개념)에서 궁여지책이 무엇이었는지를 설명할까 합니다.