제목 : 상속(inheritance)과 연결(association) 실전 응용 예제
부제 : MDI Child 폼을 활성화하는 툴 버튼 추가 코드 리팩토링(11월 세미나 예제)

얼마 전에 올린 강좌에서 다음과 같은 제목의 글이 있었다. 이 글을 읽기 전에 이 강좌글을 반드시 먼저 읽어 보기 바란다.

"MDI Child 폼을 생성할 때마다, 메인폼의 툴바(ToolBar)에 버튼 추가"

이 강좌에서 MDI Child 폼을 생성할 때마다, 그 차일드 폼을 활성화하는, 툴 버튼을 메인폼에 표시하는 방법을 소개했었다. 또한, 지난번 강좌에서 그 방법의 여러 문제점을 나열한 바 있다. 예전 강좌에 첨부한 소스에서 중요한 문제점은, 소스 코드 중복과 유틸러티 코드가 메인폼과 차일드폼 소스 코드에 마구 흩어져있다는 것이다.

이를 해결하는 방법으로, 상속(inheritance)을 이용하는 방법과, 연결(association)을 이용하는 방법이 있다.

첨부한 압축 파일을 풀면 세개의 폴더가 생기는데, ver1 폴더에는 예전 강좌 원래 소스가 있고, ver2 폴더에는 상속을 이용하여 중복 코드를 제거한 소스가 있고, ver3 폴더는 association 을 사용하여 중복 코드를 제거한 소스가 있다.

각 버전간에 메인폼 소스 파일과 작업폼 소스 내용의 차이를 비교해보면,  ver1, ver2에 비해서 ver3의 소스가 전반적으로 월등히 간결하며, 어플 코드와 라이브러리 코드가 확연히 분리되었으며, 코드 중복도 거의 없는 구조를 유지함을 알 수 있을 것이다.

여기서는 각 버전간의 중요한 차이점만 언급하기로 하고, 상세한 사항은 소스를 보기 바란다.

먼저 ver2에서 가장 큰 차이는 차일드 폼 소스들에서 중복 코드가 완전히 사라진 것이다. 이 중복 코드들은 모두 unMIDChild.pas로 옮겨졌기 때문에, 차일드 폼 소스들은 매우 간단해 졌다

// Ver2의 Sub1Fm.pas의 내용
TSub1Frm = class(TMDIChild) // 소스 차원에서의 폼 상속
    Edit1: TEdit;
    Edit2: TEdit;
    Edit3: TEdit;
    RadioGroup1: TRadioGroup;
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
그러나 ver2의 문제점은 여전히 메인폼 소스는 장황하다는 것이다.

반면에, ver3은 차일드 폼 소스 뿐만 아니라, 메인 폼 소스 역시 지극히 간단하다.

// Ver3의 메인폼 소스 내용

type
  TMainFrm = class(TForm)
    MainMenu: TMainMenu;
    N1: TMenuItem;
    mnuSub1: TMenuItem;
    mnuSub2: TMenuItem;
    procedure mnuSub1Click(Sender: TObject);
    procedure mnuSub2Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

implementation

{$R *.dfm}

uses unMDIBar, Sub1FM, Sub2FM;

procedure TMainFrm.mnuSub1Click(Sender: TObject);
begin
  MDIBar.OpenForm(TSub1Frm);
end;

procedure TMainFrm.mnuSub2Click(Sender: TObject);
begin
  MDIBar.OpenForm(TSub2Frm);
end;

이 Ver3의 소스는 Mediator패턴과 비슷한 Manager 패턴을 소개하는 예제로, 이번 11월 세미나에서 사용할 것이다.

결론인즉, 객체지향에서 상속이 막강한 해결책 중의 하나인 것은 사실이지만, 항상 최선의 방법은 아니라는 것이다. 객체지향 고수들은, "가급적 상속을 사용하지 말고도 문제를 풀 수 있다면, 그 방식이 더 좋다"고 한다. 이말을 듣고 혹시 상속은 무조건 나쁜 것이다라는 극단적인 판단을 내리지는 말기 바란다. 한번더 강조하지만 상속은 매우 유용한 객체지향 방법 중 하나이다. 그러나 항상 더 좋은 대안이 있다는 사실만 알아두자.

어쨋든, 지나친 상속은 자칫 클래스간의 관계를 복잡하게 만들고, 복잡한 상속 구조는 후일 유지보수에 악영향을 미치기도 한다. 클래스간 관계를 복잡하게 하지 않으면서도 원하는 기능을 처리할 수 있는, association이 월등히 좋은 경우가 많다.

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