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

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

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博客上的工厂设计模式 。