设计模式 工厂方法

如您所知，“工厂方法模式”或俗称“工厂设计模式”是“创意设计模式”类别下的一种设计模式。 模式背后的基本原理是，在运行时，我们根据传递的参数获得类似类型的对象。 关于这种模式的文章很多，开发人员可以通过各种方式来实现它。 在本文中，我将向您展示如何创建一种更好且最有效的工厂设计模式设计方法。

技术性

正如我已经告诉您的那样，在工厂设计的情况下，我们将在运行时获得一个类似类型的对象，这样，对象的基础实现将位于屏幕后面。 让我们考虑一个简单的方法。 让我们考虑一个可以是Male或Female的Person对象。 在运行时，我们仅应考虑人的行为，而不应考虑性别。 作为传统方法，我们创建一个Person接口，并创建两个实现类，例如MalePerson和FemalePerson。 基于运行时性别数据，我们传递到Factory类的Factory方法，在此我们确定性别类型是Male还是Female，因此我们创建特定类的实例并返回引用类型对象。 这种方法听起来不错，我们在许多开发活动中都采用了这种方法。 在细粒度的多线程应用程序中，我们可以确保它是有效的方法吗？ 表现如何呢？ 还有其他方法吗？ 是的，我们愿意。

让我们考虑另一个实时示例。 考虑一个组织中的某个情况，该雇员可以担任CEO，CTO，CFO，开发人员，测试工程师，人力资源，人员，安全性等。如果您想根据组织了解雇员的角色，您将怎么办？ 您将如何创建更好的工厂设计，以便我们可以轻松地找到角色并且不应有性能损失？ 您是否会通过提供多个if子句来采用相同的传统方法？ 您可以提出一个论点，我们应该使用切换条件。 很好……让我们看看传统方法，然后让我们测量时间。

让我们以传统方式采用工厂设计。

package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public interface Roles
{public String getRole();
}

上面的接口用作一种类型，因为组织中可以有各种类型的角色。 它有一个称为“ getRole（）”的方法，用于指定员工角色的描述。

让我们为组织中CEO，CTO和CFO的合适角色设计实现类。

package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public class CEORoles implements Roles
{public String getRole() {return "CEO is the supreme head of the company";}
}package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public class CFORoles implements Roles
{@Overridepublic String getRole() {return "CFO is the finance head of a company";}
}package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public class CTORoles implements Roles
{@Overridepublic String getRole() {return "CTO is the technology decision maker of a company";}
}

现在，我们必须考虑从中动态创建对象的工厂。 让我们看下面的代码。

package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public abstract class EmployeeFactory
{public static Roles getRole( String type ){Roles roles = null;if( type.equals("cfo"))roles = new CFORoles();else if( type.equals("cto"))roles = new CTORoles();else if( type.equals("ceo"))roles = new CEORoles();return roles;}
}

让我们编写一个简单的测试工具类来验证设计。

package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public class TestTraditionalFactoryDesign
{public static void main(String[] args) {String type = "ceo";long startTime = System.nanoTime();String role = EmployeeFactory.getRole(type).getRole();System.out.println("Role ::: "+role);long endTime = System.nanoTime();System.out.println("Time difference ::: "+(endTime-startTime)+" nano seconds");}}

如果运行上述程序，则以下是我系统的输出。

仅供参考，我的系统具有4 GB RAM和I5处理器。

Role ::: CEO is the supreme head of the company
Time difference ::: 3477574 nano seconds

上面的设计似乎是正确的，但是性能呢？ 您可能会说这没关系，因为它以纳秒为单位。 当然，您的应用程序是否很小并不重要，但是对于大型企业应用程序而言，这确实很重要。 如果您是优秀的程序员或开发人员，则不能忽略性能问题，尤其是在产品开发的情况下，它们可能是市场上的同类产品。

为了解决上述问题，让我们尝试另一种工厂设计方法，即工厂类可能有所更改。

让我们看下面的代码。

package com.ddlab.rnd.patterns;
/*** @author Debadatta Mishra(PIKU)**/
public enum EmployeeType
{CEO("CEO") {@Overridepublic Roles getRoles() {return new CEORoles();}},CTO("CTO"){@Overridepublic Roles getRoles() {return new CTORoles();}},CFO("CFO"){@Overridepublic Roles getRoles() {return new CFORoles();}};private EmployeeType( String type ){this.type = type;}private String type;public abstract Roles getRoles();public String getType() {return type;}@Overridepublic String toString() {return "TYPE CODE -> "+type;}
}

下面给出了测试线束类。

package com.ddlab.rnd.patterns;
import java.util.HashMap;
import java.util.Map;
/*** @author Debadatta Mishra(PIKU)**/
public class TestFactoryDesign
{static Map<String,EmployeeType> typeMap = new HashMap<String,EmployeeType>();static{typeMap.put("cto", EmployeeType.CTO);typeMap.put("ceo", EmployeeType.CEO);typeMap.put("cfo", EmployeeType.CFO);}public static void main(String[] args){String empType = "ceo";try {long startTime = System.nanoTime();String whatIstheRole = typeMap.get(empType).getRoles().getRole();System.out.println("Role of the Employee :::"+whatIstheRole);long endTime = System.nanoTime();System.out.println("Time difference ::: "+(endTime-startTime)+" nano seconds");}catch (NullPointerException e) {System.out.println("No such Role is found");e.printStackTrace();}}
}

如果运行上面的代码，您将获得以下输出。

Role ::: CEO is the supreme head of the company
Time difference ::: 1049108 nano seconds

那时间呢 让我们在传统方法和现代方法之间进行比较。

您能考虑一下时差吗，它仅比传统方法快3倍。

那么哪个更好呢？ 当然，使用枚举的现代方法更好。 除了枚举，我还使用Map来维护雇员类型及其对应的枚举的列表。 在这种情况下，就循环复杂性而言，无需使用if子句可能会影响我们的性能。 使用以上1049108纳秒的方法总是更好。 您可以将ConcurrentMap用于多线程应用程序。

结论

希望您喜欢我关于工厂设计模式的文章。 如果有任何澄清，您可以与我联系debadatta.mishra@gmail.com 。

翻译自: https://www.javacodegeeks.com/2013/06/factory-design-pattern-an-effective-approach.html

设计模式 工厂方法