主頁 > 軟體設計 > 我的設計模式之旅、10 抽象工廠

我的設計模式之旅、10 抽象工廠

2022-09-17 09:29:51 軟體設計

一個菜鳥的設計模式之旅,文章可能會有不對的地方,懇請大佬指出錯誤,

編程旅途是漫長遙遠的,在不同時刻有不同的感悟,本文會一直更新下去,

程式介紹

你想要購買一組運動裝備, 比如一雙鞋與一件襯衫這樣由兩種不同產品組合而成的套裝, 相信你會想去購買同一品牌的商品, 這樣商品之間能夠互相搭配起來,如果把這樣的行為轉換成代碼的話, 幫助創建此類產品組的工具就是抽象工廠,便于產品之間能夠相互匹配,

案例中 Shoe、Shirt 是兩個抽象產品,具體產品NikeShirt、NikeShoe、AdidasShirt、AdidasShoe 是對兩個抽象產品的具體分類的實作,ISportsFactory\IAbstractFactory 是抽象工廠介面,里面包含所有產品創建的抽象方法,客戶端用的都是抽象產品介面,沒有出現任何一個具體產品了字樣,達到了解耦的目的!

最大的好處是易于交換產品系列,只需要修改具體的工廠實體!

阿迪達斯工廠正在生產襯衫
阿迪達斯工廠正在生產襯衫
阿迪達斯工廠正在生產鞋子
耐克工廠正在生產襯衫
耐克工廠正在生產襯衫
耐克工廠正在生產鞋子
襯衫 品牌 阿迪達斯 大小 14	
襯衫 品牌 阿迪達斯 大小 14
襯衫 品牌 耐克 大小 12
襯衫 品牌 耐克 大小 12
鞋子 品牌 阿迪達斯 大小 10
鞋子 品牌 耐克 大小 12

程式代碼、抽象工廠模式 Golang

iShirt.go 產品介面類

package main

type IShirt interface {
	setLogo(logo string)
	setSize(size int)
	getLogo() string
	getSize() int
}

type Shirt struct {
	logo string
	size int
}

func (s *Shirt) setLogo(logo string) {
	s.logo = logo
}

func (s *Shirt) getLogo() string {
	return s.logo
}

func (s *Shirt) setSize(size int) {
	s.size = size
}

func (s *Shirt) getSize() int {
	return s.size
}

iShoe.go 產品介面類

package main

type IShoe interface {
	setLogo(logo string)
	setSize(size int)
	getLogo() string
	getSize() int
}

type Shoe struct {
	logo string
	size int
}

func (s *Shoe) setLogo(logo string) {
	s.logo = logo
}

func (s *Shoe) getLogo() string {
	return s.logo
}

func (s *Shoe) setSize(size int) {
	s.size = size
}

func (s *Shoe) getSize() int {
	return s.size
}

adidas.go 阿迪達斯工廠

package main

type Adidas struct {
}

type AdidasShirt struct {
	Shirt
}

type AdidasShoe struct {
	Shoe
}

func (a *Adidas) makeShoe() IShoe {
	return &AdidasShoe{
		Shoe: Shoe{
			logo: "adidas",
			size: 14,
		},
	}
}

func (a *Adidas) makeShirt() IShirt {
	return &AdidasShirt{
		Shirt: Shirt{
			logo: "adidas",
			size: 14,
		},
	}
}

nike.go 耐克生產工廠

package main

type NikeShirt struct {
	Shirt
}

type NikeShoe struct {
	Shoe
}

type Nike struct {
}

func (n *Nike) makeShoe() IShoe {
	return &NikeShoe{
		Shoe: Shoe{
			logo: "nike",
			size: 14,
		},
	}
}

func (n *Nike) makeShirt() IShirt {
	return &NikeShirt{
		Shirt: Shirt{
			logo: "nike",
			size: 14,
		},
	}
}

iSportsFactory.go 抽象工廠介面、簡單工廠

package main

import "fmt"

// 這個是抽象工廠介面
type ISportsFactory interface {
	makeShoe() IShoe
	makeShirt() IShirt
}

// 這里是簡單工廠,根據brand生成特定工廠實體
func GetSportsFactory(brand string) (ISportsFactory, error) {
	if brand == "adidas" {
		return &Adidas{}, nil
	}

	if brand == "nike" {
		return &Nike{}, nil
	}

	return nil, fmt.Errorf("wrong brand type passed")
}

main.go

package main

import "fmt"

func main() {
	adidasFactory, _ := GetSportsFactory("adidas")
	nikeFactory, _ := GetSportsFactory("nike")

	nikeShoe := nikeFactory.makeShoe()
	nikeShirt := nikeFactory.makeShirt()

	adidasShoe := adidasFactory.makeShoe()
	adidasShirt := adidasFactory.makeShirt()

	printShoeDetails(nikeShoe)
	printShirtDetails(nikeShirt)

	printShoeDetails(adidasShoe)
	printShirtDetails(adidasShirt)
}

