java spring 区别_Java Spring中依赖注入与工厂设计模式的区别？ - 知识铺

知识铺： 致力于打造轻知识点，持续更新每次的知识点较少，阅读不累。不占太多时间，不停地来唤醒你记忆深处的知识点。

一、设计模式解决问题

学习Java或Python等编程语言很容易，但编写生产质量的代码很困难。编码是其背后的科学艺术。要编写好的代码，需要仔细设计类，它们的依赖关系以及如何使用它。如果已经编写了一段时间，那么就知道接口单一职责和设计模式可以帮助编写更好的代码，更容易维护的代码。但是，仅了解设计模式是不够的，还需要学习在正确的位置使用正确的设计模式。

二、Factory模式和依赖注入区别

2.1 依赖注入和工厂模式之间的主要区别在于前者依赖是由第三方框架或容器提供的，依赖性是由客户端类本身获取的。

2.2 依赖注入的使用松耦合设计，但是工厂模式在工厂和类之间产生紧密耦合，这取决于工厂生产的产品。

2.3 它们都创建了一个类的实例，并且还促进了接口驱动的编程而不是硬编码实现类。

2.4 工厂模式：客户端类负责调用 工厂类的getInstance()来创建产品实例，这也意味着客户端类直接与工厂耦合， 如果没有工厂类，则无法进行。

2.5 依赖注入：客户端类没有关于如何创建和管理其依赖关系的线索。它只知道依赖关系。

三、Spring Framework

3.1 bean类的框架注入的，没有任何硬编码依赖项，是由IOC容器注入与管理。Spring IOC只是依赖注入模式的实现。

3.2 Java Spring中的依赖注入和工厂设计模式

四、依赖注入与工厂模式简单实例对比

4.1 工厂模式代码示例

public class CashierRegister {

private PriceCalculator calculator = PriceCalculatorFactory.getInstance();

public void add(Transaction tx) {

int price = calcualtor.getPrice(tx); add(price);

}

}

4.1.1 这种情况下依赖类，CashierRegister直接与PriceCalculatorFactory耦合, 因为calculator是调用它的静态得到实例。从PriceCalculatorFactory以满足它的依赖性。为了测试CashierierierierierRegister，必须需要一个PriceCalculatorFactory，无法独立进行单元测试，不够单一。

4.1.2 如果使用依赖注入，那么依赖性将由Spring框架的DI容器之类的框架添加， 因为反转了获取依赖项的责任。OC容器的责任是注入依赖性，而不是依赖类依赖自己。在依赖注入的情况下，任何类看起来都像POJO。

4.2.依赖注入代码示例

public class CashierRegister {

private PriceCalculator calculator;

public CashierRegister(PriceCalculator calculator){

this.calculator = calculator;

}

public void add(Transaction tx) {

int price = calcualtor.getPrice(tx);

add(price);

}

public void setCalcuator(PriceCalculator calc){

this.calculator = calc;

}

}

4.2.1 CashierRegister的依赖项，即PriceCalculator是通过构造函数提供的，这称为构造函数依赖注入。

4.2.2 还有另一种形式的DI，例如setter注入，其中使用setter方法提供依赖性。

例如，setCalcuator(PriceCalcuator)正在促进那里的setter注入。应该使用构造函数注入来为可选的注入强制依赖项和setter注入，以便具有依赖性。

五、依赖注入与工厂设计模式总结

Java Spring中的依赖注入与工厂设计模式

工厂模式与依赖注入之间的区别

5.1 工厂模式增加了对象，工厂和依赖关系之间的耦合。对象不仅需要依赖对象才能正常工作，还需要Factory对象。在依赖注入的情况下，Object只知道依赖关系，它对容器或工厂一无所知。

5.2 与Factory模式相比，依赖注入使单元测试更容易。如果使用工厂模式，则需要创建要测试的对象，工厂和依赖对象。另一方面，如果使用依赖注入，则只需要模拟依赖项并注入要测试的对象，不需要多余对象来启动单元测试。

5.3 依赖注入比工厂模式更灵活。

5.4 依赖注入缺点是，需要一个容器和配置来注入依赖项，如果使用工厂设计模式，则不需要这样做。

5.5 由于低耦合，DI导致比工厂模式更清洁。对象看起来像POJO，也可以通过查看类正在使用哪种类型的依赖注入来了解什么是强制性的以及什么是选项。

5.6 使用DI的另一个问题，是创建一个具有太多依赖关系的对象，如果使用构造函数注入注入它们则更糟。代码变得难以阅读。该问题的一个解决方案是使用Facade模式并通过封装在另一个对象中来注入依赖项。例如，可以引入一个对象，例如ParamsSettings，它可以包含DatabaseSetting，FileSetting和对象所需的其他配置设置。

5.7 应该使用依赖注入模式让代码松散耦合。

这一切都在与工厂设计模式与Java中的依赖注入之间存在差异。这两种模式都是从依赖类中创建了依赖关系，并使用接口来定义属性，例如，在这里使用PriceCalculator这是一个接口，以便以后可以被任何合适的实现替换，而不会影响任何部分代码。

工厂和依赖注入之间的真正区别在于，在工厂的情况下，的依赖类仍然依赖于工厂，而DI完全取消了依赖。

这意味着依赖注入可以在工厂设计模式上提供更好的类解耦和单元测试。