지난번에 쓴 "잘 디자인된 코드 만들기(Delphi/VCL 기반)"를 읽고 많은 친구들이 그 안에 있는 관점을 받아들일 수 있을 것 같다고 말했지만 너무 단순하고 구체적이지 않은 것 같았습니다. 일부 친구들도 이에 대해 의구심을 표명했습니다. 일부 반대의 작은 예입니다. 그러므로 이 기사.
지난번에 제가 제시한 예는 다음과 같습니다. 어딘가에서 문자열 목록을 가져와 TListBox에 표시한다고 가정해 보겠습니다. 제가 권장하는 코드는 다음과 같습니다.
ObjectXXX := TObjectXXX.Create;
ListBox1.Items := ObjectXXX.GetStringList;
개체XXX.무료;
실제로 이 세 줄의 코드만으로 판단하면 '객체 남용'이 의심되는 것 같다는 점은 인정합니다. 예가 너무 단순하여 TObjectXXX에 GetStringList라는 공용 멤버 함수만 있는 것처럼 보일 수 있습니다. 이것이 사실이라면 이는 실제로 "객체 남용"입니다. 클래스는 객체의 추상화이며 객체는 상태와 작업(즉, 데이터와 데이터에 대한 작업)의 모음으로 구성됩니다. 그러므로 상태가 없는 객체는 객체가 아닙니다! 전용 데이터 멤버가 없는 클래스 디자인은 실패한 디자인입니다(클래스가 아니라 인터페이스임).
좋습니다. 인터페이스 코드와 함수 코드를 분리하는 방법을 설명하기 위해 자세한 예를 들어보겠습니다.
간단한 개인 주소록 관리 소프트웨어를 만들고 싶다고 가정해 보겠습니다. 분명히 전체 소프트웨어는 두 부분으로 나누어져 있습니다. 한 부분은 소위 인터페이스 부분으로, 각각 "추가" 버튼을 제공할 수 있습니다. , " "삭제", "수정", "검색") 및 편집 상자(주소록 정보 표시 및 사용자 입력 허용)는 사용자와 상호 작용하는 데 사용됩니다. 다른 부분은 기능적입니다. 소프트웨어 내의 주소록.
그래서 기능적인 부분을 추상화한 TAddrBook 클래스가 있습니다.
TAddrBook = 클래스
사적인
//일부 비공개 멤버
공공의
생성자 생성;
소멸자 파괴; 재정의;
GetCount: 정수;
FindRecord(strString): 정수;
GetRecord(nIndex:Integer): 문자열;
SetRecord(nIndex:integer; strRec:String): 부울;
AddRecord(strRec:String): 부울;
DelRecord(nIndex): 부울;
//기타 공유 멤버 함수
끝;
private 멤버를 결정할 수 없는 이유는 주로 이 클래스의 구현에 달려 있습니다.
이러한 방식으로 주소록에 대한 액세스 작업 논리를 캡슐화할 수 있습니다. 인터페이스 부분의 코드에는 이러한 액세스 논리가 포함되지 않습니다. 인터페이스 부품 코드는 다음과 같습니다.
var
Form1: TForm1;
AddrBook: TAddrBook;
nCurRec: 정수;
구현
절차 TForm1.FormCreate(Sender: TObject);
시작하다
AddrBook := TAddrBook.Create;
nCurRec := AddrBook.GetCount;
끝;
절차 TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
시작하다
AddrBook.Free;
끝;
//버튼 추가
절차 TForm1.Button1Click(Sender: TObject);
시작하다
AddrBook.AddRecord(memo1.Text)가 아닌 경우
ShowMessage("오류");
끝;
//삭제 버튼
절차 TForm1.Button2Click(Sender: TObject);
시작하다
AddrBook.DelRecord(nCurRec)가 아니면
ShowMessage("오류");
끝;
//수정 버튼
절차 TForm1.Button3Click(Sender: TObject);
시작하다
AddrBook.SetRecord(nCurRec, memo1.Text)가 아닌 경우
ShowMessage("오류");
끝;
//찾기 버튼
절차 TForm1.Button4Click(Sender: TObject);
시작하다
memo1.Text := AddrBook.GetRecord(AddrBook.FindRecord(memo1.Text));
끝;
위 인터페이스 부분의 코드에는 액세스 로직이 포함되어 있지 않습니다. 각 모듈의 코드는 간단하고 이해하기 쉽고 유지 관리가 쉽습니다. 실제로 주소록이 데이터베이스에 저장되어 있는지 텍스트 파일에 저장되어 있는지 인터페이스 코드는 알 수 없습니다. 실제로 이러한 액세스 논리는 TAddrBook 클래스의 구현에 따라 달라집니다. TAddrBook 클래스 구현은 별도의 .pas 파일에 배치될 수 있습니다. TAddrBook 클래스 구현에 대한 변경 사항은 인터페이스 부분에 영향을 미치지 않습니다. 코드를 유지 관리할 때는 변경 사항을 단일 모듈로 제한하는 것이 좋습니다.
Nicrosoft([email protected]) 2001.7.14