为什么这么苛刻地来评论VCL的基础类设计，我已经在前一篇关于TObject的文章中讲过。今天我拿出在一次跟踪VCL代码的过程中发现的问题。在此之前，我没有任何理由会相信会存在这样的情况。
TForm读取dfm文件创建窗体过程大家一定都比较清楚，其中负责读取的是Classes.pas单元中的TReader类，而它在实现的时候，会调用到如下的函数：
function InternalReadComponentRes(const ResName: string; HInst: THandle; var Instance: TComponent): Boolean;
var
HRsrc: THandle;
begin { avoid possible EResNotFound exception }
if HInst = 0 then HInst := HInstance;
HRsrc := FindResource(HInst, PChar(ResName), RT_RCDATA);
Result := HRsrc <> 0;
if not Result then Exit;
with TResourceStream.Create(HInst, ResName, RT_RCDATA) do
try
Instance := ReadComponent(Instance);
finally
Free;
end;
Result := True;
end;
大家请注意TResourceStream的方法ReadComponent。是的，我想说的其实就是这个方法。大家可以回过头来看看TStream的声明：
function ReadComponent(Instance: TComponent): TComponent;
function ReadComponentRes(Instance: TComponent): TComponent;
procedure WriteComponent(Instance: TComponent);
procedure WriteComponentRes(const ResName: string; Instance: TComponent);
procedure WriteDescendent(Instance, Ancestor: TComponent);
procedure WriteDescendentRes(const ResName: string; Instance, Ancestor: TComponent);
procedure WriteResourceHeader(const ResName: string; out FixupInfo: Integer);
procedure FixupResourceHeader(FixupInfo: Integer);
procedure ReadResHeader;
对于Stream这个抽象概念，很多人对它的理解过程都是曲折的。但不管怎么样，它基本特性还是比较清晰的。Read、Write、Position、Seek等等基本方法，构成了流的基本属性。
然而，令我不明白的地方是，为什么Delphi会在基础类TStream中增加上述的那些有关Component的方法。这些显然和流的职责没有关系！
在单一职责原则中，建议将两种不同的职责分成两个类实现，或继承、或组合。要说TStream的这些Component的方法，要么可以定义单独的Component资源类， 要么做出TStream的Helper类。但总比像VCL这样设计好吧。
现在猜想VCL当时的设计情形，很可能Classes单元的类，很多是为了Delphi的组件系统的实现（或者说是IDE本身）。所以很多类在设计的时候，默认都引入了TComonent类。
这么说是有根据的，不光是TStream类，在这个单元中的TParser类也是如此。我发现TParser类的时候是非常惊喜的，但是使用后发现，其规则是按照dfm来做的。在分析Delphi的源码的时候，会遇到注释不能识别的问题。
一向认为单一职责最难把握，现在看VCL，呵呵，确实如此啊。
| 这个我倒是非常同意楼主的。在Stream中加了那么多Component的方法我觉得是设计上的失败。 优雅一点的设计方式是，在Component中加入关于Stream的方法。 |
| 呵呵，这个地方确实是恶心了点，比起Java的流机制就失败了很多，我想宝兰的流其实更多的是与界面窗体的流化关联起来，不过作为最早最成功的的FrameWork也不用太苛责了。 |
| 搂主的想法有道理，但borland的想法也不无道理，因为这样从tStream的派生类都有component的操作功能，这样vcl可以把可视化资源保存到任何流中，也可以从任何流中读出，这样对我们这些多数以component来做应用的使用者来说更加容易把componet直接流化到我们自己特定的ttream派生类中，所以从vcl角度上这样做没有什么错。 |
