1. 비즈니스 객체 구현 비즈니스 규칙을 캡슐화하는 클래스는 진정한 객체 지향 프로그래밍의 기초입니다. 이 기사에서는 프로그래밍의 모든 측면을 다루고 델파이 프로그램을 작성하는 일반적인 방법에 대해 질문할 것입니다. 이러한 디자인 방법 뒤에 있는 기본 개념은 캡슐화입니다. 즉, 해당 속성에 대해 작동하는 메서드가 있는 명확하게 정의된 인터페이스(메서드)를 사용하여 클래스 집합을 디자인하는 것입니다. 이 개념은 전체 프로그램에 걸쳐 사용되며 데이터 저장 및 표시 방법에 큰 영향을 미칩니다. C++에 관한 Francis Glassborow의 기사를 독자들에게 소개하고 싶습니다. 언어는 다르지만 훌륭한 클래스 디자인 개념은 언어와 무관합니다. 오늘날 Delphi로 작성된 대부분의 프로그램은 객체 지향적이지 않습니다. 언어에 개체 모델이 있고 원본 또는 새 클래스를 사용한다고 해서 프로그램이 진정한 개체 지향적이라는 의미는 아닙니다. 타사 컨트롤을 창으로 드래그하면 코드 재사용이 종료되지만 창과 단위 간의 상호 의존성은 빠르게 확산됩니다. (!!!) 향후 프로그램의 기반을 변경하려는 경우(다른 데이터베이스로 전환하거나 2층 구조에서 3층 구조로 전환하는 등) 심각하게 방해를 받거나 비용이 많이 듭니다. 프로그램이 정말로 객체 지향 방식으로 작성된다면 제한적이기보다는 매우 편리할 것입니다. 물론, 그러한 프로그램을 작성하려면 개념의 개선이 필요하며, 대부분의 개발팀은 이를 하려고 하지 않거나 고려하지 않습니다. 이 기사를 통해 더 나은 프로그램을 작성하는 방법을 보여주길 바랍니다. 그 결과 전통적인 방식으로 작성된 프로그램보다 더 안정적이고, 유지 관리가 쉽고, 스타일이 일관되고, 유연하고, 재사용 가능하며, 더 잘 실행되는 시스템이 탄생했습니다. 특히 대규모 프로그램의 경우 코드가 명확하고 진정한 객체 지향적인 프로그램은 기존 방식으로 작성된 동일한 프로그램보다 유지 관리 리소스가 덜 필요합니다. 객체 지향 프로그램의 더 높은 신뢰성은 데이터와 작업이 잘 정의된 클래스에 캡슐화된다는 사실에서 비롯됩니다. 컴파일러는 강력한 유형 검사를 통해 코드의 올바른 클래스, 메서드 및 속성을 적용하며, 향후 변경 사항이 전체 프로그램에 영향을 미칠 경우 코드의 의도를 오해할 가능성이 없어야 합니다. 클래스가 올바르게 사용되면 클래스 간의 관계는 자명하며 대부분의 코드는 데이터가 유지되는 방식과 같은 세부 사항을 고려하기보다는 실제로 프로그램의 핵심에 중점을 둡니다. 코드 전체의 단순성과 일관성은 프로그램의 유지 관리성을 크게 향상시킵니다. 앞으로 살펴보겠지만 클래스 상속을 광범위하게 사용하면 생산성과 안정성이 향상되고 일관성이 향상됩니다. 이러한 일관성은 클래스의 동작, 데이터 저장 방법, 사용자 인터페이스가 데이터를 표시하는 방법을 포함하여 표시된 코드에 반영됩니다. 대부분의 기능은 기본 클래스에서 제공되기 때문에 동작을 빠르게 변경하면 프로그램을 근본적으로 변경할 수 있습니다. (예를 들어, 사용자 상호작용 인터페이스가 윈도우 중심에서 HTML 기반으로 변경되었습니다.) 이러한 기본 클래스는 프로그램과 독립적으로 설계될 수 있으므로 두 번째 유사한 프로그램이 즉시 생산성을 높일 수 있습니다. 좋은 기본 클래스 세트는 시간, 비용 및 신뢰성 측면에서 보통의 프로그램에 대해 최대 50%의 상당한 개선을 제공할 수 있습니다. 가장 먼저 강조해야 할 점은 진정한 객체 지향 개발로 전환하는 것이 사소한 문제가 아니라는 것입니다. 처음으로 지원을 경험했는지, 아니면 프로그램이 작고 긴급한 납품 기한이 없는지 확인해야 합니다. 객체 지향(OO) 솔루션은 프로그램에서 어떤 클래스를 사용해야 하고 어떤 클래스를 사용하지 말아야 하는지를 지시하는 것이 아닙니다. 회사에서 자체 시각적 컨트롤을 개발하거나 타사 시각적 컨트롤을 사용하는 경우 객체 지향 프로그램을 설계하는 첫 번째 단계는 어떤 클래스가 필요한지 고려하는 것입니다. 이는 초기 단계의 실수를 수정하는 데 비용이 많이 들기 때문에 다양한 다른 개발의 기술적 보장이 적용되는 절대적으로 기본적인 단계입니다. 클래스를 설계할 때 일반적으로 낮은 결합도와 높은 응집도를 달성하려고 노력합니다. 클래스는 가능한 한 독립적이지만 강력한 방식으로 결합될 수 있습니다. 이 목표를 달성하는 한 가지 방법은 학급을 프로그램에서 수행하는 다양한 역할에 따라 다양한 범주로 나누는 것입니다. 이러한 역할을 올바르게 선택하면 응집력 있는 클래스 집합이 만들어집니다. 클래스 역할 설계에는 일관된 기본 원칙이 있습니다. 즉, 클래스의 책임을 표현, 적용 및 데이터의 영구 저장(일반적으로 데이터베이스)으로 나누는 것입니다. 이는 3계층 데이터베이스 프로그램의 파티셔닝과 동일하지만 이 파티셔닝 개념은 단일 칩 프로그램부터 분산된 다중 계층 프로그램까지 다양한 환경에서 구현될 수 있다는 점에 유의하는 것이 중요합니다. 애플리케이션 로직을 구성하는 클래스 그룹은 사용자 작업 요청에 응답하고 데이터를 처리하는 등 가장 어려운 작업을 담당합니다. 이 계층의 일부 클래스는 실제 엔터티를 나타내며 시스템에 의해 모델링됩니다. 이러한 클래스를 "비즈니스 클래스" 또는 "문제 도메인 클래스"라고도 합니다. 이는 객체 지향 프로그램의 중요한 부분을 형성하며 다른 클래스가 어떤 방식으로든 이러한 클래스를 지원하기 때문에 모든 개발자의 초점이 됩니다. 특정 프로그램에 어떤 비즈니스 객체가 있는지 식별하는 것은 일반적으로 경험과 본능의 문제이지만, 이 프로세스에는 SSADM(1)과 같은 전통적인 기술에 비해 객체 지향의 장점이 있습니다. 분석, 설계 및 엔터티 유지 프로세스 전반에 걸쳐: 각 비즈니스 객체는 객체지향 분석(OOA), 객체지향 디자인(OOD) 및 객체지향 프로그래밍(OOP)을 통해 표현될 수 있습니다. 나중에 적합한 비즈니스 대상을 식별하기 위한 몇 가지 기술을 살펴보겠습니다. 먼저 다음과 같은 과정이 완료되었다고 가정합니다. 서로 다른 계층(프레젠테이션, 애플리케이션 및 지속성) 간의 클래스 상호 통신이 명확하게 정의되고 상호 연결됩니다. 이러한 클래스 간의 관계는 그림 1에 나와 있습니다. 그림의 화살표는 동일한 계층의 클래스가 다른 클래스의 메서드를 호출할 수 있음을 보여줍니다. 이 그림은 또한 프리젠테이션 계층(사용자 인터페이스)의 클래스가 애플리케이션 계층 또는 사용자 인터페이스의 다른 클래스를 작동할 수 있음을 보여줍니다. 애플리케이션 계층(비즈니스 객체)은 애플리케이션 계층의 클래스를 작동하고 지속성 메서드를 호출할 수 있습니다. 지속성 계층은 애플리케이션 계층 요청에만 응답합니다. 비즈니스 개체 비즈니스 개체가 구현되는 방법을 보여주기 위해 다음으로 재고, 고객 및 주문 엔터티(회사는 특정 양의 상품을 제공하고 고객은 이러한 상품을 구매함)가 포함된 단순화된 프로그램을 살펴보겠습니다. 초기 분석에서는 이러한 엔터티를 나타내기 위해 세 가지 비즈니스 개체가 필요하다는 사실을 확인했습니다. Delphi 프로그램에는 TStockItem, TCustomer 및 Torder라는 세 가지 클래스가 있습니다. 이러한 클래스의 공용 인터페이스는 목록 1에 표시되어 있습니다. 여기서는 이러한 클래스의 특성이 속성(PROperty)을 통해 외부에 노출된다는 점을 지적해야 합니다. 이는 간단하고 유익한 클래스 디자인이며 속성을 통해 외부 액세스를 제어합니다. 또한 이러한 속성은 클래스의 게시된 영역에 있어야 하며(나중에 언급할 이유 때문에) 적절한 기본값이 할당되어야 합니다. 이러한 속성 제한은 스트리밍 클래스에만 사용되지만 각 속성에 적절한 초기 값을 제공하고 코드를 보다 자체 설명적으로 만듭니다. First Class Framework 프로그램 개발의 초기 단계에서 우리는 세 가지 비즈니스 객체를 식별하고 구현했습니다. 이 세 가지 개체는 어떤 방식으로든 실제 개체를 나타내는 공통된 역할을 합니다. 따라서 우리는 그들이 실제 엔터티와 유사한 속성과 적절한 수준을 갖기를 원합니다. 우리는 각 개체에 TPDObject(문제 도메인 개체)라는 공통 기본 클래스를 제공합니다. 시간이 지남에 따라 우리는 이 클래스에 공용 메서드와 속성을 추가할 것이며 TPDObject는 계속 확장될 것입니다. TPDObject에는 특정 애플리케이션과 관련된 요소가 있어서는 안 된다는 점에 유의해야 합니다. 프로그램 독립적인 클래스로서 독립적인 단위에 배치되며 프레임워크의 기초를 형성합니다. 즉, 많은 프로그램에서 재사용할 수 있는 클래스 집합입니다. 앞으로 우리의 프레임워크는 중요한 프로그램 독립적 기능을 제공하고 특정 시스템에서 빠르게 사용될 수 있는 기본 클래스를 형성하도록 크게 확장될 것입니다. TStockItem, TCustomer 및 Torder는 TPDObject의 특정 시스템에 대한 사용자 정의 개체입니다. TMyAppPDObject는 TPDObject의 상속된 클래스입니다. 비록 구현 부분이 비어 있지만 특정 프로그램에 특정 요소를 추가하고 프로그램의 모든 문제 도메인 클래스에 영향을 미치는 경우 클래스 계층 구조가 더 적절해야 합니다. 프레임워크의 초기 코드가 목록에 나열되어 있습니다. TPDObject 클래스는 읽기 전용 속성 ID만 제공하며 해당 유형은 TobjectID입니다. 이 속성은 각 개체에 식별자를 제공합니다. 동일한 유형과 ID의 두 인스턴스를 동일한 개체로 간주합니다. 여기서 ID는 다른 표준 유형의 값에 직접 할당되지 않도록 의도적으로 자체 유형으로 선언되었습니다. TobjectID의 유형은 특별히 선택되지 않았습니다. 여기서는 특정 경우 특수 클래스일 수도 있는 정수를 선택했습니다. 클래스를 ID로 사용하는 것이 보다 순수한 객체 지향 접근 방식인 것처럼 보이지만, 생성 시 추가 로드를 피하기 위해 문제 영역의 클래스가 프로그램 실행 중에 수천 번 생성되고 해제된다는 사실을 기반으로 합니다. 객체를 해제하는 경우에는 이 작업을 수행하지 않았습니다. (순수주의자로서 TPDObject에 TobjectID를 복합 객체로 포함합니다.) 코드에는 문자열을 객체 식별 유형으로 변환하는 한 쌍의 함수와 할당이 이루어지지 않을 때 초기 값으로 사용되는 상수가 있습니다. 개체 식별이 언급되는 클래스가 많이 있습니다. 일부는 모든 비즈니스 개체가 생성될 때 프로그램 내에서 반복되지 않는 식별(GUID도 포함)을 부여해야 한다고 말합니다. 실제로 주어진 컨텍스트에서 서로 다른 개체를 구별할 수 있는 것이 정말 중요하며, 이를 단순하게 유지하면 성능과 저장 공간 이점이 분명해집니다. 사양에 대한 질문: 클래스 프레임워크를 설계할 때 일부 디자인 개념과 실습을 강화하기 위해 몇 가지 질문을 하고 독자들에게 그 뒤에 있는 기본 원칙에 대해 생각해 보라고 요청합니다. 진정한 객체 지향 디자인은 특정 클래스의 사용을 금지하지 않지만 한 가지 중요한 예외가 있다고 언급했습니다. 이 예외는 무엇입니까(답은 그림 1에 있음) ((( 목록 1 - 애플리케이션별 문제 도메인 단위(요약) )))unit ProblemDomain;interfaceuses Framework;type TMyAppPDObject = class (TPDObject) end; TMyAppPDObject ) 게시 속성 이름: 문자열; 속성 QuantityInStock: 기본 속성 TradePrice: 통화 속성 RetailPrice; TCustomer = class (TMyAppPDObject) … ; TOrder = class (TMyAppPDObject) … ;implementationend.((( 끝 목록 1 )))((( 목록 2 - 응용 프로그램 독립적인 프레임워크 단위 )))unit Framework;interfaceconst NotAssigned = 0; type TObjectID = type Integer; TPDObject = class private FID: TObjectID 공용 속성 ID: TObjectID 읽기 FID 기본값 NotAssigned; end;function StrToID (값: 문자열): TObjectID;function IDToStr (값: TObjectID): 문자열;implementation…end.((( End Listing 2 )))(1) SSADM(Structured Systems Analysis & Systems Design)이 1999년에 설립되었습니다. 1981 영국 정부의 중앙 컴퓨터 통신국(CCTA) 웹사이트: http://www.ccta.gov.uk ) 소프트웨어 분석 및 설계 표준 방법을 개발했습니다. Philip Brown은 시스템 설계 컨설턴트이자 활동적인 개발자, 발표자 및 강사입니다. 그는 기회가 있을 때마다 더 나은 애플리케이션을 제공하기 위해 강력한 OO 기술의 이점을 홍보할 것입니다. 그에게 연락할 수 있습니다. [email protected].