前言：筆者在最開始寫程式的時候經常會遇到一種情況，例如更改乙個字段、或者新增一種小功能，就要把原來寫過的東西幾乎廢棄掉，或者更改大量以前寫過的**。又或者自己寫的東西時間久了再去回顧，完全找不到到時為什麼這麼寫的頭緒，如果遇到了bug更是無法快速定位在**小範圍出現的問題。如果你也經常遇到這種問題，就說明你現階段非常需要學習下設計模式了。
在網上經常說的設計模式有23種，也有一些更多的設計模式，無非也是從這些設計模式中變種而來。如果讓筆者來形容什麼是設計模式，我認為設計模式是：一種思想，一種模式，一種套路，一種解決問題的高效策略。
舉個生活中的列子：你需要從家去公園，雖然都是從a點到b點，但目的是著急取東西，你會用代步工具快速到達，但如果僅僅是打發時間，完全可以散步去。用代步工具和散步本身沒有絕對的對錯，只是根據當時的需求採取的策略。設計模式這種思想，就是根據你當時的需求給你提供最高效的策略。
在上次的【話大】設計模式之簡單工廠筆者有提到過還有跟多優化的地方，下面筆者跟大家聊一聊簡單工程的優化版 ------【工廠方法】
現在我們的策劃大佬來了新的需求，說海瀾我們現在需要增加「產品」，原來的「產品」不好，全部去掉，換成10個新的，而且每個「產品」在生產之前要有一些檢測機制。按照簡單工廠的套路，我們知道，在工廠類switch中把原來的產品的case刪掉，然後新增10個新的case，然後在對應的語句塊中新增需要的檢測機制。設計模式之物件導向七大原則我們知道，這種方式違背了單一原則和開閉原則，違背單一原則是因為過多的涉及其他產品的生產，雖然都是生產產品。違背開閉原則是因為，在乙個工廠類中有許多產品的產生，不管是增加產品或者是對單一產品的修改都有可能造成其他產品的干擾。所以我要對他們進行再次的分離，再次的封裝。
public inte***ce iproduct{}
public class computer : iproduct{}
public class iphone : iproduct{}
public class mac : iproduct{}
public class ipad : iproduct{}
public inte***ce ifactory
public class factorycomputer : ifactory
}public class factoryiphone : ifactory
}public class factorymac : ifactory
}public class factoryipad : ifactory
}
public void examplefactorymethod()
現在直觀的看，**量增加了，而且對產品的選擇由下端工廠類又轉交給上端業務邏輯層了。但筆者認為對於版本迭代來說，這種犧牲是值得的，理由有一下幾點
為什麼說更符合開閉原則呢？因為如果在在版本迭代的時候，在原有產品的基礎上新增檢測等機制，可以用如下寫法，完全不會涉及到原來類的原始碼。
工廠方法(factory method),定義了乙個用於建立物件的介面，讓子類決定例項化哪乙個類。工廠方法使乙個類的例項化延遲到其子類。
筆者說過，運用哪種設計模式沒有絕對的對錯，設計模式是：一種思想，一種模式，一種套路，一種解決問題的高效策略，如果真的後續不會有什麼改動，那就怎麼簡單怎麼寫就好了。當然工廠還有另一種寫法，那就是【抽象工廠】，筆者後續會提到~
Unity 話大 設計模式之抽象工廠
前言 筆者在最開始寫程式的時候經常會遇到一種情況，例如更改乙個字段 或者新增一種小功能，就要把原來寫過的東西幾乎廢棄掉，或者更改大量以前寫過的 又或者自己寫的東西時間久了再去回顧，完全找不到到時為什麼這麼寫的頭緒，如果遇到了bug更是無法快速定位在 小範圍出現的問題。如果你也經常遇到這種問題，就說明...
Unity 話大 設計模式之迭代器模式
前言 筆者在最開始寫程式的時候經常會遇到一種情況，例如更改乙個字段 或者新增一種小功能，就要把原來寫過的東西幾乎廢棄掉，或者更改大量以前寫過的 又或者自己寫的東西時間久了再去回顧，完全找不到到時為什麼這麼寫的頭緒，如果遇到了bug更是無法快速定位在 小範圍出現的問題。如果你也經常遇到這種問題，就說明...
設計模式 工廠模式之工廠方法模式
工廠方法模式是指定義乙個建立物件的介面，然後實現這個介面的工廠來決定建立什麼樣的例項。工廠方法讓類的例項推遲到子類中進行。在這個模式中，只關心需要建立的是什麼工廠，不需要關心建立的細節。而且新加入的產品符合開閉原則。1 建立支付介面，裡面定義抽象的支付方法。package com.gupao.vip...