工厂类不支持 SOLID 原理

Question

我有如下代码

 public interface ICar
{
    void Created();
}

public class BigCar : ICar
{
    public void Created()
    {

    }
}

public class SmallCar : ICar
{
    public void Created()
    {

    }
}


public class LuxaryCar : ICar
{
    public void Created()
    {

    }
}

public class CarFactory
{
    public ICar CreateCar(int carType)
    {
        switch (carType)
        {
            case 0:
                return new BigCar();
            case 1:
                return new SmallCar();
            case 2:
                return new LuxaryCar();
            default:
                break;
        }
        return null;
    }
}

在这段代码中，我有一个返回具体实例的工厂。但是每次我需要有一个新的 ICar 接口实现时，我都必须更改 CarFactory 的 CreateCar() 方法。看来我不支持 SOLID 原则的开放封闭原则。请建议是否有更好的方法来处理这种情况。

Answer 1

您可能希望使其可配置，如下所示：

void Main()
{
    // configurable array
    var factories = new ICarFactory[] { new BigCarFactory() };

    // create factory
    var realfactory = new CarFactory(factories);

    // create car
    var car = realfactory.CreateCar(0);
}

public class CarFactory : ICarFactory
{
    private ICarFactory[] _factories;

    public CarFactory (ICarFactory[] factories)
    {
        _factories = factories;

    }   
    public ICar CreateCar(int carType)
    {
        return _factories.Where(x=>x.SupportCar(carType)).First().CreateCar(carType);
    }

    public bool SupportCar(int type) => _factories.Any(x=>x.SupportCar(type));
}

public interface ICarFactory
{
    ICar CreateCar(int type);
    bool SupportCar(int type);
}

public class BigCarFactory : ICarFactory
{
    public ICar CreateCar(int carType)
    {
        if(carType != 0) throw new NotSupportedException();
        return new BigCar();
    }

    public bool SupportCar(int type) => type == 0;
}


public interface ICar
{
    void Created();
}

public class BigCar : ICar
{
    public void Created()
    {

    }
}

public class SmallCar : ICar
{
    public void Created()
    {

    }
}


public class LuxaryCar : ICar
{
    public void Created()
    {

    }
}

Answer 2

confusion around the open/closed principle, and what it should mean to your code很多。

事实就在这里，你很好。移动到配置文件只是将代码与数据分开并隐藏意图，这会导致问题。

答案？这取决于。务实。 “只是他妈的硬编码它”。通过保留你的 switch 语句来明确工厂的意图。保持数据和意图紧密结合，就像这里一样。确保首先为缺少的 switch 案例编写测试，并始终包含 default 案例（即使它只是引发异常）。

你的工厂只有一个改变的理由，而且只做一项工作。你现在的设计就可以了。如果您发现自己经常回来添加新案例，那么也许您会想考虑其他方法（配置文件不是答案，它只是将编辑从代码文件移至配置文件）并重构您的解决方案。不断增加的 switch 语句并不好，但与其想办法以不同的方式做到这一点，不如花精力从一开始就解决这个问题。请参阅下面的附录：

附录

另一种解决方法是不要让多个类实现相同的接口。想想其他 SOLID 原则。也许还有另一个一致性或功能边界而不是“汽车类型”？也许有一些功能组可以在更多、特定、细粒度的接口中指定，然后也许你使用 DI 在你需要的地方注入实现，而不是一开始就必须使用工厂（其中，让我们面对现实吧，反正只是一个捏造的构造函数）。另请参阅：“偏好组合胜于继承”。

Answer 3

看来我的cmets被误解了，所以我们开始吧：

假设我们有一些简单的配置文件：

<config>
  <MyType key="1" type="My.Namespace.Ferrari"/>
  <MyType key="2" type="My.Namespace.Fiat"/>
</config>

现在您可以从该配置中读取并根据类型信息创建您的实例：

ICar CreateCar(int carType)
{
    foreach(var typeInfo in myConfig)
    {
        if(typeInfo.Key == carType) return Activator.CreateInstance(Type.GetType(typeInfo.type));
    }
}

现在只需调用myFactory.CreateCare(2) 即可获取Fiat 的实例。

这肯定假设您已经反序列化了您的配置（例如，使用 Linq2Xml 或使用 XmlSerializer）并且包含这些类型的程序集已经在运行时加载。如果这不适用，您应该先致电Assembly.Load。

现在您的工厂仍然需要做的就是读取配置文件，最终加载程序集并构建一个缓存键和类型的字典以稍微提高性能。

依赖外部文件的好处是您不必重新发布整个应用程序，而只需重新发布那些实际更改的部分。

编辑：如果您的类型没有默认构造函数并且您必须提供参数，事情可能会变得复杂。然而，为了简单起见，我们假设我们有一个默认构造函数。

Answer 4

我认为 Vlad 在 cmets 中的建议是更好的方法，我在后续评论中对此进行了更具体的说明，但我将在下面详细说明。与tym32167's answer 不同，此方法不会通过将type 参数从应用程序本身发送到ICarFactory 类型，将您的库与使用它的特定应用程序耦合。

换句话说，我认为 tym32167 的回答不会让你的类在每次需要添加新实现时都“关闭以供修改”。

---

汽车

public interface ICar {
    string Name { get; }
}

class BigCar : ICar {
    string Name {
        get { return "Big Car"; }
    }
}

class SmallCar : ICar {
    string Name {
        get { return "Small Car"; }
    }
}

工厂

public interface ICarFactory {
    ICar CreateCar();
}

public class BigCarFactory : ICarFactory {
    ICar CreateCar() { return new BigCar (); }
}

public class SmallCarFactory : ICarFactory {
    ICar CreateCar() { return new SmallCar (); }
}

请注意，它们不会受到“控制耦合”的影响，即它们不依赖外部“魔法”值来确定工厂的内部控制流程。换句话说，它们不是ICar CreateCar(int type);，工厂只是ICar CreateCar();。工厂不应通过 type 参数与您的特定应用程序耦合，该参数具有特定于应用程序的含义。

把它们放在一起

现在，在您的客户端应用程序中的一些任意方法中，您拥有汽车创建逻辑，即 在您的库之外（例如读取您的配置文件或其他内容），您可以执行类似的操作：

public List<ICar> CreateCars() {
    // organize your factories based on whatever value you want for 'type'
    ICarFactory[] factories = { new BigCarFactory(), new SmallCarFactory() };
    List<ICar> carsList = new List<>();

    while (/* more config to read */ ) {
        int type = // read type from config, etc.
        carsList.Add(factories[type].CreateCar());
    }

    return carsList;
}

现在，每次添加新的ICar 实现时，都会创建一个关联的ICarFactory 实现，这显然很容易做到，并且在任何汽车@987654333 中的ICarFactory[] factories 数组中添加一个新工厂@你想要的位置，type 知识保留在你的特定应用程序中，与你的汽车/工厂库分离。

---

与其他回复相比，为什么我的提案SOLID？

1. S：这些工厂有 1 个职责：创建他们的汽车实现；其他提案增加了弄清楚type 含义的责任
2. O：您的ICar 和ICarFactory 可以通过添加新的实现来扩展，但在这样做时不需要修改现有的。
3. L：我们已经在这样做了，因为我们正在返回 ICar 对象，所以无论实现是 BigCar 还是 SmallCar 或其他什么都没有关系。李>
4. 我：我们在这里通过保持接口和类简单来做到这一点；其他建议通过 type 参数将您的库与您的应用耦合，该参数具有应用特定的含义
5. D：在这种特殊情况下，库类并不完全需要依赖注入的外部信息。