面向对象设计模式2:Abstract Factory 模式

本文深入探讨了抽象工厂模式的设计理念,旨在解决软件系统中一系列相互依赖对象的创建问题,通过封装变化点,避免客户程序与具体对象创建工作的紧耦合。文章详细解释了简单工厂模式的局限性,并介绍了抽象工厂模式如何应对新系列对象创建的需求变动。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

new 的问题
//创建一个Road对象

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

解决思路:
--封装变化点--哪里变化,封装哪里
--潜台词:如果没有变化,当然不需要额外的封装!

工厂模式的缘起
变化点在"对象创建",因此就封装"对象创建"
面向接口编程--依赖接口,而非依赖实现
最简单的解决方法:
class RoadFactory
{
 public static Road CreateRoad()
 {
  return new Road();
 }
}

//创建一个Road对象
Road road=roadFactory.CreateRoad();


简单工厂的问题:
不能应对"不同系列对象"的变化,比如有不同风格的游戏场景--对应不同风

格的道路,房屋,地道...

使用面向对象的技术来"封装"变化点.


动机(Motivation)
在软件系统中,经常面临着"一系列相互依赖的对象"的创建工作;同时由于

需求的变化,往往更多系列对象的创建工作。

如何应对这种变化?如何绕过常规的对象创建方法(new)
提供一种"封装机制"来避免客户程序和这种"多系列具体对象创建工作"的
紧耦合?

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

//道路
public abstract class Road
{
}
//房屋
public abstract class Building
{
}
//地道
public abstract class Tunnel
{
}
//丛林
public abstract class Jengle
{
}
abstract class FacilitiesFactory
{
   public abstract Road CreateRoad();
   public abstract Building CreateBuilding();
   public abstract Tunnel CreateTunnel();
   public abstract Jungle CreateJungle();
}

class GameManager
{
FacilitiesFactory facilitiesFactory;
 public GameManager(FacilitiesFactory facilitiesFactory)
 {
   this.facilitiesFactory=facilitiesFactory;
 }
 public void BulidGameFacilities()
 {
   Road road=roadFactory.CreateBuiliding();

 }
}
Abstract Factory 模式的几个要点
如果没有应对"多系列对象构建"的需求变化,则没有必要使用Abstract

Factory 模式,这时候使用简单的静态工厂完全可以。
“系列对象”指的是这些对象之间有相互依赖或作用的关系.例如游工开发场

景中的"道路"与"房屋"的依赖,“道路”与“地道”的依赖。

Abstract Factory 模式主要在于应对"新系列"的需求变动。
其缺点在于难以应对“新对象”的需求变动。

Abstract Factory 模式经常和Factory Method模式共同组合来应对“对象

创建”的需法变化。

 

 

 

转载于:https://www.cnblogs.com/dotnetjun/archive/2011/03/17/1987440.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值