工厂设计模式

当在实现通用协议或共享通用基类的类之间进行选择时，将使用工厂方法模式。 这种模式允许实现子类提供专业化，而无需依赖它们的组件知道这些类的任何详细信息以及它们之间的关系

什么是工厂设计模式？

工厂方法模式选择一种实现类来满足调用组件的请求，而无需组件知道有关实现类或它们之间的相互关系的任何信息。

有什么好处？

这种模式巩固了决定选择哪个实现类的逻辑，并防止其在整个应用程序中扩散。 这也意味着调用组件仅依赖于顶层协议或基类，而不需要有关实现类或选择它们的过程的任何知识。

什么时候应该使用这种模式？

当您有几个实现通用协议或从同一基类派生的类时，请使用此模式。

什么时候应该避免这种模式？

在没有通用协议或共享基类的情况下，请勿使用此模式，因为此模式通过使调用组件仅依赖单一类型来起作用

让我们看一下示例：

 协议JobContactProtocol { 
  func sendRequestResumeEmail（） 
  } 
  struct Contact { 
 变量名称：字符串 
  var job：工作 
 初始化（名称：字符串，工作：职位）{ 
  self.name =名称 
  self.job =工作 
  } 
 枚举Job { 
 案例IOS 
 案例Android 
  } 
  } 

  IOSJob类：JobContactProtocol { 
  var联系人：联系人 
  func sendRequestResumeEmail（）{ 
 打印（“亲爱的\（contact.name）您是ios候选人”） 
  } 
 初始化（联系人：联系人）{ 
  self.contact =联系人 
  } 
  } 

  AndroidJob类：JobContactProtocol { 
  var联系人：联系人 
  func sendRequestResumeEmail（）{ 
 打印（“亲爱的\（contact.name）您是Android的候选人”） 
  } 
 初始化（联系人：联系人）{ 
  self.contact =联系人 
  } 
  } 

 结构jobContactorFactory { 
 静态函数getJobSeeker（contact：Contact）-> JobContactProtocol { 
 开关（触点。工作）{ 
 案例.IOS： 
 返回IOSJob（联系人） 
 案例.Android： 
 返回AndroidJob（联系人） 
  } 
  } 
  } 

  var联系人= [Contact]（） 
  contact.append（Contact（name：“ J Rob”，job：.IOS）） 
  contact.append（Contact（name：“ J Rob”，工作：.Android） 

 用于联系人中的联系人{ 
 让客户= jobContactorFactory.getJobSeeker（联系人：联系人） 
 打印（client.sendRequestResumeEmail（）） 
  } 

上面的代码包含一个名为JobContactProtocol的协议和两个一致的类：IOSJob和AndroidJob。

工厂方法模式解决了当存在多个符合协议的类并且您需要选择应实例化的类时出现的问题。 您可以在上面的代码中看到工作原理，其中jobContactorFactory.getJobSeeker（）方法根据Job的类型选择并实例化符合JobContactProtocol的类之一。