1. 폼에 중요한 정보를 보관하지 말라.

이말인즉, 중요한 정보를 폼 디자인시 속성값으로 저장하지 말라는 것이다. 다시 말해서, 속성창으로 중요한 정보를 입력하지 말라는 것이다. 폼에 놓여진 모든 콤포넌트와 폼 자체의 속성값들은 모두 리소스 형태로 최종 실행 파일에 포함된다.

문제는 아주 간단한 방법으로도 이 폼 리소스 정보를 꺼집어 낼수 있다는 것이다. 그러므로, 보안이 필요한 중요한 정보를 절대로 속성창으로 입력하지 말라. 특히 데이타베이스 커넥션에서 디비와 접속하는데 필요한 userid, password 등은 절대로 폼에 저장하면 안된다. 이런 정보들은 암호화하여 코딩으로 설정하던가, 아니면 클라이언트에 이런 로그인 정보를 전혀 실행파일에 보관할 필요가 없도록 3티어 방식으로 작성하라.

폼 리소스의 보안 취약성은 어떤 경우 심각한 문제를 야기하기도 하는데, 폼 리소스를 암호화하여 실행파일에 포함하는 방법도 있다. citadel 이란 콤포넌트가 이런 기능을 제공하니 참고하기 바란다.

2. 간단한 기능을 가진 콤포넌트를 과도하게 자주 만들지 말라.

윈도우에서 DLL Nightmare 란 단어를 들어봤을 것이다. 이는 수많은 프로그램을 윈도우에 설치하면서 발생하는 DLL들간의 간섭현상을 말한다. 마찬가지로 델파이에는 Component Hell 이란 단어가 있다. 이는 수많은 콤포넌트를 델파이 IDE에 설치하면서 발생하는 여러 부작용을 말한다.

현존 개발 툴 중에서, 스스로의 언어로 자신의 기능을 확장하는 툴을 만들고, 콤포넌트를 만드는 개발툴은 드물다. C++ 개발툴을 제외하고는 비베, 파워빌더 등 대부분이 콤포넌트나 기능 확장툴을 외부언어인 C나 C++에 의존한다. 반면 델파이는 오브젝트 파스칼로 확장툴, 콤포넌트 모두를 만들 수 있다. 사실 델파이만큼 콤포넌트 만들기 쉬운 툴도 잘 없다.(물론, 예외적이지만, 시샵은 콤포넌트 만드는 것이 델파이보다 더 쉽다).

문제는 델파이로 콤포넌트 만들기가 쉽다는 것 때문에, 많은 델 개발자들이 콤포넌트 작성을 필요없이 과다하게 남발한다는 것이다.

기존 콤포넌트에서 다소 사소한 기능을 추가할 필요가 있다면 굳이 콤포넌트화 하지 말라. 예들 들어, TEdit에 오른쪽 정렬같은 기능을 추가하기 위해서 TEdit에서 상속받은 TAlignEdit라는 콤포넌트를 만들지 말라는 것이다.

이런 경우, 래퍼나 미디이터 같은 패턴으로 굳이 콤포넌트를 만들지 않고도 해결할 수 있는 경우가 많다. 내 책인 델파이 내공쌓기 상당 수 예제는, 이런 사소한 콤포넌트 만들기 피하기 방법이라고 해도 과언이 아니다.

하여튼, 기존 콤포넌트에 사소한 기능을 추가하기 위한 방법은 새 콤포넌트 작성 말고도 몇몇 방법이 있다. 이는 다음 기회에 알아보자.

3. 이벤트 메서드를 최소화 하라.

델파이에서 폼 소스 코딩은 이벤트 메서드 코딩이라고 해도 과언이 아닐 정도로 이벤트 메서드 작성은 중요하다. 그런데 한가지 중요한 사항은, 어떤 방법을 동원해서라도 이벤트 메서드 갯수를 최소화하란 것이다.

이벤트 메서드를 최소화하란 것은 프로그램 흐름을 소스만 봐도 알수 있는 상태, 즉 Top/Down 방식으로 구현하란 것이다. 다시 말하자면 폼 소스 파일에 놓여진 함수나 메서드의 순서가 프로그램 실행 순서와 거의 일치하도록 작성하란 것이다.

이벤트 메서드가 많아져서 골치 아픈 경우 중 하나가 리포트 작성이다. 대부분의 리포트 콤포넌트들은 OnHeaderPrint, OnFooterPrint, OnRowPrint, OnBeforePrint, OnAfterPrint 같은 식으로 여러 이벤트를 작성해서 리포트를 생성하는데, 사실 하나의 리포트를 만들기 위해 이런 수많은 이벤트 메서드를 작성하면, 후일 리포트 생성 로직의 흐름을 판단할 때 무지 어렵다. 변경도 용이하지 않다.

특히 하나의 폼에서 두개의 리포트를 작성하는 경우를 가정해보라. 이런 저런 이벤트 메서드들의 중복으로 엄청난 소스 분석 혼란을 야기할 수도 있다.

따라서 리포트 생성의 경우, 이런 이벤트를 사용하지 않고도 리포트 생성 로직의 흐름을 뚜렷하게 볼 수 있는 방식으로 코딩해야 한다.

이는 폼에 수십개의 콤포넌트가 놓여서 수 많은 이벤트가 서로 의존관계를 가질때도 마찬가지다. 이벤트끼리 의존관계를 가지기 보다는 각각의 이벤트는 단독으로 존재하도록, 즉 가급적 다른 이벤트에 의존하지 않도록 작성하라.

실행시에 어떤 이벤트 메서드가 언제 호출될지 명확하게 판단한다는 것은 매우 힘들다. 나같이 오랜 동안 델파이를 사용해온 사람도 마찬가지다. 하여튼, 이벤트 메서드의 과도한 사용으로 인해 골치 아픈 현상이 발생하는 것은 델파이만이 아닌, 모든 윈도우 개발툴의 공통현상이다.

일전에 설명한 TAction의 玲逾?이벤트 메서드 줄이기에 많은 도움이 될 수 있다.

4. 도큐멘트/뷰 원칙에 의거하여 코딩하라.

이말인즉, 사용자에게 보여주는 부분에 대한 코드 부분과 데이타 처리 부분에 대한 코드를 완전히 분리하란 것이다. 대다수의 델파이 개발자들은 폼소스에 데이타 처리 로직까지 함께 넣어둔다. 예를 들어, 테이블 내용을 보여주고,  테이블을 열고, 레코드를 검색하고, 삭제하고 추가하는 모든 로직을 하나의 폼 소스 파일에 둔다.

이런 방식의 문제는 UI(그리드, 입력박스 등) 처리를 위한 로직과, 데이타 처리를 위한 로직이 여러 이벤트 메서드에 분산되고 뒤 섞여 있게 되므로, 후일 어떤 기능을 추가/수정하려면 무척 골치 아프게 된다.

따라서, 데이타 처리부와 화면 처리부에 대한 코드를 완벽히 분리할 필요가 있다. 이 방법에 대한 간단한 예제는 여기 자료실에 이미 하나 있으니 참고해 보기 바란다.

도큐멘트 뷰 방식으로 코딩함으로 해서, 3항에서 언급한 이벤트 메서드 줄이기 효과를 얻을 수도 있다.

http://cafe.daum.net/delphinegong 델파이 강좌