VCL框架评价向来是很高的，但今天我搞个小玩意儿却有了点想法，但愿是我不对
面向对象的设计思想是基类要简单，几乎啥也不干才好，派生类不断的去扩展它，加入新的功能。
我今天觉得TShape类不满足要求，我想要它能够相应OnClick事件，并且有一个标签能够显示文字。我决定扩展它，写个组件从TShape继承。
正常的想法就是我要扩展功能，写出新的代码出来实现我要的功能，而这些功能都是TShape所没有的。
但是查了一下实现方法，发现完全不是这样，恰恰相反。这些功能基类全部都有，一直可以甚至追溯到TContol。我自己实际上什么也不需要干，仅仅就是把基类已经实现但是声明为Private的东西重新声明为public或者published就可以了，几乎不用写别的什么代码。
这能叫继承吗？实在是非常奇怪。
基类实现了大部分的所有功能，然后隐藏起来，派生类实际上要做的就是放开这些功能，作些重声明就可以了。
我承认，这种实现方式，对开发人员非常方便，这次这个新组件几乎没有几行新代码就完成了。但是这种思想我觉得有些怀疑。

[解决办法]
这就是快速开发的好处.
当然,你愿意自己重新写,我也没有意思.你可以找一个更为原始的祖先类,从头写起 0(n__n)0
[解决办法]
用API的DrawText就可以达到同样的目的，用DrawText画文字，编译后仅几个字节，但用TLabel组件，编译后多1000倍也不止。
-----------------------------------
“编译后仅几个字节”，不过，再加上改变颜色，位置，字体等等属性。编译出来的就不至几个字节了。
如果加上事件的处理，代码就不知道多少了。
再从开发效率上来看，用API来实现是不是就不太合适了。
[解决办法]
首先你的认识就有偏差
“面向对象的设计思想是基类要简单，几乎啥也不干才好，派生类不断的去扩展它，加入新的功能。”
这种想法本身就不OO

继承的目的是为了复用，不是为了有个好看的“家谱”，
如果功能都在子类实现，要个父类做什么？
多态就是为了解决这种子类的个性化要求的，
如果一味把继承当作扩展功能的手段，等出现“十八代子孙”的局面，也就该崩溃了。

VCL已经有些年头了，它诞生的时候，还没有接口这个东西，
事实上有了接口以后，在很多场合都在强调优先使用接口而不是继承。

没有什么东西是完美的，VCL也不例外，
不要把它的一些做法当作金科玉律，一味盲从
也不要因为一些历史问题，就把它全盘否定
[解决办法]
最好的办法是学习它，使用它，等自己本事长进了，再弄一套更优美的出来，而不是在还不了解它的时候就否定它
framework的作用是简化开发，易学易用，兼顾而不是强调效率或简洁
敢整一套framework是很了不起的事情，要兼顾的东西很多，甚至需要改造语言本身，vcl基于Pascal、JDK基于Java、dotNet基于C#，其实大家可以很容易得出一个结论，推出这些framework的都是因为其厂商对语言有掌控权，这也是vcl为什么不用c++来写的原因吧。等楼主看过JDK、dotNet的构架后会发现，他们跟vcl是如此的似曾相识，你就知道vcl的伟大了