델파이 언어

델파이란

 

미국 볼랜드에서 오브젝트 파스칼 언어의 기능을 향상시켜 개발한 일반 응용 프로그램 개발 언어이다 또한 데이터베이스 프로그래밍까지 가능한 VCL 개발도구이다. VCL이라고 불리는 하나의 객체 지향적인 구조를 사용하며 코딩하는 과정에서도 완성 후의 모습을 살펴볼 수 있다.

 

위 글은 지식백과에 나와 있는 간단한 요약이다 단 3줄만으로는 델파이에 대해 알기 어려울 것이다.

왜 델파이가 좋은가?

왜 꼭 델파이를 써야 하지?

라는 물음에 대한 가장 짦은 답변은 바로 생산성이다. 델파이는 윈도우즈 애플리케이션 개발 도구 중에서 가장 생산적인 도구이다 당연히 직장 상사나 고객의 관점에서는 이 답이 충분하지 않을 것이다. 그렇다면 여기 긴 답변을 들어보아야 한다 긴 답은 델파이의 생산성을 극대화 해 주는 제품의 질과 관련해 표현된다. 소프트웨어 개발 도구의 생산성은 5개의 중요한 속성으로 표현할 수 있다.

 

비주얼 개발 도구 환경의 질

효율적으로 컴파일된 코드 대 컴파일러의 속도

프로그래밍 언어의 힘과 복잡함

데이터베이스 구조의 유연함과 확장성

프레임워크에 의한 디자인과 사용 패턴

 

비록 배포 문제 문서 써드파티 지원 등 다른 많은 요인들이 얽혀 있지만 델파이 초보자들을 위해 우리가 왜 델파이를 선택하는지 조금 더 쉽고 확실하게 설명할 수 있는 방법이 있다. 어떤 주제들은 조금 주관적이지만 중요한 점은 특정 도구를 사용해서 얼마나 생산적으로 작업을 하는가일 것이다.

 

 

비주얼 개발 도구 환경의 질

 

비주얼 개발 환경은 일반적으로 세 가지 구성요소로 이야기 할 수 있다 에디터 디버거 폼 디자이너가 바로 그것이다. 요즘 나오고 있는 RAD 도구들은 애플리케이션 개발을 할 때 대부분 이 세가지를 이미 조화시켜 놓고 있다. 여러분들이 폼 디자이너로 작업할 때 델파이는 뒤에서 여러분들이 폼 위에 떨어뜨린 컴포넌트에 관련된 코드를 생성한다 여러분은 에디터에서 프로그램 동작을 정의하기 위한 추가 코드를 덧붙일 수 있고 또 이 에디터에서 중단점 Watch 기능 등을 설정해 애플리케이션을 디버깅 할 수 있다.

 

 

컴파일러의 속도와 컴파일된 코드의 효율성

 

빠른 속도의 컴파일은 소프트웨어의 개발을 가속화 시킬 수 있게 해 주었다.

소스 코드의 수정 -> 컴파일 -> 테스팅 -> 수정 -> 재 컴파일 -> 테스팅

위 과정의 반복에 대해 델파이는 매우 능률적인 개발 환경을 제공한다.

 

컴파일 속도가 더 느려진다면 개발자는 개발 기간 동안 제한된 코드만을 만들 수밖에 없을 것이다.

 

런타임때 능률 향상의 이점은 언제나 명확하다. 더 빠른 실행 속도와 더 적은 바이너리 코드는 언제나 좋은 것일 수밖에 없다. 아마도 델파이의 기초가 된 오브젝트 파스칼 컴파일러의 가장 유명한 특징은 빠른 속도일 것이다. 사실 이것은 윈도우즈에서 가장 빠른 하이레벨 네이티브 컴파일러일 것이다.

 

 

프로그래밍 언어의 능력 대 복잡성

 

능력과 복잡성은 개인의 주관에 의해 좌우된다. 그리고 이 특별한 주제는 온라인상의 불꽃 튀는 논쟁의 기수에 섰던 주제이기도 하다. 누군가에겐 쉬운 것이 다른 사람에게는 어려울 수도 있고, 또 다른 어떤 사람에겐 우아한 것으로 생각될 수도 있다. 따라서 다음 내용은 이글을 읽는 여러분의 경험과 개인의 취향에 의거한다.

 

어셈블리는 궁극적으로 가장 강력한 언어이다. 극소수의 사람들만이 그 언어를 다룰 수 있다. 그러나 어셈블리로는 가장 단순한 윈도우즈 프로그램을 제작하는 것도 매우 힘들고, 에러를 발생시킬 소지가 큰 모험이 될 것이다. 비단 그것뿐만 아니라 팀 환경에서 어셈블리 코드 기반을 어느 기간 동안 유지하는 것은 거의 불가능에 가깝다. 그 코드는 한 개발자에게서 다른 개발자로 옮겨가고 디자인에 관한 아이디어와 목적이 추가되면 될수록 코드가 컴퓨터용 언어가 아니라 외계어처럼 보이기 시작할 때까지 더욱 더 미궁 속으로 빠지게된다. 그러므로 어셈블리가 비록 강력하긴 하지만 모든 애플리케이션을 개발하기에는 너무 복잡하기 때문에, 어셈블리에 매우 낮은 점수를 줄 수밖에 없다

 

