델파이 사고
영광의 가을 2002
Delphi는 지금까지 가장 잘 알려진 RAD(Rapid Application Development) 제품입니다.
Delphi 3.0은 Delphi 시리즈의 획기적인 버전입니다. 성숙하고 안정적인 Delphi 5.0은 엔터프라이즈 수준 개발 도구로서 Delphi의 선도적 위치를 더욱 강화합니다.
델파이 4.0은 내 기억에 최악의 버전이다. 이 패치를 적용한 후에는 프로그램을 정상적으로 컴파일할 수 없습니다. 해당 패치를 적용한 후에는 프로그램을 정상적으로 컴파일할 수 없습니다. 물론, 프로그램이 충분히 크고 복잡하지 않다면 Delphi에는 명백한 버그가 없습니다.
엔터프라이즈 소프트웨어 개발자에게 Delphi의 MIDAS 기술은 획기적인 의미를 갖습니다. 그 그림자는 오늘날에도 여전히 Microsoft .NET에서 볼 수 있습니다.
Delphi의 Active Form은 놀라운 기술입니다. 장점은 특별한 웹 지식 없이도 기존 Windows 프로젝트를 Active Forms로 쉽게 패키징할 수 있다는 것입니다. 이를 브라우저에 표시하려면 몇 줄의 코드만 추가하면 됩니다. IE를 시작하면 클라이언트 유지 관리 비용이 제거됩니다. 이 기술의 표현력도 ASP보다 훨씬 풍부합니다. 그러나 치명적인 결함도 있습니다. 너무 부피가 크고 고속 LAN에서만 실행하기에 적합하다는 것입니다.
전력계통에 널리 사용되는 금융소프트웨어에도 이 기술이 활용된다. 최고의 기술은 없고, 가장 적합한 기술만이 이런 곳에 사용하기에 완벽한 델파이의 Active Form 기술입니다.
이 기술을 광역 네트워크나 저속 LAN에서 사용하는 것은 악몽일 것입니다.
오브젝트 파스칼은 제가 좋아하는 가장 우아한 언어 중 하나입니다. 전통적이면서 현대적입니다. 단순하고 명확하지만 코드가 읽기 쉽고 Visual Basic 프로그램만큼 지루하지 않습니다. 게다가 C++와 마찬가지로 다양한 프로그래밍 스타일도 지원합니다.
3년 전만 해도 데이터베이스 관련 소프트웨어를 개발 중이지만 스크립팅 언어나 전용 개발 도구(예: Oracle's Developer 2000)를 사용하고 싶지 않았다면 실제 객체로 구동되는 개발 도구를 사용하고 싶었습니다. 지향적인 언어라면 델파이가 최선의 선택입니다.
Delphi의 설계자들은 대부분의 소프트웨어가 데이터베이스를 다루어야 한다는 것을 깨닫고 데이터베이스 관련 개발 기능에 대한 강력한 지원을 추가했습니다. 이 결정은 매우 현명한 것입니다. Delphi가 큰 성공을 거둘 수 있었던 것은 데이터베이스 개발에 대한 강력한 지원 덕분이었습니다.
데이터베이스에 대한 Delphi의 강력한 지원은 일부 특수 데이터베이스 개발 도구에 도달하거나 심지어 그 이상입니다. 그러나 일부 일반인들은 델파이가 단지 데이터베이스 개발 도구일 뿐이라고 오해하기 쉽습니다.
몇 년 전에 난징 신지에커우에 있는 신화서점에 눈에 띄게 놓여 있던 책이 기억납니다. 이름이 아주 우스꽝스러웠습니다. "관계형 데이터베이스: 델파이"(정확히 기억은 나지 않지만 거의 똑같습니다.) ).
볼랜드는 IDE(통합 개발 환경)의 기능 개발에 너무 많은 관심을 기울인 것 같습니다. 그러면 오브젝트 파스칼 언어의 품질이 더욱 향상될 수 있었을 것입니다. 이유는 말할 필요도 없습니다.
델파이는 일부 COM 관련 API 등 모든 Windows API를 래핑하지 않습니다. 이것이 제가 델파이를 포기한 이유 중 하나입니다.
RAD 개발 환경은 엔터프라이즈 수준의 프로젝트 소프트웨어 개발에 절대적으로 필요합니다. RAD는 소프트웨어 개발의 문턱을 낮추었고, RAD는 또한 수많은 냉담한 프로그래머를 "창조"했습니다. 나는 RAD 도구에 대한 오해와 편견이 이러한 냉담한 프로그래머들에게서 비롯된 것이라고 의심합니다.
최신 버전의 Delphi에는 항상 최신 기술이 포함되어 있습니다. 때때로 이러한 기술은 Microsoft의 개념일 뿐이지만 Borland는 이를 제품으로 구현했습니다. 그러나 델파이의 최신 기술은 때로는 과도기적 기술로만 간주될 수 있습니다.
Delphi 6.0은 데이터 액세스, 웹, XML을 크게 개선하고 지원하지만, 제 생각에는 Delphi 6.0은 단지 과도기 버전일 뿐입니다.
Delphi의 BDE(Borland Database Engine) 데이터 액세스 기술은 ODBC 데이터 소스를 완벽하게 지원하고 ODBC를 공격합니다. 이 기술은 Delphi 3.0에서 정점에 도달합니다. Delphi의 MIDAS 기술은 n계층 데이터 액세스 기술을 제공하지만 여전히 BDE를 기반으로 합니다. Delphi 5.0은 ADO를 완벽하게 지원하며 BDE를 포기할 계획입니다. Delphi 6.0의 dbExPRess 및 DataSnap 기술은 볼랜드의 지속적인 데이터 액세스 기술 혁신의 또 다른 예입니다.
그러나 BDE가 전성기를 맞이하고 오늘날 수많은 데이터베이스 액세스 기술이 있음에도 불구하고 ODBC의 위상은 여전히 대체할 수 없습니다. 데이터베이스 관련 API(예: Oracle의 OO4O)에 대한 직접 호출을 제외하고는 ODBC API의 효율성에 도달하거나 이에 근접할 수 있는 데이터 액세스 기술이 없습니다.
Microsoft는 Windows 플랫폼의 사실상의 표준이며, 레거시 코드의 힘은 종종 누구의 상상도 뛰어넘습니다.
VCL(Visual Component Library) 컨트롤과 ActiveX 컨트롤은 완전히 다릅니다. ActiveX 컨트롤은 언어 간 바이너리 재사용을 목표로 하는 반면, VCL 컨트롤은 Borland 개발 환경 내에서 구성 요소 재사용을 목표로 합니다. 재사용 수준은 실제로 MFC(Microsoft Foundation)와 같은 C++ 클래스 재사용과 비슷합니다. 클래스) 클래스 재사용.
VCL 컨트롤에 익숙한 프로그래머는 ActiveX 컨트롤을 별도로 게시하고 등록해야 하는 것에 지쳤습니다. ActiveX 컨트롤에 익숙한 사람들은 Delphi가 모든 것을 큰 파일로 컴파일하는 것이 재미있다고 생각합니다.
Delphi의 런타임 BPL(Borland 패키지 라이브러리)은 실제로는 Borland 형식 DLL로 생각할 수 있습니다. 프로그램 크기를 줄이고 싶거나 동일한 BPL을 사용하여 여러 프로그램을 동시에 릴리스하려는 경우 런타임 BPL을 사용하면 원하는 바를 실현할 수 있습니다.
자동 버전 증가 기능에 대한 Delphi의 편리한 지원으로 인해 Delphi 프로그래머는 Visual C++에서 버전 번호를 수동으로 수정해야 한다는 사실이 이상하다고 생각합니다. RAD와 non-RAD의 차이점은 여기에서 알 수 있습니다.
Delphi 모드는 C++Builder에 성공적으로 복제되었지만 지금까지 C++Builder의 기술은 일반적으로 Delphi의 최신 버전 기술에 비해 다소 뒤떨어져 있습니다. 이 상황이 빨리 해결되기를 바랍니다. 가능합니다.
Delphi와 C++Builder는 동일한 백엔드를 사용하지만 볼랜드는 Studio와 같은 통합 개발 환경에 처음부터 두 언어를 통합하지 않았기 때문에 동일한 스타일(심지어 기능까지) IDE 지원 언어 다른 맛이 판촉 판매 포인트로 사용되는데, 이는 나를 당황하게 합니다. 나는 이것이 잘못된 결정이거나 볼랜드에 충분한 자원이 부족하다는 힌트라고 생각합니다.
엔터프라이즈 소프트웨어 개발에 종사하고 C++에 집착하는 프로그래머들에게 C++Builder는 의심할 여지 없이 가장 좋아하는 프로그램입니다.
Delphi 프로그래머라면, C#에 익숙하다면 C#이 C/C++ 스타일 구문을 채택한 것 외에도 많은 사람들이 C#이 Java의 복제품이라고 말하는 사실 외에도 C#이 진화했다는 사실을 이해할 것입니다. Delphi에서 수많은 언어 디자인 아이디어를 끌어냈습니다.
나는 Anders Hejlsberg가 C# 언어를 디자인했을 때 먼저 본능적으로 Java 대신 Object Pascal을 떠올렸을 것이라고 믿습니다. C#의 단일 구현 및 다중 인터페이스 상속에 대한 객체 지향 구현을 살펴보세요. try/catch/finally 예외 처리 구조를 살펴보세요(많은 사람들이 이러한 기능이 모두 Java에서 유래했다고 말할 것입니다). 어떤 사람들은 이것이 Visual Basic에서 왔다고 말할 것입니다.) override 키워드를 보십시오... 우선 이 모든 것이 Object Pascal에서 나온 것이라고 결론을 내릴 수 있습니다.
말할 필요도 없이 Delphi는 .NET을 지원해야 합니다.
.NET 플랫폼 개발 도구 분야에서는 현재 Delphi만이 Microsoft Visual Studio .NET과 경쟁할 수 있습니다.
Windows 플랫폼에는 Microsoft를 좋아하지 않는 사람들이 항상 있지만 이들 중 대부분은 여전히 .NET으로 이동하기를 원하며 Delphi .NET은 이상적인 대안입니다.
Delphi .NET은 매우 흥미롭습니다.