本人以前使用FORTRAN进行完全过程化的程序设计，自去年转而使用Delphi进行面向对象程序设计以来，发现编程的天空骤然扩展了许多。面向对象的程序设计方案较之模块化的程序设计思想更好的实现了算法功能的封装及继承，同时Object Pascall语言自身的优雅，Delphi快速集成开发环境的优越性让我感觉到原来编程也有如此的艺术体验。
由于本人转向面向对象程序设计时间太短，对于面向对象概念本身，对于Delphi和Object Pascal语言都不是非常熟悉，因此以下的一些个人的观点可能非常肤浅，请各位大侠指出和包含。
在我个人使用Delphi进行程序设计的时候，有以下几点让我觉得不太方便的：
第一、关于自定义运算符或者运算符的重载问题。
Delphi中没有运算符重载的功能，这是个很大的缺陷。由于本人编程的数据对象完全面向复数，而Delphi不提供复数类新，自定义的复数类所有的运算只能直接调用函数实现，这对于复杂的表达式就显得非常繁琐而且不易于维护。
重载是一个方面，自定义是另一个方面。有些运算是基本运算符中所不包含的，譬如说矩阵的逆和转置，我希望能够自定义出一个新的运算符。这方面Delphi不支持。
对于以上的功能，目前还属于过程化程序设计的Fortran语言却支持良好。对于语言语法本身而言，实现对这方面功能的支持应该不是什么非常困难的事情。不知道Object Pascal中为什么不扩展。
第二、类中的模块化。
这是从程序的可读性和易维护方面来说的。在一个功能很强的庞大的类中，类属方法和函数本身也存在模块化的问题。我希望几个相关的函数和过程能够写在一起，在这些方法实现代码中也一样，写在一个连续的“模块”中。Delphi将类声明和实现代码分开，方便了阅读和维护，但是实现部分的代码却很乱，尽管Delphi提供了相关的功能让你能较快地找到相应的代码，但我觉得还是不太方便。有时候我只需要打印部分相关的源码，这就显得极不方便。因此，我希望类中能够再度“模块化”，积累的明可以如下：
TMyClass=Class
Private
Module1:
fx1,...,fXn:Double;
Procedure ...
function ...
Module2:
...
Module3:
...
Protected
Module1:
....
Module2:
...
Module3:
... Public
Module1:
....
Module2:
...
Module3:
...
Published
Module1:
....
Module2:
...
Module3:
...
End;
在实现中，编译器自动将相关源码统一集成在一个相应的模块内。（哈哈，现在Delphi这方面做的确实不好，类的相关源码都没有写在一起）。
第三、关于提供可选特征（ Option Attribute）的建议
封装是面向对象的目标和成就之一。然而，在我的编程过程中，我希望还能有一种“可选特征”。这种特征（Attribute）可以设为一种枚举变量，其值为Private，Protected，Public，Published的一种。因为在程序设计中，经常遇到这样的现象：由的数据对象一开始不允许访问，而在其他数据对象进行了某种操作以后才可以进行访问。例如我要进行曲线拟合，必须在已知的拟合数据已经赋值的情况下方可进行，否则就会引起错误。将拟合方法赋予“可选特征”，一开始其值为私有的（Private),在拟合数据赋值后再将其设为共用的(Public)，这样封装起来的类数据安全性更好，而且也可能，更容易调试和维护。
以上只是我的一些拙见，大侠们尽管批评指教，不用客气。
由于本人转向面向对象程序设计时间太短，对于面向对象概念本身，对于Delphi和Object Pascal语言都不是非常熟悉，因此以下的一些个人的观点可能非常肤浅，请各位大侠指出和包含。
在我个人使用Delphi进行程序设计的时候，有以下几点让我觉得不太方便的：
第一、关于自定义运算符或者运算符的重载问题。
Delphi中没有运算符重载的功能，这是个很大的缺陷。由于本人编程的数据对象完全面向复数，而Delphi不提供复数类新，自定义的复数类所有的运算只能直接调用函数实现，这对于复杂的表达式就显得非常繁琐而且不易于维护。
重载是一个方面，自定义是另一个方面。有些运算是基本运算符中所不包含的，譬如说矩阵的逆和转置，我希望能够自定义出一个新的运算符。这方面Delphi不支持。
对于以上的功能，目前还属于过程化程序设计的Fortran语言却支持良好。对于语言语法本身而言，实现对这方面功能的支持应该不是什么非常困难的事情。不知道Object Pascal中为什么不扩展。
第二、类中的模块化。
这是从程序的可读性和易维护方面来说的。在一个功能很强的庞大的类中，类属方法和函数本身也存在模块化的问题。我希望几个相关的函数和过程能够写在一起，在这些方法实现代码中也一样，写在一个连续的“模块”中。Delphi将类声明和实现代码分开，方便了阅读和维护，但是实现部分的代码却很乱，尽管Delphi提供了相关的功能让你能较快地找到相应的代码，但我觉得还是不太方便。有时候我只需要打印部分相关的源码，这就显得极不方便。因此，我希望类中能够再度“模块化”，积累的明可以如下：
TMyClass=Class
Private
Module1:
fx1,...,fXn:Double;
Procedure ...
function ...
Module2:
...
Module3:
...
Protected
Module1:
....
Module2:
...
Module3:
... Public
Module1:
....
Module2:
...
Module3:
...
Published
Module1:
....
Module2:
...
Module3:
...
End;
在实现中，编译器自动将相关源码统一集成在一个相应的模块内。（哈哈，现在Delphi这方面做的确实不好，类的相关源码都没有写在一起）。
第三、关于提供可选特征（ Option Attribute）的建议
封装是面向对象的目标和成就之一。然而，在我的编程过程中，我希望还能有一种“可选特征”。这种特征（Attribute）可以设为一种枚举变量，其值为Private，Protected，Public，Published的一种。因为在程序设计中，经常遇到这样的现象：由的数据对象一开始不允许访问，而在其他数据对象进行了某种操作以后才可以进行访问。例如我要进行曲线拟合，必须在已知的拟合数据已经赋值的情况下方可进行，否则就会引起错误。将拟合方法赋予“可选特征”，一开始其值为私有的（Private),在拟合数据赋值后再将其设为共用的(Public)，这样封装起来的类数据安全性更好，而且也可能，更容易调试和维护。
以上只是我的一些拙见，大侠们尽管批评指教，不用客气。
delphi还可以更强大！！！！！！！！！！现在也很强。
Delphi的博大精深不是一个公司二三个开发组四五个人六七天就能说的八九不离十的。
软件体系结构不是语言的问题，而是思想的问题，特别是OO的问题。
其实delphi提供了这类的简单解决办法，避免一个文件过大。那就是类似C语言的#include的{$include xxxxx}，它可以放在你需要的地方，把一个文件分为若干部分。3.这个问题有点违背了OOP自身的封装概念，但是我想通过合理的设计类的结构应该完全可以觉得。个人意见，班门弄斧了。
bcb应该能满足你的要求，而且有强大的STL库支持。
希望增加多重继承
希望提供更多的工具和Demo，特别是最新技术