乍一看，服务定位器模式在我看来与抽象工厂模式相同。它们似乎都有相同的用途（您查询它们以接收抽象服务的实例），并且在我阅读依赖注入时都提到了它们。
不过，I have seen the Service Locator pattern described as a poor idea，却见过direct support for the Abstract Factory pattern in at least one major Dependency Injection framework。
如果不一样，有什么区别？
【问题讨论】：
标签： design-patterns service-locator abstract-factory
我在调查这些模式时偶然发现了同样的问题。我认为可以在 Service Locator 和 Factory 之间找到主要区别（无论它是否抽象）：
【讨论】：
从我目前阅读的内容来看，我认为区别在于：
服务定位器模式
抽象工厂模式
【讨论】：
实际上这两种模式之间有明显的区别。众所周知，这两种模式都用于避免来自具体类型的依赖。
不过看完
出现了一些严重的矛盾：
Seemann 说：“抽象工厂是泛型类型，Create 方法的返回类型由工厂本身的类型决定。也就是说，构造类型只能返回单一类型的实例。”
虽然 Rober C. Martin 没有提及任何关于泛型类型的内容，此外，他书中的工厂示例允许创建多个类型对象的实例，使用密钥字符串作为 Factory.Make( ）。
Gamma 说抽象工厂的目的是“提供一个接口来创建相关或依赖对象的系列，而无需指定它们的具体类”。值得一提的是，Gamma Abstract Factory 示例违反了 Martin 所说的接口隔离原则 (ISP)。 ISP 和 SOLID 通常是更现代的原则，或者为了简单起见，省略了。
Gamma 和 Martin 的作品先于 Seemann，所以我认为他应该遵循已经做出的定义。
虽然 Fowler 提出服务定位器作为实现依赖倒置的一种方式，但 Seemann 认为它是一种反模式。 Gamma 或 Martin 都没有提到服务定位器。
但是，Seemann 和 Fowler 一致认为，Service Locator 需要一个配置步骤来注册具体类的实例，该实例将在稍后请求此类对象时返回。 Martin 或 Gamma 在他们对抽象工厂的定义中没有提到这个配置步骤。抽象工厂模式假设每次请求此类对象时都会实例化一个新对象。
结论
服务定位器和抽象工厂之间的主要区别在于，抽象工厂假设在每次请求时都会实例化一个新对象并返回，并且服务定位器需要配置一个对象实例，并且每次都将返回相同的实例。
【讨论】：
来自： http://blog.ploeh.dk/2010/11/01/PatternRecognitionAbstractFactoryorServiceLocator/
抽象工厂是泛型类型，Create方法的返回类型由工厂本身的类型决定。换句话说，构造类型只能返回单一类型的实例。
另一方面，服务定位器是具有通用方法的非通用接口。单个 Service Locator 的 Create 方法可以返回无数种类型的实例。
【讨论】：
Martin Fowler 描述了Service Locator Pattern 的几个实现，其中大部分是具体类，通过static 方法配置和调用。我认为我们可以忽略这些变化并专注于他使用依赖注入的最后一个示例，这是一种更现代的方法。我们可以将其与 GoF book 中的抽象工厂模式进行比较。
抽象工厂的显着特征是一组固定的相关产品。相反，服务定位器具有无限的不相关产品集。这使得 Service Locator 更像是一个黑盒子，并且可能导致该模式的主要criticism：它隐藏了 API 的依赖关系。当服务定位器被实现为动态注册表时，客户端可能会请求不存在的产品。这对于抽象工厂是不可能的。
考虑到抽象工厂和服务定位器之间的选择，前一种模式更可取。但这是一种错误的二分法，因为有更多选择。这两种模式都依赖于依赖注入，但没有它们，DI 会更好地工作。
注入是一种实现控制反转的机制。 IoC 是依赖倒置的理想形式，因为它最大限度地减少了客户端的复杂性并提供了最高级别的抽象。服务定位器和抽象工厂是实现依赖反转没有控制反转的两种机制。从 IoC 是理想的角度来看，它们都是不可取的，而且它们都没有实现。
有关 IoC 与 DI 的更多信息，请参阅：Inversion of Control vs Dependency Injection。
有关抽象工厂和服务定位器陷阱的更多信息，请参阅：Dependency Injection Code Smell。
【讨论】：