Unity应用架构设计(8)——使用ServiceLocator实现对象的注入

对象的 『注入』 是企业级软件开发经常听到的术语。如果你是一个 Java 程序员,一定对注入有着深刻的映像。不管是SSH框架还是SSM框架,Spring 全家桶永远是绕不过去的弯。通过依赖注入,可以有效的解耦应用程序。在uMVVM框架中,我提供了另外一种对象注入的方式,称为Service Locator 『服务定位模式』 。与Spring的依赖注入不同的是,Service Locator 内部以字典的形式维护了对象的依赖关系,外部通过Key的形式获取 『Resolve』 到对应的Value,从而达到解耦。

为什么要注入对象

简而言之,为了解耦,达到 不去依赖 具体的对象。

实际上解耦是个非常 『虚』 的概念,只有软件到达一定的复杂度之后才会明白解耦和的好处,对于一个简单如『Hello World』程序而言,你很难理解为什么需要解耦。

假设有个 Foo 类,需要通过调用 SomeService 对象的方法去执行一些任务。很简单的需求,你可能会这样写:

public class Foo
{
ISomeService _service; public Foo()
{
_service = new SomeService();
} public void DoSomething()
{
_service.PerformTask();
...
}
}

这当然没问题,但有隐患,Foo 紧耦合了 SomeService,当需求变了,你不得不打开 Foo 类,然后找到构造函数,重新调用另外的 Service,改完之后编译,然后部署、测试等等。如果是Web程序,你还得在等到晚上去部署。

既然紧耦合了,那就解耦,你可能会这样写:

public class Foo
{
ISomeService _service; public Foo(ISomeService service)
{
_service = service;
} public void DoSomething()
{
_service.PerformTask();
...
}
}

这样很不错,Foo 与具体的 Service 解耦了,那怎样去实例化 Foo 呢?比如有一个 Bar 类:

public class Bar
{
public void DoSomething()
{
var foo = new Foo(new SomeService());
foo.DoSomething();
...
}
}

遗憾的是,BarSomeService 又耦合了。然后你又改成这样:

public class Bar
{
ISomeService _service; public Bar(ISomeService service)
{
_service = service;
} public void DoSomething()
{
var foo = new Foo(_service);
foo.DoSomething();
...
}
}

通过构造函数传递参数,BarSomeService 解耦了。但你打算怎样去实例化 Bar 呢?

额...(-。-

上一篇:利用before、after制作提示框


下一篇:UVALive - 3263 That Nice Euler Circuit (几何)