zoukankan      html  css  js  c++  java
  • 设计模式——抽象工厂(Abstract Factory)

    Abstract Factory 抽象工厂模式(创建型模式):

    new的问题:实现依赖,不能应变应对“具体实例化类型”的变化。  

    解决思路:--封装变化点:哪里变化,封装哪里           -

                   -潜台词:如果没有变化,当然不需要额外的封装

    工厂模式的缘起   

         变化点在“对象创建”,因此就封装“对象创建”   

         面向接口的编程——依赖接口,而非依赖实现

          简单工厂的问题     --不能应对“不同系列对象”的变化。比如有不同风格的游戏场景——对应不同风格的道路,房屋,地道。。。。    

            ——如何解决:使用面向对象的技术来“封装”变化点

    抽象工厂模式

    动机(Motivation):在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?

    意图(Intent):提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定他们的具体类《设计模式》GOF  

    实现代码

    public abstract class Road//道路
    
    { }
    
    public abstract class Building//房屋
    
    { }
    
    public abstract class Tunnel//地道
    
    { }
    
    public abstract class Jungle//丛林
    
    { }
    
    abstract class FacilitiesFactory
    
    {   
    
    public abstract Road CreateRode();   
    
    public abstract Building CreateBuilding();   
    
    public abstract Tunnel CreateTunnel();   
    
    public abstract Jungle CreateJungle();
    
    }
    
    //客户程序
    
    class GameManager
    
    {   
    
    FacilitiesFactory  facilitiesFactory;    
    
    Road road;   
    
    Building building;   
    
    Tunnel tunnel;   
    
    Jungle jungle;   
    
    public GameManager(FacilitiesFactory  facilitiesFactory)
    
     {        
    
    this.facilitiesFactory=facilitiesFactory;  
    
    }    
    
    public void BuildGameFacilities()
    
     {     
    
        road=facilitiesFactory.CreateRoad();     
    
       building=facilitiesFactory.CreateBuilding();   
    
       tunnel=facilitiesFactory.CreateTunnel();     
    
        jungle=facilitiesFactory.CreateJungle();  
    
    }    
    
      public void Run()  
    
      {      
    
          road.Aaa();      
    
         building.Bbb();  
    
      }
    
    }
    
    //现代的风格
    
    public class ModernRoad:Road//道路
    
    { }
    
    public  class ModernBuilding:Building//房屋
    
    { }
    
    public  class ModernTunnel:Tunnel//地道
    
    { }
    
    public  class ModernJungle:Jungle//丛林
    
    { }
    
    //具体的实现
    
    public class ModernFacilitiesFactory:FacilitiesFactory
    
    {     
    
    public override Road CreateRode()  
    
    {     
    
    return new ModernRoad();  
    
    }     
    
    public override Building CreateBuilding()  
    
    {    
    
      return new ModernBuilding();  
    
    }
    
       
    
    public override Tunnel CreateTunnel()  
    
    {     
    
    return new ModernTunnel();  
    
    }
    
       public override Jungle CreateJungle()  
    
    {     
    
    return new ModernJungle();
    
      }
    
    }
    
     
    
    class APP
    
    {   
    
    GameManager g=new (new ModernFacilitiesFactory());   
    
    g.BuildGameFacilities();   
    
    g.Run();
    
    }
    View Code

    Abstract Factory模式的几个要点:

    ——如果没有应对“多系列对象构建”的需求变化,则没有必要使用Abstract Factory模式,这时候使用简单的静态工       厂完全可以。

    ——“系列对象”指的是这些对象之间有相互依赖,或作用的关系,例如游戏开发场景中的“道路”与“房屋”的依赖,“道路”与“地道”的依赖

    ——Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动 ——Abstract Factory模式经常和Factor Method模式共同组合来应对“对象创建”的需求变化

  • 相关阅读:
    git(常用命令)思维导图...
    有关gitlab的神秘操作.....version&&domain设置...
    Gitlab不小心关闭了sign-in,无法登录web的坑。。。
    聊聊CMSIS-RTOS是什么东东
    c#接口interface学习
    没有内置小鹤双拼的rime输入法就是差劲
    stm32中的型号对比——为什么很少用STM32F2,F3?
    stm32软件编程的框架及注意事项——rtos篇
    modbus-poll和modbus-slave工具的学习使用——modbus协议功能码3的解析(及欧姆龙温控器调试笔记)
    keil中error: #70: incomplete type is not allowed—解决方法
  • 原文地址:https://www.cnblogs.com/lip0121/p/3415757.html
Copyright © 2011-2022 走看看