func printShoeDetails(s IShoe) {
	fmt.Printf("Logo: %s", s.getLogo())
	fmt.Println()
	fmt.Printf("Size: %d", s.getSize())
	fmt.Println()
}

func printShirtDetails(s IShirt) {
	fmt.Printf("Logo: %s", s.getLogo())
	fmt.Println()
	fmt.Printf("Size: %d", s.getSize())
	fmt.Println()
}

Console 輸出

Logo: nike
Size: 14
Logo: nike
Size: 14
Logo: adidas
Size: 14
Logo: adidas
Size: 14

程式代碼、抽象工廠模式 C#

Shirt.cs 產品類

namespace 抽象工廠;

public abstract class Shirt
{
    public string Logo { get; private set; }
    public int Size { get; private set; }

    protected Shirt(string logo, int size)
    {
        Logo = logo;
        Size = size;
    }
}

public class AdidasShirt : Shirt
{
    public AdidasShirt(int size) : base("阿迪達斯", size)
    {
    }
}

public class NikeShirt : Shirt
{
    public NikeShirt(int size) : base("耐克", size)
    {
    }
}

Shoe.cs 產品類

namespace 抽象工廠;

public abstract class Shoe
{
    public string Logo { get; private set; }
    public int Size { get; private set; }

    protected Shoe(string logo, int size)
    {
        Logo = logo;
        Size = size;
    }
}

public class AdidasShoe : Shoe
{
    public AdidasShoe(int size) : base("阿迪達斯", size)
    {
    }
}

public class NikeShoe : Shoe
{
    public NikeShoe(int size) : base("耐克", size)
    {
    }
}

AbstractFactory.cs 抽象工廠類

namespace 抽象工廠;

public interface IAbstractFactory
{
    Shoe createShoe(int size);
    Shirt createShirt(int size);
}

public class AdidasFactory : IAbstractFactory
{
    public Shoe createShoe(int size)
    {
        Console.WriteLine("阿迪達斯工廠正在生產鞋子");
        return new AdidasShoe(size);
    }

    public Shirt createShirt(int size)
    {
        Console.WriteLine("阿迪達斯工廠正在生產襯衫");
        return new AdidasShirt(size);
    }
}
public class NikeFactory : IAbstractFactory
{
    public Shoe createShoe(int size)
    {
        Console.WriteLine("耐克工廠正在生產鞋子");
        return new NikeShoe(size);
    }

    public Shirt createShirt(int size)
    {
        Console.WriteLine("耐克工廠正在生產襯衫");
        return new NikeShirt(size);
    }
}

// 一個類用于存放工廠單例物件,使用餓漢式單例類
public sealed class AbstractFactorySingleton
{
    public static readonly IAbstractFactory Adidas = new AdidasFactory();
    public static readonly IAbstractFactory Nike = new NikeFactory();
    
    // 常規寫法應該提供一個全域訪問點,這里為了方便省略
}

Program.cs

// See https://aka.ms/new-console-template for more information

using 抽象工廠;

// 產品的庫存
List<Shoe> shoes = new();
List<Shirt> shirts = new();

IAbstractFactory factory = AbstractFactorySingleton.Adidas;
Shirt s1 = factory.createShirt(14);
Shirt s2 = factory.createShirt(14);
shirts.Add(s1);
shirts.Add(s2);
Shoe s3 = factory.createShoe(10);
shoes.Add(s3);

factory = AbstractFactorySingleton.Nike;
s1 = factory.createShirt(12);
s2 = factory.createShirt(12);
shirts.Add(s1);
shirts.Add(s2);
s3 = factory.createShoe(12);
shoes.Add(s3);

foreach (var shirt in shirts)
{
    Console.WriteLine($"襯衫 品牌 {shirt.Logo} 大小 {shirt.Size}");
}

foreach (var shoe in shoes)
{
    Console.WriteLine($"鞋子 品牌 {shoe.Logo} 大小 {shoe.Size}");
}

Console 輸出

阿迪達斯工廠正在生產襯衫
阿迪達斯工廠正在生產襯衫
阿迪達斯工廠正在生產鞋子
耐克工廠正在生產襯衫
耐克工廠正在生產襯衫
耐克工廠正在生產鞋子
襯衫 品牌 阿迪達斯 大小 14
襯衫 品牌 阿迪達斯 大小 14
襯衫 品牌 耐克 大小 12
襯衫 品牌 耐克 大小 12
鞋子 品牌 阿迪達斯 大小 10
鞋子 品牌 耐克 大小 12

思考總結

