虽然我相信每个接触过 Java 的开发者都知道以下代码的意思：
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
这个例子非常简单，但不具备扩展性。如果想要改变消息、改变消息的输出方式（例如使用 HTML 标签而不是纯文本）都需要重新修改源码再进行编译。一个更好的做法是通过外部传入字符串参数：
public class HelloWorld {
public static void main(String[] args) {
if (args.length > 0) {
System.out.println(args[0]);
} else {
System.out.println("Hello World!");
}
}
}
现在可以不修改程序源码的情况下改变输出的消息。但是，这个程序负责渲染消息的组件（println ）也同时负责获取消息。这就意味着改变渲染器就需要重新修改源码。
依赖注入：渲染器和消息分开为了解除这种耦合关系，让这个程序变得更加灵活，应该让这些组件实现接口并定义组件和使用这些接口的程序之间的依赖关系。
重新编写消息提供的逻辑，采用一个接口来提供这种能力：
public interface MessageProvider {
String getMessage();
}
getMessage 本身就屏蔽了消息的获取机制，那么渲染器只要允许实现了这个接口的对象传入即可：
public interface MessageRenderer {
void render();
void setMessageProvider(MessageProvider provider);
MessageProvider getMessageProvider();
}
这样 MessageRenderer 就把提供消息的责任委托给了 MessageProvider。
Provider 对应接口的实现也非常简单：
public class HelloWorldMessageProvider implements MessageProvider {
@Override
public String getMessage() {
return "Hello World!";
}
}
Renderer 则调用传入的对象的方法：
public class StandardOutMessageRenderer implements MessageRenderer{
private MessageProvider messageProvider;
@Override
public void render() {
if (messageProvider == null) {
throw new RuntimeException("You must set the property messageProvider of class:"
+ StandardOutMessageRenderer.class.getName());
}
System.out.println(messageProvider.getMessage());
}
@Override
public void setMessageProvider(MessageProvider provider) {
this.messageProvider = provider;
}
@Override
public MessageProvider getMessageProvider() {
return this.messageProvider;
}
}
这种模式其实就是依赖注入的典型例子。入口的 main 方法则负责构建 Provider 和 Renderer，并将 Provider 作为依赖传入到 Renderer。
public class HelloWorld {
public static void main(String[] args) {
MessageRenderer messageRenderer = new StandardOutMessageRenderer();
MessageProvider messageProvider = new HelloWorldMessageProvider();
messageRenderer.setMessageProvider(messageProvider);
messageRenderer.render();
}
}
基于反射的工厂类
这个例子仍然有个小问题，如果修改 MessageRenderer 或者 MessageProvider 接口的实现，同样需要修改源码。为了解决这个问题，可以引入一个简单的工厂类，它从属性文件读取类的名称，并代表程序进行实例化：
public class MessageSupportFactory {
private static MessageSupportFactory instance;
private Properties props;
private MessageRenderer renderer;
private MessageProvider provider;
private MessageSupportFactory() {
props = new Properties();
try {
props.load(this.getClass().getResourceAsStream("./msf.properties"));
String renderClass = props.getProperty("renderer.class");
String providerClass = props.getProperty("provider.class");
renderer = (MessageRenderer) Class.forName(renderClass).getDeclaredConstructor().newInstance();
provider = (MessageProvider) Class.forName(providerClass).getDeclaredConstructor().newInstance();
} catch (Exception e) {
e.printStackTrace();
}
}
static {
instance = new MessageSupportFactory();
}
public static MessageSupportFactory getInstance() {
return instance;
}
public MessageRenderer getMessageRenderer() {
return renderer;
}
public MessageProvider getMessageProvider() {
return provider;
}
}
创建对应的配置文件 msf.properties：
renderer.class=com.ft.StandardOutMessageRenderer provider.class=com.ft.HelloWorldMessageProvider
重新修改 main 进行初始化：
public class HelloWorld {
public static void main(String[] args) {
MessageRenderer mr = MessageSupportFactory.getInstance().getMessageRenderer();
MessageProvider mp = MessageSupportFactory.getInstance().getMessageProvider();
mr.setMessageProvider(mp);
mr.render();
}
}
至此，我们从 HelloWorld 开始，然而一步步让程序更加灵活。现在修改消息和渲染机制都很简单。
Spring重构如果说上面的程序还有什么问题，那就是必须编写大量的胶水代码来将应用程序拼凑在一起。第二个问题就是仍然需要手动提供接口的对应实现类。 Spring 就可以用来解决这个问题。
可以将 MessageSupportFactory 完全删除，使用 Spring 的 ApplicationContext 替换它。这个接口存储 Spring 所管理的有关程序的所有的环境信息，并扩展了另外一个接口 ListableBeanFactory ，该接口充当 Spring 管理的任何 bean 实例应用程序。
package com.example.demo;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class DemoApplication {
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("spring/app-context.xml");
MessageRenderer mr = ctx.getBean("renderer", MessageRenderer.class);
mr.render();
}
}
在这段代码中，可以看到 ClassPathXmlApplicationContext 从 spring/app-context.xml 中获取应用程序的配置信息，类型为 ApplicationContext ，并通过使用 getBean 来获取 MessageRenderer 实例。
app-context.xml 的作用和之前的工厂类 MessageSupportFactory 是一样的：
名称空间
从 Spring 3.0 开始，开发 Spring 不再需要 XML 配置文件，可以替换成注解和配置类。配置类是用 @Configuration 注解的 Java 类，它包含了 bean 定义（用 @bean 注解的方法），或者通过 @ComponentScanning 对 bean 定义进行注解，从而识别应用程序中 bean 的定义。
以下的配置类和前面的 bean-context.xml 等价：
package com.example.demo;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class HelloWorldConfiguration {
// 等价于
需要将 ClassPathXmlApplicationContext 方法替换成从配置类读取 bean 定义的 ApplicationContext 实现类 AnnotationConfigApplicationContext ：
package com.example.demo;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class DemoApplication {
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(HelloWorldConfiguration.class);
MessageRenderer mr = ctx.getBean("renderer", MessageRenderer.class);
mr.render();
}
}
小结
本文唯一做的一件事情就是打印 HelloWorld。从最原始的 HelloWorld，到程序启动参数控制，接着引入接口进行解耦。为了进一步让整个程序变得更加灵活，引入配置文件和工厂设计模式。Spring 则在这个基础上减少了大量胶水代码，让整个程序集中在业务层面，而这就是 Spring 最初的意义。当然，这篇只是碰到了 DI 的皮毛，并没有深入到 Spring 中的 IoC 和 DI。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）