设计模式 工厂方法
如您所知,“工厂方法模式”或俗称“工厂设计模式”是“创意设计模式”类别下的一种设计模式。 模式背后的基本原理是,在运行时,我们根据传递的参数获得类似类型的对象。 关于这种模式的文章很多,开发人员可以通过各种方式来实现它。 在本文中,我将向您展示如何创建一种更好且最有效的工厂设计模式设计方法。
技术性
正如我已经告诉您的那样,在工厂设计的情况下,我们将在运行时获得一个类似类型的对象,这样,对象的基础实现将位于屏幕后面。 让我们考虑一个简单的方法。 让我们考虑一个可以是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
那时间呢 让我们在传统方法和现代方法之间进行比较。
传统方法 | 3477574纳秒 |
现代方法(使用枚举和映射) | 1049108纳秒 |
您能考虑一下时差吗,它仅比传统方法快3倍。
那么哪个更好呢? 当然,使用枚举的现代方法更好。 除了枚举,我还使用Map来维护雇员类型及其对应的枚举的列表。 在这种情况下,就循环复杂性而言,无需使用if子句可能会影响我们的性能。 使用以上1049108纳秒的方法总是更好。 您可以将ConcurrentMap用于多线程应用程序。
结论
希望您喜欢我关于工厂设计模式的文章。 如果有任何澄清,您可以与我联系debadatta.mishra@gmail.com 。
翻译自: https://www.javacodegeeks.com/2013/06/factory-design-pattern-an-effective-approach.html
设计模式 工厂方法