【发布时间】:2012-09-19 21:06:19
【问题描述】:
这是一个通用的设计问题。我们经常使用接口来解耦组件,写入接口而不是实现等。有时接口使用基本的注入技术,例如,
interface IMyInterface
{
void DoSomething();
}
static class IMyInterfaceFactory
{
public static IMyInterface GetInstance()
{
return new MyInterfaceInstance();
}
}
class IMyInterfaceConsumer
{
IMyInterface mInterface;
public IMyInterfaceConsumer()
{
this.mInterface = IMyInterfaceFactory.GetInstance();
}
public void UseTheInterface()
{
this.mInterface.DoSomething();
}
}
我的问题是关于使用 var 关键字。甚至不使用真正的 C# 接口,但仍然在设计意义上创建一个“接口”,
static class IMyInterfaceFactory
{
// of course, this doesnt need to be a single instance
static MyInterfaceInstance mSingleInstance;
// no longer programming to the interface, just returning the instance
public static MyInterfaceInstance GetInstance()
{
// null coalesce
return mSingleInstance ?? (mSingleInstance = new MyInterfaceInstance());
}
}
class IMyInterfaceConsumer
{
public void UseTheInterface()
{
// shorthand way, could also omit var, too
var myInterface = IMyInterfaceFactory.GetInstance();
myInterface.DoSomething();
}
}
这样我仍然只需要更改一次工厂,只要它返回的任何实例支持需要使用的方法,它就可以工作。然而,优点是生产和消费对象甚至不需要知道任何显式接口,不存在。它还可以干净地支持具有多个方法的接口(防止臃肿的接口声明)。
一个明显的缺点是,每次您想从“接口”使用方法时,工厂可能必须重新实例化该类,除非缓存了单个实例(如上)或使用了一些记忆技术。
这种方法的优缺点?这是一种常见的做法吗?
【问题讨论】:
-
这不仅仅是关于 var 关键字,而是它与工厂结合使用的方式。
-
// shorthand way, could also omit var, too-- 怎么样? -
IMyInterfaceFactory.GetInstance().DoSomething();
-
“被消费,它会工作”,你的意思是:“它会编译”,对吧?我的印象是
var和dynamic在这里混淆了。 -
是的,我的意思是它会编译,好点。但这甚至适用于传统的 C# 接口——它只是确保只要类型实现(注意:语法上)它们继承的接口的方法,事情就会编译。我已经从标题中删除了动态以避免这种混淆。
标签: c# oop dynamic interface var