한의원 아저씨로부터 부탁이 있어서 번역을 하게 되었습니다. 번역이 자연스럽게 되면 좋겠는데 어떨지 모르겠네요.
저도 공부하는 거라 생각하고 시작하게 되었습니다.
읽어주셔서 감사합니다.
대부분의 델파이 프로그래머들은 그들의 직접 작업을 하지 않고도 Visual Basic[Editor는 간단히 두려움을 떨쳐버려주지요...]처럼 개발환경을 사용하지요. 델파이는 강력한 VCL 구조와 제각기 델파이 어플리케이션에 객체지향 아키텍쳐의 근본을 두고 있습니다.
이 글에서 필자는 OOP 이론을 주장하려는 것이 아니라 여러분이 프로그램의 구조를 개선하도록 도움될 만한 몇가지 간단한 제안을 할까 합니다. 나열되는 규칙들은 여러분이 작성하는 어플리케이션의 실제 형태에 적용될 수도 안될 수도 있습니다. 그냥 필자가 하는 제안하는 규칙들을 기억해주시면 고맙지요. ^^
제가 제일 강조하는 원칙은 캡슐화인데요. 우리는 프로그램의 다른 부분에 영향을 주지 않고 차후에 코드를 변경할 수 있는 유연성과 내구성이 있는 클래스를 생성하길 바라고 있습니다. 단지 좋은 OOP의 유일한 척도는 아니라도, OOP의 기초라고 할 수 있습니다. 그래서 필자가 이 글에서 정말 OOP를 지나치게 강조하는데에는 몇가지 그럴싸한 이유가 있습니다.
마지막으로, 이러한 원칙들이 델파이 프로그래머에 의해 일상 생활에서 사용된다는 사실을 강조하기 위해서, 필자는 여러가지 규칙들이 컴포넌트의 개발에 똑같이 적용되고 있더라도 주로 폼 개발에 초점을 맞출려고 합니다. 컴포넌트를 작성하는 프로그래머는 특히 OOP와 클래스를 생각해야합니다. 때때로 컴포넌트를 사용하는 프로그래머는 OOP에 관해 잊고 있는데 이 기사가 회상시켜줄 수도 있겠죠.
Part 1: 폼은 곧 클래스다
프로그래머는 오브젝트로서 폼을 취급하죠. 사실, 폼은 클래스인데 말이죠. 여기서 차이점은 동일한 폼 클래스를 바탕으로 다중 폼 오브젝트를 가질 수 있다는 것이죠. 햇갈리는 것은 델파이는 여러분이 정의한 모든 폼 클래스를 기본적으로 글로벌 오브젝트를 생성한다는 것입니다. 이는 프로그래머를 아주 초보적인 것이고 나쁜 습관으로 빠뜨릴 수 있습니다.
Rule 1: 유닛 하나에 클래스 하나!
항상 기억하세요, 클래스의 private과 protected 부분은 단지, 다른 유닛에서 클래스와 프로시저에서는 숨겨진다는 것을 말입니다. 따라서 효과적인 캡슐화를 하려 한다면, 모든 클래스에 대해 각자 다른 유닛을 사용해야 한다는 것입니다. 다른 클래스에서 클래스를 상속하는 간단한 클래스에 대해서는, 실제로 공유 유닛을 사용할 수 있지만, 단지 클래스의 수를 제한한다면: 하나의 유닛에서 20개의 클래스의 복합적인 계층을 위치시키지 말았으면 하는 것이지요. 볼랜드에서 VCL소스 코드에 대량으로 공유 유닛을 작성했을지라도... 폼에 대해 생각하자면, 델파이는 단순히 '한 클래스에 한 유닛' 원칙을 고수하고 프로젝트에 폼이 아닌 클래스를 추가할 때는 새 유닛을 생성하고 있습니다.
Rule 2: 컴포넌트 명
폼이나 유닛에 의미있는 명명을 하는 것은 아주 중요한데요. 안타깝게도, 이 두 명칭은 AboutForm과 About.pas와 같이 이 두가지에 대해 유사한 이름을 주려해도 반드시 달라야 합니다.
또한 컴포넌트에 대한 적당한 명칭 사용도 중요한데요. 가장 일반적인 표기는 btnAdd 나 editName 과 같은 컴포넌트의 역할에 따라, 클래스 타입에 대해 소문자로 머리글자를 사용하는 것입니다. 이 스타일에 따라 실제로 많은 유사한 표기방법이 있는데요. 이 방법을 가장 좋은 방법이라고 할 수는 없겠지만 개인적인 취향이 있는거 아니겠습니까!
Rule 3: 이벤트 명
이벤트 핸들링 메소드에 적당한 명칭을 부여하는 것 또한 쉽게 생각할 일은 아니죠. 예를들어, Button1Click 이라는 컴포넌트명이 있다고 하구요. 메소드명이 버튼명에서 생성되는 것이라고 추측하겠지만, 컴포넌트명에 추가된 메소드명 보다는 메소드의 기능을 잘 설명하는 명칭이 더 나는 방법이라는 생각을 하게 됩니다. 예를들자면, btnAdd 버튼의 OnClick 이벤트는 AddToList라고 할 수도 있겠지요. 이 방법은 특히 클래스의 다른 메소드로부터 이벤트 핸들러를 호출할 때 판독성이 좋아지구요. 필자가 Actions를 사용하는 것이 더 좋다고 말하고 싶지만 같은 메소드를 다양한 이벤트나 다른 컴포넌트에 추가하는데 있어 개발자에게 도움이 됩니다.
Rule 4: 폼 메소드를 사용하자
폼이 클래스라면 그 코드는 메소드로 이루어집니다. 게다가 특별한 역할도 하고 다른 메소드로서도 호출가능한 이벤트 핸들러는 사용자 메소드를 폼 클래스에 추가하는게 종종 유용할게 먹힐 때가 있습니다. 여러분은 폼의 액션을 수행하고 상태를 액세스하는 메소드를 추가할 수도 있습니다. 말하자면, 폼의 컴포넌트를 다른 폼에서 직접 조작하는 것보다는 폼의 public 메소드를 사용하는 것이 더 낫다는 것이지요.
Rule 5: 폼 생성자를 추가하자
실시간에 생성된 두번째 폼은 디폴트로 있는 거 외에 특정 생성자를 작성할 수 있습니다( 상속된 폼 TComponent 클래스). 델파이 이전 버전과 호환이 필요없다면, 필자의 제안은 초기화 파라메터와 함께 Create 메소드를 오버로드(overload)하는 것입니다. 예제 1을 봅니다.
public constructor Create (Text: string); reintroduce; overload; constructor TFormDialog.Create(Text: string); begin inherited Create (Application); Edit1.Text := Text; end;
예제 1
Rule 6: 전역 변수를 피하자
(유닛의 Interface 부분에 선언된) 전역 변수는 되도록 피하도록 합니다. 여기에 괜찮은 제안을 보여주겠습니다.
여러분들 폼에 여분의 데이터 저장공간이 필요하다면, private 필드들을 사용해 보세요. 이 경우에 각 폼 인스턴스는 데이터의 복사본을 가지게 되고, 폼 클래스의 여러 인스턴스들 중에서 공유된 데이터에 대한 유닛 변수들(유닛의 implementation 부분에 선언된)을 여러분이 사용하게 되는 겁니다.
여러분이 다른 타입의 폼들 사이에서 공유된 데이터가 필요하다면, 메인 폼이나 전역 개체에서 데이터를 놓고 데이터를 공유할수도 있고 데이터를 액세스하기 위해 메소드나 프로퍼티를 사용할 수도 있습니다.
Rule 7: TFrom1 에서는 Form1를 사용하지 말자
특정 오브젝트의 클래스의 메소드에서 특정 오브젝트를 참조하지 말아야 합니다. 바꾸어 말하면, TForm1 클래스의 메소드에서 Form1 을 참조하지 마라는 겁니다. 현재 오브젝트에 대한 참조가 필요하다면, Self 키워드를 사용하시면 됩니다. 직접 현재 오브젝트의 메소드와 데이터를 참조할 수 있기 때문에, 대부분의 경우 필요치 않다는 것을 십분 인지 하시기 바랍니다.
여러분이 이 규칙에 따르지 않는다고 봤을 때에는 폼의 여러 인스턴스를 생성할 때 문제 발생의 여지가 많습니다.
델파이 객체지향프로그래밍을 위한 20가지 규칙
