Delphi 流畅的界面

使用上有什么优点和缺点流畅的界面 http://en.wikipedia.org/wiki/Fluent_interface在德尔福？

流畅的界面应该会增加可读性，但我对此有点怀疑one包含很多链式方法的长 LOC。

是否存在编译器问题？
是否存在任何调试问题？
是否存在任何运行时/错误处理问题？

流畅的界面用于例如TStringBuilder http://docwiki.embarcadero.com/VCL/en/SysUtils.TStringBuilder, THTML编写器 http://code.google.com/p/delphihtmlwriter/ and TGpFluentXMLBuilder http://17slon.com/blogs/gabr/2009/04/fluent-xml-1.html.

Updated:
大卫·赫弗南 (David Heffernan) 问我关心哪些问题。我对此进行了一些思考，总体问题是“明确指定它是如何完成的”与“让编译器决定它是如何完成的”之间的区别。

AFAICS，没有关于编译器实际如何处理链式方法的文档，也没有关于编译器应如何处理链式方法的任何规范。

In 本文 http://docwiki.embarcadero.com/RADStudio/en/Program_Control我们可以了解编译器如何向声明为函数的方法添加两个额外的 var 参数，以及标准调用约定将三个参数放入寄存器中，并将下一个参数放入堆栈中。因此，具有 2 个参数的“流畅函数方法”将使用堆栈，而具有 2 个参数的“普通过程方法”仅使用寄存器。

我们还知道编译器会执行一些魔法来优化二进制文件（例如字符串作为函数结果 https://stackoverflow.com/questions/3250827/initialise-string-function-result/3251381#3251381, 评估顺序 https://stackoverflow.com/questions/3054526/delphi-compiler-directive-to-evaluate-arguments-in-reverse/3054899#3054899, 引用本地过程 https://stackoverflow.com/questions/5044981/loosen-local-procedure-function-assigned-to-procedure-variable-restriction-grac），但有时会给程序员带来令人惊讶的副作用。

因此，内存/堆栈/寄存器管理更加复杂，而且编译器可能会产生一些意想不到的副作用，这一事实对我来说非常臭。因此就有了这个问题。

在我阅读了答案（非常好的答案）后，我的担忧大大减少，但我的偏好仍然是一样的:)

每个人都只写负面问题，所以让我们强调一些正面问题。呃，唯一的积极问题 - 更少（在某些情况下much少）打字。

我编写 GpFluentXMLBuilder 只是因为我讨厌在创建 XML 文档时键入大量代码。不多也不少。

流畅界面的好处是，如果您讨厌这种习惯用法，则不必以流畅的方式使用它们。它们完全可以以传统方式使用。

编辑：“简短和可读性”观点的一个观点。

我正在调试一些旧代码并偶然发现了这一点：

fdsUnreportedMessages.Add(CreateFluentXml
  .UTF8
  .AddChild('LogEntry')
    .AddChild('Time', Now)
    .AddSibling('Severity', msg.MsgID)
    .AddSibling('Message', msg.MsgData.AsString)
  .AsString);

我立即知道代码的作用。但是，如果代码看起来像这样（我并不是说这甚至可以编译，我只是将它放在一起进行演示）：

var
  xmlData: IXMLNode;
  xmlDoc : IXMLDocument;
  xmlKey : IXMLNode;
  xmlRoot: IXMLNode;

  xmlDoc := CreateXMLDoc;
  xmlDoc.AppendChild(xmlDoc.CreateProcessingInstruction('xml', 
    'version="1.0" encoding="UTF-8"'));
  xmlRoot := xmlDoc.CreateElement('LogEntry');
  xmlDoc.AppendChild(xmlRoot);
  xmlKey := xmlDoc.CreateElement('Time');
  xmlDoc.AppendChild(xmlKey);
  xmlData := xmlDoc.CreateTextNode(FormatDateTime(
    'yyyy-mm-dd"T"hh":"mm":"ss.zzz', Now));
  xmlKey.AppendChild(xmlData);
  xmlKey := xmlDoc.CreateElement('Severity');
  xmlDoc.AppendChild(xmlKey);
  xmlData := xmlDoc.CreateTextNode(IntToStr(msg.MsgID));
  xmlKey.AppendChild(xmlData);
  xmlKey := xmlDoc.CreateElement('Message');
  xmlDoc.AppendChild(xmlKey);
  xmlData := xmlDoc.CreateTextNode(msg.MsgData.AsString);
  xmlKey.AppendChild(xmlData);
  fdsUnreportedMessages.Add(xmlKey.XML);

我需要相当长的时间（和一杯咖啡）才能理解它的作用。

EDIT2:

埃里克·格兰奇（Eric Grange）在评论中提出了一个完全正确的观点。实际上，我们会使用某种 XML 包装器，而不是直接使用 DOM。例如，使用 OmniXMLUtilsOmniXML http://www.omnixml.com包，代码如下所示：

var
  xmlDoc: IXMLDocument;
  xmlLog: IXMLNode;

  xmlDoc := CreateXMLDoc;
  xmlDoc.AppendChild(xmlDoc.CreateProcessingInstruction(
    'xml', 'version="1.0" encoding="UTF-8"'));
  xmlLog := EnsureNode(xmlDoc, 'LogEntry');
  SetNodeTextDateTime(xmlLog, 'Time', Now);
  SetNodeTextInt(xmlLog, 'Severity', msg.MsgID);
  SetNodeText(xmlLog, 'Message', msg.MsgData.AsString);
  fdsUnreportedMessages.Add(XMLSaveToString(xmlDoc));

不过，我还是更喜欢流畅的版本。 [而且我从不使用代码格式化程序。]