Tag: 抽象工厂

Factory方法更适合图书馆的框架和抽象工具吗？

Abstract Factory和Factory方法模式都是创建设计模式，它解决了不同场景下的对象创建问题。 根据GOF 工厂方法模式 定义用于创建对象的接口，但让子类决定实例化哪个类。 Factory方法允许类将实例化延迟到子类。 我的理解： 客户端的动机是获得一个存在于基础工厂类中的方法得到执行，这取决于现在不知道具体类的对象（在这种情况下，无论是在向客户提供软件期间，它都将是定义，或者客户自己编写具体实现，最有可能是框架）。 未知（或可能更改）的产品提供了一种抽象类型：IProduct，并设置一个合同，以后在产品的任何实现中都必须实现此接口。 IProduct接口 package com.companyx; public interface IProduct { public void serve(); } 带有’a method’的工厂类需要执行 package com.companyx; public abstract class Factory { public abstract IProduct createProduct(); private void performCriticalJob(){ IProduct product = createProduct(); product.serve(); } public void executeJob(){ //some code performCriticalJob(); //some more code } } 一些具体的产品 package […]

在IoC容器中将依赖项设置为NULL并在运行时提供依赖项是不好的做法？

我有一个包含Socket和其他字段的SocketManager类。 除了Socket之外的所有字段都可以在对象图的组合期间使用DI框架注入。 我的想法是通过将Socket留空并在运行时设置它来简单地构建整个对象图。 这将允许我在代码中的某一点完成SocketManager实例化，并在整个程序中使用该实例（因为它已经通过DI框架设置为依赖）？ 这是“注入”运行时依赖项的标准方法还是不好的做法？ 抽象工厂似乎是一个坏主意，原因有两个：a）每次创建一个不同的对象b）它需要在我想要创建对象的每个地方运行时参数 让我来说明一下我的问题： SocketManager类： public class SocketManager { //i’ll only receive the socket at runtime Socket socket; //this object is available at compile-time and can be injected through the DI container InjectableObject obj; } 在我的代码[CodePosition1]的某处我会收到这样的套接字： public class SocketCreator{ SocketManager socketManager; //will be injected through DI container at startup Socket socket = […]

我应该如何根据用户选择选择应该实例化哪个具体实现？

我有一个接口Fruit有两个实现Apple和Banana 。 我想创建一个Fruit实例。 应该由用户选择具体实现应该是Apple还是Banana 。 我还没有设计用户界面，所以用户做出这个选择没有限制。 我知道有以下选择： 使用抽象工厂模式 使用reflection从给定的类名创建实例 使用reflection从给定的类对象创建实例 这些选项的优缺点是什么？ 请注意，虽然有几个类似的问题讨论了一种或另一种方法，但我没有找到一个比较。 以下是相关问题列表： 为什么Class.newInstance（）“邪恶”？ 我可以将Class.newInstance（）与构造函数参数一起使用吗？ 如何制作类的ArrayList？ Class.newInstance（）是否遵循“抽象工厂”设计模式？