我目前正忙于为现有技术实现一个流畅的接口,这将允许类似于以下代码片段的代码:
using (var directory = Open.Directory(@"path\to\some\directory"))
{
using (var file = Open.File("foobar.html").In(directory))
{
// ...
}
}
为了实现这样的构造,需要类来累积参数并将它们传递给其他对象。例如,要实施Open.File(...).In(...)
构造,你需要两个类:
// handles 'Open.XXX':
public static class OpenPhrase
{
// handles 'Open.File(XXX)':
public static OpenFilePhrase File(string filename)
{
return new OpenFilePhrase(filename);
}
// handles 'Open.Directory(XXX)':
public static DirectoryObject Directory(string path)
{
// ...
}
}
// handles 'Open.File(XXX).XXX':
public class OpenFilePhrase
{
internal OpenFilePhrase(string filename)
{
_filename = filename
}
// handles 'Open.File(XXX).In(XXX):
public FileObject In(DirectoryObject directory)
{
// ...
}
private readonly string _filename;
}
也就是说,语句(例如初始示例)的组成部分越多,需要创建的对象就越多,以便将参数传递给链中的后续对象,直到实际语句最终执行为止。
问题:
我对一些观点感兴趣:使用上述技术实现的流畅界面是否会显着影响使用它的应用程序的运行时性能?对于运行时性能,我指的是both速度和内存使用方面。
请记住,只需在非常短的时间跨度内创建大量潜在的、节省参数的临时对象,我认为这可能会给垃圾收集器带来一定的压力。
如果您认为这对性能有显着影响,您是否知道实现流畅界面的更好方法?
一般来说,生命周期非常短的对象正是 GC 最有效处理的对象类型,因为它们中的大多数将在下一次次要收集运行时死亡——并且在任何像样的 GC 实现中,次要集合与总大小成正比live对象。因此,短命对象的成本非常低,并且它们的分配意味着仅向上移动指针,这很快。
所以我想说:可能不会对性能产生重大影响。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)