注:把不同的產品變體、產品族理解為不同的產品系列,如現代風格家具類、北約風格家具類,

什么是抽象工廠模式

image-20220916160544800

抽象工廠模式:創建型設計模式,提供一個創建一系列相關或相互依賴物件的介面,而無需指定它們具體的類,

何時使用:系統的產品有多于一個的產品族,而系統只消費其中某一族的產品,

如何解決:

  • 為系列中的每件產品明確宣告介面,確保所有產品變體都繼承這些介面,
  • 我們需要宣告抽象工廠——包含系列中所有產品構造方法的介面,
  • 這些方法必須回傳抽象產品型別,每個工廠類都只能回傳特定類別的產品,

關鍵代碼:在一個工廠里聚合多個同類產品,

應用場景:

  • 代碼需要與多個不同系列的相關產品互動,但是由于無法提前獲取相關資訊,或出于對未來擴展性的考慮,
  • 如果你有一個基于一組抽象方法的類,且其主要功能因此變 得不明確,那么在這種情況下可以考慮使用抽象工廠模式,
  • 設計良好的程式中,每個類僅負責一件事,如果一個類與多種型別產品互動,就可以考慮將工廠方法抽取到獨立的工廠類或具備完整功能的抽象工廠類

實作步驟:

  1. 以不同的產品型別與產品變體為維度繪制矩陣,
  2. 為所有產品宣告抽象產品介面,然后讓所有具體產品類實作這些介面,
  3. 宣告抽象工廠介面,并且在介面中為所有抽象產品提供一組構建方法,
  4. 每種產品變體實作一個具體工廠類
  5. 在應用程式中開發初始化代碼,該代碼根據應用程式配置或當前環境,對特定具體工廠類進行初始化,然后將該工廠對 象傳遞給所有需要創建產品的類,
  6. 找出代碼中所有對產品建構式的直接呼叫,將其替換為對工廠物件中相應構建方法的呼叫,

優點:

  • 當一個產品族中的多個物件被設計成一起作業時,它能保證客戶端始終只使用同一個產品族中的物件,
  • 確保同一工廠生成的產品相互匹配
  • 避免客戶端和具體產品代碼的耦合
  • 單一職責原則,你可以將產品生成代碼抽取到同一位置,使得代碼易于維護,
  • 開閉原則,向應用程式中引入新產品變體時,你無需修改客戶端代碼,

缺點:

  • 產品族擴展非常困難,要增加一個系列的某一產品,既要在介面里加代碼,又要在具體類里面加代碼,

使用場景:

  • QQ 換皮膚,一整套一起換,
  • 生成不同作業系統的程式,
  • 跨平臺UI元素

注意事項:

  • 產品系列難擴展,具體產品易擴展,
  • 一般情況下,應用程式會在初始化階段創建具體工廠物件,而在此之前,應用程式必須根據組態檔或環境設定選擇工廠類別,

與其他模式的關系:

  • 在許多設計作業的初期都會使用工廠方法(較為簡單,而且可以更方便地通過子類進行定制),隨后演化為使用抽象工 廠、原型或生成器(更靈活但更加復雜),
  • 生成器(建造者模式)重點關注如何分步生成復雜物件,抽象工廠專門用于生產一系列相關物件,抽象工廠會馬上回傳產品,生成器則允許你在獲取產品前執行一些額外構造步驟,
  • 抽象工廠模式通常基于一組工廠方法,但你也可以使用原型模式來生成這些類的方法,
  • 當只需對客戶端代碼隱藏子系統創建物件的方式時,你可以 使用抽象工廠來代替外觀,
  • 你可以將抽象工廠和橋接搭配使用,如果由橋接定義的抽象只能與特定實作合作,這一模式搭配就非常有用,在這種情 況下,抽象工廠可以對這些關系進行封裝,并且對客戶端代 碼隱藏其復雜性,
  • 抽象工廠、生成器和原型都可以用單例來實作,

餓漢式單例模式

在c#的例子中使用了餓漢式單例模式來生成各個工廠實體,這是C#與公告語言運行庫提供的一種靜態初始化方法,這種方法不需要開發人員顯式地撰寫執行緒安全代碼,即可解決多執行緒環境下它是不安全的問題,這種靜態初始化的方式是在自己被加載時就將自己實體化,所以被稱為懶漢式單例類,

更多參考:我的設計模式之旅、02 單例模式 - 小能日記 - 博客園

參考資料

  • 《Go語言核心編程》李文塔
  • 《Go語言高級編程》柴樹彬、曹春輝
  • 《大話設計模式》程杰
  • 《深入設計模式》亞歷山大·什韋茨
  • 菜鳥教程

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/508895.html

標籤:其他

上一篇:微服務設計(二)---springCloud基礎及注冊中心

下一篇:如何優化好UITableView,值得思考

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more