C++는 상당히 강력한 또 다른 언어이다 전처리 매크로, 템플릿, 연산자 오버로딩과 같은 정말로 강력한 기능의 도움으로 C++내에서 자기 자신만의 언어를 디자인 할 수 있다. 만일 이러한 광대한 기능들을 현명하게 사용한다면, 매우 깔끔하고 유지보수가 용이한 코드를 개바랄 수 있을 것이다. 그러나 문제는, 많은 개발자들이 이러한 기능들을 남용한 덕에 정말로 끔찍한 코드를 만들어 내곤 한다는 것이다. 사실 나쁜 코드를 작성하는 것이 좋은 코드를 작성하는 것보다 쉽다. 이것은 언어 자체가 좋은 디자인을 만들어 내는게 아니라 좋은 디자인을 만들어 내는 것은 개발자의 몫이기 때문이다.

 

복잡함과 강력함 사이에 매우 훌륭한 균형을 이루었다는 점에서 오브젝트 파스칼과 자바를 꽤 비슷하다고 느끼곤 한다. 이 두 언어는 개발자에게 논리적인 디자인을 강요하기 위하여 사용 가능한 기능들을 제한하는 방식을 채택하고 있다. 예를 들면, 두 언어 모두 클래스가 다중 인터페이스를 구현할 수 있도록 하기 위해 객체 지향이긴 하지만 쉽게 남용될 수 있는 다중 상속 개념을 사용하는 것은 피하고 있다. 양쪽 다 연산자 오버로딩이라는 위험한 기능도 제외하고 있다. 또한 두 언어 모두 링커에 의해 다뤄지는 세부항목보다는 언어 차원에서 최적화된 소스 파일을 만들어 낸다. 덧붙이자면, 두 언어는 예외처리, RTTI, 순수한 메모리 관리 문자열과 같은 효율적인 기능이 추가된 특징상의 이점을 가지고 있다. 그리고 이 두언어는 어떤 큰 단체에 의해 만들어진 것이 아니고 개인 혹은 작은 단체에 의해 만들어졌다.

 

 

데이터베이스 아키텍처의 유연성과 확장성

 

델파이는 볼랜드의 데이터베이스 규모가 작은 것을 극복하기 위해 어떤 툴보다 더 탄력적인 데이터베이스 구조를 유지하고 있다. 막 설치한 후의 dbExpress는 매우 효율적이긴 하지만, 드라이버의 선택은 다소 제한적이다. 비록 BDE가 볼랜드에 의해 단계적으로 사라지고는 있지만, BDE는 여전히 넓은 범위의 데이터 소스에 대해 대부분의 프로그램에서 잘 동작한다. 부가적으로, 네이트브 ADO 컴포넌트는 ADO 또는 ODBC를 통하여 서로 통신하기 위한 효율적인 방법을 제공한다. 만일 인터베이스 환경이라면, IBExpress 네이티브 인터베이스 컴포넌트들은 그 데이터베이스 서버와 서로 통신할 수 있는 가장 멋진 수단을 제공한다. 만약 이런 연결들 중 어느 것도 사용자가 원하는 데이터 접근을 허용하지 않는다면, 추상 데이터셋 아키텍처를 사용해서 자신만의 데이터 접근 클래스를 작성하거나 써드파티 데이터셋 솔루션을 구입해야한다.

 

마이크로소프트의 툴들은 논리적으로 ODBC, OLD DB 같은 마이크로소프트 자신의 데이터베이스와 데이터 접근 솔루션들에 초점을 맞추는 경향이 있다.

 

 

프레임워크에 의해 통제되는 디자인과 사용 패턴

 

이 부분은 다른 툴들이 놓치고 있는 소프트웨어 디자인의 거의 독보적인 것이다. 다른 모든 것들이 비슷해지고, VCL이 델파이에서 가장 중요한 부분으로 되어 있다. 디자인 시에 컴포넌트를 잘 다루는 능력, 컴포넌트의 디자인, 객체 지향 기술을 사용한 다른 컴포넌트로부터의 상속, 이것들은 델파이의 생산성에서 중요한 부분이다. VCL 컴포넌트를 제작할 때에는 여러 가지 경우에 맞는 객체 지향 메소드 로직의 구상에 많은 시간을 소비하게 된다. 비교해 보면 다른 컴포넌트 기반의 프레임워크는 종종 너무 유연성이 없거나, 너무 복잡하게 구성되어 있다.

 

예를 들어 ActiveX 컨트롤은 VCL 컨트롤의 디자인타임 이점과 유사한 많은 편의성들을 제공한다. 하지만 조금 다른 수행을 하는 새로운 클래스를 생성할 때에는 ActiveX 컨트롤로부터 상속받을 방법이 없다. OWL, MFC 같은 전통적인 클래스 프레임워크는 일반적으로 생산성 향상을 목적으로 제작자가 엄청난 양의 내부 프레임워크 지식을 가지고 있을 것을 요구한다. 그리고 이것들은 RAD 툴 같은 디자인타임 지원이 부족하다는 제한이 있다. 마이크로소프트의 닷넷 공통 라이브러리는 마침내 마이크로소프트를 컴포넌트 기반 개발의 측면에서 볼 때 옳은 방향으로 이끌어 가고 있다. 그리고 그것은 C#, 비주얼 C++와 비주얼베이직 같은 여러 가지 툴들에서도 같이 작업할 수 있게 했다.