网站网址前的小图标怎么做,公司产品设计部门和销售,大气企业网站欣赏,电影网站如何做长尾关键词工厂模式个人案例我有一份工作来检查我们的项目代码质量。 如果我在项目中发现任何障碍#xff0c;必须将其报告给我的团队负责人。 我发现了很多漏洞#xff0c;我认为可以在博客上进行讨论。 不是嘲笑作者#xff0c;而是一起学习和改进自己。 像这段代码一样#xff0c;… 工厂模式个人案例 我有一份工作来检查我们的项目代码质量。 如果我在项目中发现任何障碍必须将其报告给我的团队负责人。 我发现了很多漏洞我认为可以在博客上进行讨论。 不是嘲笑作者而是一起学习和改进自己。 像这段代码一样这是我在我们的代码中找到的部分。 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工厂模式个人案例
