设计模式–控制反转模式
代码案例:
public class EmailService
{
public void Sendmessage() { }
}
public class NotificationsSystem
{
private EmailService svc;
public NotificationsSystem()
{
svc = new EmailService();
}
public void InterestingEventHappended()
{
svc.Sendmessage();
}
}
这段代码中,NotificationsSystem类依赖于EmailService类。当一个组件依赖于其他组件的时候,这便叫做耦合。在这个例子中,NotificationsSystem在构造函数的内部创建了一个EmailService的实例,换言之,就是通知系统精确的知道创建和使用了哪一种类型的服务。这种耦合表示了代码的内部链接性。一个类知道与其交互类的大量信息,称作高耦合。
高耦合的代码不宜维护,会增加软件修改的负担,因为修改一个类就很有可能破坏依赖于它的另一个类。
此时为了降低组件之间的耦合程度,一般采取两个步骤:
(1)在两块代码之间引入抽象层—一般引入接口或者抽象类来代表两个类之间的抽象层。
如下实例:
public interface IMessagingService
{
void Sendmessage();
}
public class EmailService: IMessagingService
{
public void Sendmessage() { }
}
public class NotificationsSystem
{
private IMessagingService svc;
public NotificationsSystem()
{
svc = new EmailService();
}
public void InterestingEventHappended()
{
svc.Sendmessage();
}
}
(2)把选择抽象实现的责任转移到消费者类的外部
即是:把EmailService类的创建转移到NotificationsSystem类的外部
控制反转模式(IOC):把依赖的创建移到使用这些依赖的类的外部,这称为控制反转模式。之所以这样命名则是因为反转的是依赖的创建,消除了消费者类对依赖创建的控制。
实现IOC的方式:
1.服务定位器–是控制反转模式的一种实现方式,通过一个称为服务定位器的外部组件来为需求一脸的组件提供 依赖。服务定位器有时是一个具体的接口,为特定服务提供强类型的请求(强类型服务定位器);有时可能为一个泛型类型,可以提供任意类型的请求服务(弱类型服务定位器)。
服务定位器的利弊:组件需求不透明。
弱类型服务定位器代码实例:
public interface IServiceLocator
{
object GetService(Type serviceType);
}
public static class ServiceLoactorEctensions
{
public static TService GetService<TService>(this IServiceLocator locator)
{
return (TService)locator.GetService(typeof(TService));
}
}
public class NotificationsSystem
{
private IMessagingService svc;
public NotificationsSystem(IServiceLocator locator)
{
svc = (IMessagingService)locator.GetService(typeof(IMessagingService));
}
public void InterestingEventHappended()
{
svc.Sendmessage();
}
}
2.依赖注入(DI)–是控制反转模式的另一种形式,通常由构造函数参数或者属性设置器来显示表示。