//<델파이 5 개발자 가이드>에서
1.2 델파이란 무엇인가?
우리는 종종 "델파이가 그렇게 좋은 이유는 무엇입니까?", "다른 프로그래밍 도구보다 델파이를 선호하는 이유는 무엇입니까?" 등의 질문을 합니다. 수년에 걸쳐 우리는 이와 같은 질문에 대해 긴 답변과 짧은 답변 두 가지를 생각해냈습니다. 짧은 대답은 효율성입니다. Windows 애플리케이션을 만들려면 Delphi를 사용하는 것이 가장 쉬운 방법입니다. 물론 일부 사람들(상사와 미래 고객)은 이 답변에 만족하지 않습니다. 그러므로 우리는 델파이를 그토록 효과적으로 만드는 요소들의 조합을 보여주는 상세한 답변을 제시해야 합니다. 소프트웨어 개발 도구의 효율성을 결정하는 요소를 다음 다섯 가지로 요약합니다.
시각적 개발 환경의 성능.
컴파일러의 속도와 컴파일된 코드의 효율성.
프로그래밍 언어의 기능과 복잡성.
데이터베이스 구조의 유연성과 확장성.
디자인 및 사용 패턴을 위한 프레임워크 확장.
구성, 문서화, 제3자 지원 등과 같이 포함되어야 할 다른 많은 요소가 있지만, 이것이 우리가 Delphi를 선택한 이유를 사람들에게 설명하는 가장 정확하고 간단한 방법이라는 것을 알았습니다. 물론 위의 5가지 사항에는 주관적인 요소가 포함될 수도 있지만 핵심은 개발을 위해 특정 도구를 사용할 때 얼마나 효율적일 수 있는가입니다. 그림 1-1에서 볼 수 있듯이 도구 성능의 모든 측면이 평가되고 정량화되며(1과 5 사이) 그림 1-1의 각 축에 표시됩니다. 마지막으로 오각형을 얻을 수 있습니다. 오각형의 면적이 클수록 이 도구는 더 효율적입니다.
이 방법을 사용하여 얻은 답이 무엇인지 말할 필요는 없습니다. 일단 시도해 보면 스스로 알게 될 것입니다! 이러한 영역에서 Delphi의 성능을 자세히 살펴보고 이를 다른 Windows 개발 도구와 비교해 보겠습니다.
1.2.1 시각적 개발 환경
시각적 개발 환경은 일반적으로 편집기, 디버거 및 양식 디자이너의 세 가지 구성 요소로 나뉩니다. 대부분의 최신 RAD(신속한 애플리케이션 개발) 도구와 마찬가지로 이 세 부분은 함께 작동합니다. 양식 디자이너에서 작업할 때 Delphi는 양식에서 조작하는 컨트롤에 대한 코드를 자동으로 생성합니다. 또한 편집기에서 코드를 직접 추가하여 애플리케이션의 동작을 정의할 수도 있고, 동일한 편집기에서 중단점과 모니터링 지점을 설정하여 프로그램을 디버그할 수도 있습니다.
일반적으로 Delphi의 편집기는 다른 도구의 편집기와 유사하지만 Code Insight 기술은 입력 작업을 많이 줄여줍니다. 이 기술은 Visual Basic과 같은 형식 라이브러리가 아닌 컴파일러 정보를 기반으로 하므로 적용 범위가 더 넓습니다. Delphi의 편집기에도 좋은 구성 옵션이 많이 있지만 Visual Studio의 편집기에는 구성할 여지가 더 많다고 생각합니다. 버전 5에서 Delphi의 디버거 기능은 원격 디버깅, 프로세스 연결, DLL 및 패키지 디버깅, 자동 로컬 모니터링, CPU 창과 같은 많은 고급 기능을 통해 마침내 Visual Studio의 디버거를 따라잡았습니다. Delphi는 또한 이 상태를 명령의 데스크탑 설정으로 디버그하고 저장하는 동안 창을 무작위로 배치하고 도킹하는 것을 지원합니다. 결과적으로 Delphi의 IDE는 디버깅 기능에 대한 우수한 지원을 달성했습니다.
일부 통합 환경(예: VB 및 일부 Java 도구)에서 흔히 볼 수 있듯이 매우 완전한 디버거의 장점은 응용 프로그램이 디버깅될 때 코드를 수정하여 동작을 변경할 수 있다는 것입니다. 안타깝게도 이 기능은 네이티브 코드로 컴파일할 때 구현하기가 너무 복잡하기 때문에 Delphi에서는 지원되지 않습니다.
RAD 도구(예: Delphi, Visual Basic, C++Builder 및 PowerBilder 등)의 경우 양식 디자이너는 고유한 기능입니다. VC++ 및 BC++와 같은 보다 전통적인 개발 환경 중 일부는 대화식 편집기를 제공하지만 양식 디자이너를 개발 프로세스에 통합하지 않습니다. 그림 1-1의 효율성 차트에서 볼 수 있듯이 폼 디자이너가 없으면 개발 도구의 전반적인 효율성이 저하됩니다. 지난 몇 년 동안 Delphi와 Visual Basic은 폼 디자이너의 기능을 향상시키기 위해 치열한 경쟁을 벌였습니다. 각각의 새 버전은 이전 버전보다 더 나은 기능을 갖추고 있습니다. Delphi의 폼 디자이너를 독특하게 만드는 점은 Delphi가 진정한 객체 지향 프레임워크를 기반으로 구축되었다는 것입니다. 이렇게 하면 기본 클래스에 대한 변경 사항이 모든 파생 클래스에 전파됩니다. 여기에 관련된 핵심 기술 중 하나가 시각적 형태 상속(Visual Form Inheritance)인 VFI(Visual Form Inheritance)입니다. VFI 기술을 사용하면 현재 프로젝트나 개체 라이브러리의 다른 양식에서 동적으로 상속할 수 있습니다. 기본 양식이 변경될 때마다 파생 양식이 즉시 업데이트됩니다. 이 중요한 기능은 4장 "응용 프로그램 프레임워크 및 디자인"에서 자세히 설명됩니다.
1.2.2 컴파일러 속도 및 컴파일된 코드 효율성
빠른 컴파일러를 사용하면 소프트웨어를 단계별로 개발할 수 있으며 소스 코드를 자주 수정하고, 다시 컴파일하고, 테스트하고, 다시 수정하고, 다시 컴파일하고, 다시 테스트하는 등 좋은 개발 주기를 형성할 수 있습니다. 컴파일 속도가 매우 느린 경우 개발자는 비효율적인 루프 프로세스에 적응하기 위해 각 컴파일 전에 여러 변경 사항을 적용하여 일괄적으로 코드를 수정해야 합니다. 실행 효율성을 향상시키고, 실행 시간을 절약하며, 더 짧은 바이너리 코드를 생성한다는 점은 자명합니다.
아마도 Pascal 컴파일러의 가장 유명한 특징은 속도일 것입니다. Delphi는 이 컴파일러를 기반으로 구축되었습니다. 실제로 Windows용 가장 빠른 고급 언어 네이티브 코드 컴파일러일 수 있습니다. 느리던 C++ 컴파일러는 최근 몇 년 동안 특히 Visual C++ 및 C++Builder에 연결 및 다양한 캐싱 전략을 추가하면서 큰 발전을 이루었습니다. 그러나 그럼에도 불구하고 C++ 컴파일러는 여전히 Delphi보다 몇 배 더 느립니다.
컴파일 속도는 반드시 실행 효율성에 비례합니까? 물론 그렇지 않습니다. Delphi와 C++Builder는 동일한 컴파일러 백엔드를 공유하므로 생성된 코드는 우수한 C++ 컴파일러에서 생성된 코드와 동일합니다. 신뢰할 수 있는 최신 평가 표준에 따르면 Visual C++는 몇 가지 매우 강력한 최적화 조치 덕분에 컴파일 속도와 생성된 코드 길이 측면에서 가장 효율적인 것으로 간주되는 경우가 많습니다. 이러한 작은 이점은 일반적인 애플리케이션 개발에서는 알아차리기 어렵지만 복잡한 계산 코드를 작성하는 경우에는 효과를 발휘할 수 있습니다.
Visual Basic의 컴파일 기술은 조금 특별합니다. 개발 과정에서 VB는 통합된 방식으로 작동하며 응답성이 뛰어납니다. 이 컴파일러는 속도가 느리고 생성된 실행 코드는 Delphi 및 C++ 도구보다 훨씬 덜 효율적입니다.
Java는 또 다른 흥미로운 언어입니다. 최신 Java 기반 도구 언어인 JB uilder와 Visual J++는 컴파일 속도가 일치할 수 있다고 주장합니다.
델파이와 비슷하지만, 자바가 통합언어이기 때문에 생성된 코드의 실행 효율성이 만족스럽지 못하다. Jave는 꾸준히 발전하고 있지만 대부분의 상황에서 실행 속도는 여전히 Delphi와 C++에 크게 뒤떨어집니다.
1.2.3 프로그래밍 언어의 기능과 복잡성
언어의 기능과 복잡성은 보는 사람의 눈에 달려 있으며 많은 논쟁의 대상입니다. 어떤 사람에게는 단순한 것이 그 사람에게는 어려울 수도 있고, 어떤 사람에게는 제한된 기능이 다른 사람에게는 완벽할 수도 있습니다. 따라서 다음 사항은 저자의 개인적인 경험과 이해에 근거한 것입니다.
어셈블리는 근본적으로 가장 강력한 언어입니다. 당신은 그것으로 거의 모든 것을 할 수 있습니다. 그러나 가장 간단한 어셈블리 애플리케이션을 개발하는 것은 매우 어려우며 아무 결과도 나오지 않을 수 있습니다. 그뿐만 아니라 그룹 개발 환경에서 어셈블리 코드 조각을 일정 기간 동안 유지하는 것이 때로는 불가능할 때도 있습니다. 코드가 한 사람에게서 다음 사람으로, 다음 사람에게 전달되면서 디자인 아이디어와 의도는 점점 더 불분명해지며 마침내 코드는 천국에서 내려온 책처럼 보입니다. 결과적으로 어셈블리는 강력하지만 거의 모든 개발자에게 너무 복잡하기 때문에 우리는 어셈블리를 매우 낮게 평가합니다.
C++는 또 다른 매우 강력한 언어입니다. 잠재적인 기능(예: 전처리기 매크로, 템플릿, 연산자 로딩 등)의 도움으로 C++를 사용하여 거의 자신만의 언어를 디자인할 수 있습니다. 풍부한 기능 옵션을 적절하게 사용하면 간결하고 직관적이며 유지 관리가 쉬운 코드를 개발할 수 있습니다. 그러나 문제는 많은 개발자가 이러한 기능을 남용하여 쉽게 큰 오류로 이어질 수 있다는 것입니다. 사실, 좋은 C++ 코드를 작성하는 것보다 나쁜 C++ 코드를 작성하는 것이 더 쉽습니다. 왜냐하면 언어 자체는 좋은 디자인의 방향으로 나아가지 않을 것이기 때문입니다. 그것은 개발자에게 달려 있습니다.
오브젝트 파스칼과 Java는 복잡성과 기능의 균형을 매우 잘 파악하고 있기 때문에 우리와 매우 유사하다고 느낍니다. 그들은 모두 개발자의 논리적 설계를 향상시키기 위해 사용 가능한 기능을 제한하는 접근 방식을 취합니다. 예를 들어, 둘 다 완전한 객체 지향이지만 쉽게 남용되는 다중 상속 개념을 피하고 대신 다중 인터페이스의 기능을 수행하는 단일 클래스를 구현합니다. 아름답지만 위험한 작업자 로딩도 지원하지 않습니다. 두 가지 모두 예외 처리, 런타임 유형 정보(RT TI) 및 자체 관리형 문자열 수명 메모리와 같은 몇 가지 강력한 기능을 갖추고 있습니다. 동시에 두 언어 모두 전담 편집위원회에서 작성하는 것이 아니라 해당 언어에 대한 공통된 이해를 공유하는 단일 조직 내 개인 또는 그룹에서 작성됩니다.
Visual Basic은 원래 초보자가 더 쉽게 시작하고 더 빠르게 진행할 수 있도록 설계되었습니다(따라서 이름이 붙여졌습니다). 그러나 언어로서 VB는 지속적으로 장점을 배우고 단점을 보완해야 하므로 최근 몇 년간 점점 더 복잡해지고 있습니다. 개발자로부터 이러한 세부 정보를 숨기기 위해 VB는 복잡한 프로젝트를 생성하기 위한 일부 마법사를 여전히 유지합니다.
1.2.4 데이터베이스 구조의 유연성과 확장성
Borland에는 데이터베이스 체계가 없기 때문에 Delphi는 모든 도구 중 가장 유연한 데이터베이스 구조로 간주되는 것을 유지합니다. BDE는 로컬, 클라이언트/서버 및 ODBC 데이터베이스 플랫폼을 기반으로 하는 대부분의 응용 프로그램에 매우 강력합니다. 이것이 만족스럽지 않다면 새로운 기본 ADO 구성 요소 대신 BDE 사용을 피할 수 있습니다. ADO가 설치되어 있지 않은 경우 자체 데이터 액세스 클래스를 만들거나 타사 데이터 액세스 솔루션을 구입할 수 있습니다. 또한 MIDAS를 사용하면 데이터 소스에 대한 다계층 액세스를 더 쉽게 구현할 수 있습니다. Microsoft 도구(ODBC, OLE DB 또는 기타)는 논리적으로 Microsoft 자체 데이터베이스 및 데이터 액세스 솔루션을 지원하는 경향이 있습니다.
1.2.5 디자인 및 사용 패턴에 대한 프레임워크 확장
이는 다른 소프트웨어 설계 도구에서 종종 간과되는 중요한 기능입니다. VCL은 델파이의 가장 중요한 구성 요소입니다. 디자인 타임에 구성 요소를 조작하고, 구성 요소를 만들고, OO(객체 지향) 기술을 사용하여 다른 구성 요소의 동작을 상속하는 능력은 Delphi의 효율성을 결정하는 핵심 요소입니다. 대부분의 경우 VCL 구성 요소는 고정된 OO 설계 접근 방식을 사용하여 작성됩니다. 이에 비해 다른 구성 요소 기반 프레임워크는 너무 경직되거나 복잡한 경우가 많습니다. 예를 들어 Active X 컨트롤은 VCL 컨트롤과 동일한 디자인 타임 기능을 갖지만 다른 동작을 가진 새 클래스를 만들기 위해 상속될 수 없습니다. OWL 및 MFC와 같은 기존 클래스 프레임워크에서는 내부 구조에 대한 많은 지식이 필요하며 RAD 도구의 디자인 타임 지원이 없으면 해당 기능이 제한됩니다. 앞으로 VCL의 기능과 맞먹을 수 있는 도구는 Windows Foundation Class인 Visual J++의 WFC(Windows Foundation Classes)입니다. 그러나 Java 문제에 대한 Sun Microsystems의 소송이 아직 계류 중인 상황에서 Visual J++의 미래는 불분명합니다.