工厂设计模式案例研究

我有一份工作来检查我们的项目代码质量。 如果我在项目中发现任何障碍，必须将其报告给我的团队负责人。 我发现了很多漏洞，我认为可以在博客上进行讨论。 不是嘲笑作者，而是一起学习和改进自己。

像这段代码一样，这是我在我们的代码中找到的部分。

public ContactInfoBean(final Reseller resellerInfo) {

        switch(resellerInfo.getType()) {

            case PROGRAM_CONTACT:

                readExecutiveInfo(resellerInfo);

                break;

            case FILE_CONTACT:

                readOperationalInfo(resellerInfo);

                break;

            default:

                break;

        }

    }

该代码可以正常工作，并且可以很好地完成工作。 但是使用此代码样式会出现一些问题。 与往常一样，这一类别将随着业务的变化而增长，一个较大的类别是维持这种状况的“商户”。 最有可能具有多个目的的这一类称为低内聚性。

更好的面向对象的方法

对于上述情况，更好的方法是使用“工厂设计模式”。 我们可以让READER的工厂根据其类型生成每个实例。 扩展实例类型会更容易，因为我们只需要创建一个新类并在Factory类中进行一些修改即可。 呼叫者类别不会增长，并且将保持当前状态。

public interface InfoReader {

 public void readInfo();

}
public class ExecutiveReader implements InfoReader {

 public void readInfo() {

  // override

 }

}
public class OperationalReader implements InfoReader {

 public void readInfo() {

  // override

 }

}

和工厂

public class InfoReaderFactory {

 private static final int PROGRAM_CONTACT = 1;

 private static final int FILE_CONTACT = 2;

 public static InfoReader getInstance(Reseller resellerInfo) {

  InfoReader instance = null;

  switch (resellerInfo.getType()) {

  case PROGRAM_CONTACT:

   instance = new ExecutiveReader();

   break;

  case FILE_CONTACT:

   instance = new OperationalReader();

   break;

  default:

   throw new IllegalArgumentException('Unknown Reseller');

  }

  return instance;

 }

}

现在，来电者

InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);

reader.readInfo();

好处

使用Factory Design Pattern处理这种情况，我们可以获得一些好处，

• 为一个任务指定一个类别意味着更容易维护，因为一个类别仅出于一种目的（模块化/高内聚性）。 即：Operational Reader仅用于操作目的而无其他目的读取数据。 以防万一，在将来的一天中，我们需要另一台Reader（例如：NonOperationalReader）。 我们只需要创建一个扩展（或实现）InfoReader类的新类，然后就可以覆盖我们自己的readInfo（）函数。 此Caller类不会产生任何影响。 我们只需要在Factory代码中进行一些修改即可。

public class InfoReaderFactory {

 private static final int PROGRAM_CONTACT = 1;

 private static final int FILE_CONTACT = 2;

 private static final int NEW_READER = 3;

 public static InfoReader getInstance(ResellerInfo resellerInfo) {

  InfoReader instance = null;

  switch (resellerInfo.getType()) {

  case PROGRAM_CONTACT:

   instance = new ExecutiveReader();

   break;

  case FILE_CONTACT:

   instance = new OperationalReader();

   break;

  case NEW_READER:

   instance = new NonOperationalReader();

   break;

  default:

   throw new IllegalArgumentException('Unknown Reseller');

  }

  return instance;

 }

}

• 父级组件的更高可重用性（继承性）：由于我们具有父类（InfoReader），因此我们可以将公共函数和事物放入此InfoReader类中，以后所有派生类（ExecutiveReader和OperationalReader）都可以重用InfoReader的公共组件。 避免代码冗余，并可以最大程度地减少编码时间。 即使这取决于您如何执行代码，也无法保证。

但是，它运行得很好，我们应该改变它吗？

显然，答案是否定的。 这只是案例研究，仅供您进一步的经验和知识。 OOP很好，可以在任何适用的地方进行。 但是最重​​要的是，如果它正在运行，请不要更改它。 如果您为了追求某种OOP方法而破坏了整个工作代码，那将是荒谬的。 也不要天真，没有人可以实现完美的代码。 最重要的是我们知道什么是更好的方法。

参考： 案例研究： JCG合作伙伴 Ronald Djunaedi在Naming Exception博客上的工厂设计模式 。

翻译自: https://www.javacodegeeks.com/2012/10/factory-design-pattern-case-study.html