幫你整理了一份設計模式速查手冊
知識需要不斷積累、總結和沉澱，思考和寫作是成長的催化劑
內容目錄
老生常談建立型1、Singleton單例2、Factory Method工廠方法3、Abstract Factory抽象工廠4、builder建造者5、Prototype原型結構型1、Adapter 介面卡2、Decorator 裝飾3、Bridge 橋接4、Composite 組合5、Flyweight 享元6、Proxy 代理7、Facade外觀行為型1、Interpreter 直譯器2、Template Method 模板方法3、Chain of Responsibility 責任鏈4、Command 命令5、Iterator 迭代器6、Mediator 中介者7、Memento備忘錄8、Observer 觀察者9、State 狀態10、Strategy 策略11、Visitor 訪問者謝謝
老生常談
GOF23種設計模式，想必都有聽過或學習過，就是有四個人搞了一本書總結了在面向物件開發過程中常見問題的解決方案。
啥是模式？就是發現一種可識別的規律，比如色彩模式（簡歷模版也算）。模式也往往和抽象思維有關，分析事物共性，抽取事物共同的部分來幫助人們認識規律。
啥又是設計模式？就是對事物的重新定位整合來解決問題的一種模版一種套路。它是成熟的解決方案，解決類似的問題，這樣我們可以站在巨人的肩膀上，更加優雅的開發設計。
（本手冊儘可能採用口語化表達，便於代入，很基礎的細節會刪減，瞭解過設計模式者服用更佳，查漏溫故，瀏覽起來會比較輕鬆）
進入正題，設計模式按功能分為三大類
建立型
建立型設計模式，顧名思義用於物件的建立。提供建立物件就是如何New一個物件
1、Singleton單例
單例模式使得一個類只有一個例項。通常像一些工具類，只需要初始化一個例項即可，不需要每次使用都去再例項化一個，這樣可以解決些資源浪費。和靜態類功能上類似，只不過單例是個物件例項。套路1：通常三步走，私有建構函式禁止外部構造，公開靜態方法提供給外部使用，私有靜態變數保證唯一（這樣只是單執行緒模式下適用）。外部通過Singleton.GetInstance()獲取唯一物件例項。
class Singleton
{
private static Singleton instance;
{
}
public static Singleton GetSingleton()
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
套路2：多執行緒下簡單粗暴的方式就是lock加鎖，讓程式碼塊只能有一個執行緒進入。
private static readonly object syncRoot = new object();
public static Singleton GetSingleton()
{
lock (syncRoot)
{
if (instance == null)
{
instance = new Singleton();
}
}
return instance;
}
再優化一下，上面這種方法會導致多個執行緒都需要等待，無論例項是否已經建立。我們想在例項已經建立的情況下多執行緒就不需要等待，直接返回就行。在lock外面加個判斷null可以保證以後的多執行緒訪問不用排隊等待。這就是雙重鎖定。
public static Singleton GetSingleton()
{
if (instance == null)
{
lock (syncRoot)
{
if (instance == null)
{
instance = new Singleton();
}
}
}
return instance;
}
套路3：上面的已經完全實現了單例模式，但還有一個更簡單的方式-靜態初始化。CLR會在類載入時初始化靜態欄位，且是執行緒安全的，所以可以把類例項化放在靜態欄位上。
public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton()
{
}
public static Singleton GetSingleton()
{
return instance;
}
}
這種稱之為餓漢式單例，類一載入就例項化物件。前面的是懶漢式，在第一次引用時例項化。
2、Factory Method工廠方法
簡單工廠模式：什麼是工廠？現實中就是生產東西的地方，程式裡也是，就是有一個單獨的地方（類）來負責建立各種例項。
以經典的加減乘除計算程式為例，如果按照面向過程流程開發，大概步驟就是使用者輸入數字1，然後輸入運算子，輸入數字2，然後根據運算子if或switch判斷呼叫哪個數學方法，這種沒有面向物件，都在一起，耦合太緊（程式碼就不貼了，都是過來人）
先看一下使用簡單工廠模式之後的類圖
把加減乘除各個運算操作封裝成單獨類，都繼承自運算類，共用基類的成員變數AB，重寫GetResult獲取運算結果方法。封裝之後，提供一個簡單工廠類，通過傳入不同的操作符，例項化不同的操作運算類。這樣增加新的操作運算子時只需要修改工廠就行。（增加一個流水線）
簡單工廠類核心：
public class OperationFactory
{
public static Operation CreateOperate(string operate)
{
Operation oper = null;
switch (operate)
{
case "+":
oper = new OperationAdd();
break;
case "-":
oper = new OperationSub();
break;
case "*":
oper = new OperationMul();
break;
case "/":
oper = new OperationDiv();
break;
}
return oper;
}
}
工廠方法模式：對簡單工廠模式的進一步抽象。簡單工廠是要求把邏輯放在在工廠類中，新增需要修改case分支，違背了開放封閉原則。工廠方法模式進一步在工廠上做文章，定義一個建立物件的介面，讓子類決定例項化哪一個類。
工廠部分像下面這樣
interface IFactory
{
Operation CreateOperation() ;
}
class AddFactory : IFactory
{
public Operation CreateOperation()
{
return new OperationAdd();
}
}
class SubFactory : IFactory
{
public Operation CreateOperation()
{
return new OperationSub();
}
}
客戶端呼叫像下面這樣。如果增加操作運算子，增加相應的運算類和工廠，不需要像簡單工廠那樣修改工廠類內的邏輯。
IFactory operFactory = new AddFactory();
Operation oper = operFactory.CreateOperation();
3、Abstract Factory抽象工廠
抽象工廠模式和工廠方法類似。它是提供一個建立一系列物件的工廠介面，無需指定它們具體的類。我們看下結構圖
如果說工廠方式模式只是提供單一產品建立介面，那抽象工廠就是讓工廠抽象類擁有建立更多產品的能力，一個汽車生產線包括車架，底盤，輪轂等。抽象工廠的好處便於交換產品系列。如常見的資料庫訪問類。
interface IFactory
{
IUser CreateUser();
IDepartment CreateDepartment();
}
class SqlServerFactory : IFactory
{
public IUser CreateUser()
{
return new SqlserverUser();
}
public IDepartment CreateDepartment()
{
return new SqlserverDepartment();
}
}
class AccessFactory : IFactory
{
public IUser CreateUser()
{
return new AccessUser();
}
public IDepartment CreateDepartment()
{
return new AccessDepartment();
}
}
如果只是替換產品線比較容易，要是新增一個數據庫訪問表就要修改IFactory，SqlServerFactory ，AccessFactory。 這裡可以用簡單工廠改進。雖然簡單工廠會多一些switch或if判斷，但可以通過反射配置去掉。
4、builder建造者
又叫生成器模式，將一個複雜產品的生成過程和它的表示分離，這樣給不同的表示就可以創建出不同的產品，就像去買咖啡，加不加糖，加幾塊，加不加奶，做出來就是不同的咖啡，使用者只需要指定我要冰美式就行。
有多個產品Builder構建類生成不同的產品，使用者Director指揮者指定一種產品就可以通過GetResult獲取這款產品。這個比較好理解，產品建立過程內部完整高內聚，只對外暴露產品需求，需要什麼產品，內部建立後給客戶。
5、Prototype原型
原型模式用於建立重複的物件而不需要知道建立的細節。一般在初始化的資訊不發生變化時，克隆Copy可以動態的獲取一個執行時的物件，而且效率相比建構函式會提高。原型模式克隆物件應該是由於型別自己完成的。
在dotNET中提供了一個ICloneable介面（代替原型抽象類Prototype的功能）。只需要實現這個介面就可以完成原型模式。
class MyClass : ICloneable
{
public object Clone()
{
return this.MemberwiseClone();
}
}
注意：MemberwiseClone是淺拷貝，就是對於引用型別只複製了引用，而沒有真的把引用型別堆地址複製一份，值型別倒沒問題是真的記憶體上覆制一份。所以這樣如果生成一個拷貝類，則修改拷貝類中的引用型別，原類也會跟著變動。因此使用深拷貝老老實實在Clone方法裡呼叫過載建構函式（直到沒有引用型別成員）初始化拷貝類，然後將值型別變數賦值。
結構型
結構型設計模式關注的是物件與物件之間的關係，像拼積木，組合合併給程式提供更好的靈活和擴充套件
1、Adapter 介面卡
聯想到電源的介面卡，各個國家的電壓不一樣，為了滿足電器使用電壓就需要介面卡轉換成額定電壓，那麼介面卡模式的定義就是將一個類的介面轉換成客戶希望的另外一個介面，使得原本由於介面不相容而不能一起工作的那些類可以一起工作。那麼如何轉換呢，核心就是介面卡繼承或依賴已有的物件，實現想要的目標介面。
核心通過繼承或依賴：
class Adapter : Target
{
private Adaptee adaptee = new Adaptee();
public override void Request()
{
adaptee.SpecificRequest();
}
}
主要解決現有類不能滿足系統介面要求下，將現有類（可以是多個）包裝到介面繼承類下。這樣介面繼承類就能呼叫介面來實際呼叫現有類功能。雖然提高類的複用，增加靈活，但過多使用導致內部太透明，明明呼叫的是A介面，後臺又實際呼叫的B介面。所以可以看出介面卡是在專案服役時期做的靈活調整，屬於臨陣磨槍，設計期能重構不用最好。不便重構的情況下，介面卡可以快速統一介面。
2、Decorator 裝飾
人靠衣服馬靠鞍，裝飾模式就像給人搭配服飾，可以根據不同場合搭配不同的風格，裝飾模式可以動態的給一個物件新增額外的功能職責（比直接用子類靈活一些），在不增加子類的情況下擴充套件類。
核心套路：Component 類充當抽象角色，不具體實現，ConcreteComponent子類代表實際的物件，現在要給這個物件新增一些新的功能。裝飾類繼承並且引用Component類，通過設定裝飾類中的Component屬性呼叫具體被裝飾物件ConcreateComponent方法。可能有些繞，關鍵在於裝飾類和具體被裝飾物件都要繼承相同的抽象Component 類。
看下程式碼也許會更容易理解
abstract class Component
{
public abstract void Operation();
}
class ConcreteComponent : Component
{
public override void Operation()
{
Console.WriteLine("具體被裝飾物件的操作 ")
}
}
abstract class Decorator : Component
{
protected Component component;
public void SetComponent(Component component)
{
this.component = component;
}
public override void Operation()
{
if (component != null)
{
component.Operation();
}
}
}
class ConcreateDecoratorA : Decorator
{
private string addedState;
public override void Operation()
{
base.Operation();//執行原Component的功能
//可以新增需要裝飾的東西，增加什麼功能
addedState = "New State";
Console.WriteLine("具體裝飾物件A的操作 ");
}
}
class ConcreateDecoratorB : Decorator
{
public override void Operation()
{
base.Operation();//執行原Component的功能
//可以新增需要裝飾的東西，增加什麼功能
AddedBehavior();
Console.WriteLine("具體裝飾物件B的操作 ");
}
private void AddedBehavior()
{
}
}
客戶端呼叫時像下面這樣。
ConcreteComponent c = new ConcreteComponent();
ConcreateDecoratorA d1 = new ConcreateDecoratorA();
ConcreateDecoratorB d2 = new ConcreateDecoratorB();
d1.SetComponent(c);
d2.SetComponent(d1);
d2.Operation();
利用SetComponent將待裝飾物件包裝到裝飾器中，然後呼叫裝飾器的同名方法（因為都繼承相同的抽象類）。像上面這樣可以定義不同的裝飾器，會按順序逐個呼叫裝飾的部分。
總之，裝飾模式可以動態擴充套件一個實現類的功能，當有實現類需要增加特殊行為時，可以用一個單獨的裝飾類去實現，（把被裝飾類也就是實現類包裝進去即可），像前面的也可以不用一個Component抽象類，直接用裝飾類繼承被裝飾類就不需要修改原類。有一個不好的地方就是如果裝飾行為多了，請注意裝飾順序。
3、Bridge 橋接
像路由器橋接一樣，將兩者解耦，通過一個橋接介面連通。橋接模式用於把抽象部分和實現部分分離解耦，使得兩者可以獨立變化。
橋接模式中一個重要的概念就是用關聯組合代替繼承，從而降低類與類之間的耦合和臃腫。比如一個繪製圖形的功能，有圓形、正方形等不同的圖形，它們還有不同的顏色。用繼承關係設計可能像下面這樣。可以看見類比較多
還有一種方案就是對圖形和顏色進行組合得到想要的顏色圖形。
所以對於有多個維度變化的系統，採用第二種方案系統中的類個數會更小，擴充套件方便。
abstract class Implementor
{
public abstract void Operation();
}
class ConcreteImplementorA : Implementor
{
public override void Operation()
{
Console.WriteLine("具體實現A的方法執行");
}
}
class ConcreteImplementorB : Implementor
{
public override void Operation()
{
Console.WriteLine("具體實現B的方法執行");
}
}
class Abstraction
{
protected Implementor implementor;
public void SetImplementor(Implementor implementor)
this.implementor = implementor;
}
public virtual void Operation()
{
implementor.Operation();
}
}
class RefinedAbstraction : Abstraction
{
public override void Operation()
{
implementor.Operation();
}
}
客戶端呼叫
Abstraction ab = new RefinedAbstraction();
ab.SetImplementor(new ConcreteImplementorA());
ab.Operation();
ab.SetImplementor(new ConcreteImplementorB());
ab.Operation();
如果系統可能有多個角度的分類，每一種角度都可能變化，就可以不用靜態的繼承連線，通過橋接模式可以使它們在抽象層建立關聯關係。
4、Composite 組合
組合模式也就是部分整理關係，將物件組合成樹形結構以表示“部分整體”的層次結構，組合模式使得使用者對單個物件和組合物件的使用具有一致性，用於把一組相似的物件當做一個單一的物件。
核心就是讓樹枝和葉子實現統一的介面，樹枝內部組合該介面，並且含有內部屬性List放Component。
abstract class Component
{
protected string name;
public Component(string name)
{
this.name = name;
}
public abstract void Add(Component c);
public abstract void Remove(Component c);
public abstract void Display(int depth);
}
class Leaf : Component
{
public Leaf(string name) : base(name)
{ }
public override void Add(Component c)
{
Console.WriteLine("Cannot add to a leaf");
}
public override void Remove(Component c)
{
Console.WriteLine("Cannot remove to a leaf");
}
public override void Display(int depth)
{
Console.WriteLine(new string('-', depth) + name);
}
}
class Composite : Component
{
private List<Component> children = new List<Component> { };
public Composite(string name) : base(name)
{ }
public override void Add(Component c)
{
children.Add(c);
}
public override void Remove(Component c)
{
children.Remove(c);
}
public override void Display(int depth)
{
Console.WriteLine(new string('-', depth) + name);
foreach (Component component in children)
{
component.Display(depth + 2);
}
}
}
客戶端使用像下面這樣
Composite root = new Composite("root");
root.Add(new Leaf("Leaf A"));
root.Add(new Leaf("Leaf B"));
Composite comp = new Composite("Composite X");
comp.Add(new Leaf("Leaf XA"));
comp.Add(new Leaf("Leaf XB"));
root.Add(comp);
Composite comp2 = new Composite("Composite XY");
comp2.Add(new Leaf("Leaf XYA"));
comp2.Add(new Leaf("Leaf XYB"));
comp.Add(comp2);
root.Add(new Leaf("Leaf C"));
root.Display(1);
或者像公司體系結構這種當需求中體現部分整體層次結構，以及你希望使用者可以忽略組合物件與單個物件的不同，統一地使用組合結構中的所有物件時，考慮使用組合模式。上面例子中客戶端無需關心處理一個葉節點還是枝節點組合元件，都用統一方式訪問。
5、Flyweight 享元
享元模式主要用於減少物件的數量，以減少記憶體佔用和提供效能。享元模式嘗試重用現有的同類物件，如果未找到匹配的物件，則建立新物件。像棋盤中的棋子，不可能建立一整個所有的棋子物件。所以它主要解決當需要大量的物件，有可能對記憶體造成溢位，我們可以把共同的部分抽象出來，這樣如果有相同的業務請求，直接返回記憶體中已有的物件，不去重複建立了。
核心就是用一個字典儲存這些需要重複使用的物件。
通過上面結構圖可以看見就是把Flyweight享元類聚合到FlyweightFactory享元工廠中，享元工廠中用一個Hashtable儲存這些具體的享元類。
class FlyweightFactory
{
private Hashtable flyweights = new Hashtable();
public FlyweightFactory()
{
flyweights.Add("X", new ConcreateFlyweight);
flyweights.Add("Y", new ConcreateFlyweight);
}
public Flyweight GetFlyweight(string key)
{
return (Flyweight)flyweights[key];
}
}
看上面程式碼，估計大都用過，設計模式好多都是這種普普通通，資料庫連線池就是使用享元模式。總結下就是在系統中有大量相似物件或者需要緩衝池的場景，相似物件可以分離出內部和外部狀態，內部狀態就是固有的，不變的。外部狀態可以通過外部呼叫傳遞進去。
6、Proxy 代理
像代購一樣，我們拜託他人幫我們買某個東西。代理模式就是用一個類代表另一個類的功能。通常在不方便直接訪問原始物件功能，或者需要對原始物件功能增加一些許可權或其他控制時使用代理模式。
核心就是增加代理層，讓代理類和真實類都實現相同的介面（或抽象類），然後把真實類關聯到代理類中。
上述結構圖中的核心程式碼如下
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}
代理模式其實就是在訪問物件時引入一定程度的間接性，因此可以附加多種用途。
7、Facade外觀
外觀模式隱藏系統的複雜性，向客戶端提供一個高層訪問系統介面。這樣降低訪問複雜系統的內部子系統時的複雜度，簡化客戶端互動，就像公司前臺。
核心就是將複雜系統裡的類關聯到外觀類上。上面結構圖就很清晰，通過外觀類方法呼叫各個複雜系統類。
這種方式對老系統尤其有用，新增功能需要用到舊類，如果怕改壞了，就可以簡單實用外觀封裝。還有就是設計時經典的三層架構也是外觀的體現。
行為型
行為型設計模式關注物件和行為的分離。行為型比較多，因為程式邏輯都需要行為來觸發。
1、Interpreter 直譯器
直譯器模式，給定一個語言，定義它的文法的一種表示，並定義一個直譯器，這個直譯器使用該表示來解釋語言中的句子。有點拗口，簡單理解就是對於一些固定文法構建一個解釋句子的直譯器。像正則表示式就是這樣，查詢匹配字元問題發生的頻率很高，就把該問題各個例項表述為一個簡單語言中的句子，解釋句子來解決問題。比例諜戰片中的加密電報，構建一個直譯器對每個文法解析。
核心就是構建語法數，定義終結符與非終結符。實際利用的場景還是比較少的，而且文法太複雜也很難維護。
實際客戶端呼叫時像下面這樣遍歷直譯器文法
Context context = new Context();
List<AbstractExpression> list = new ArrayList<>();
list.Add(new TerminalExpression());
list.Add(new NonterminalExpression());
list.Add(new TerminalExpression());
list.Add(new TerminalExpression());
foreach (AbstractExpression abstractExpression in list)
{
abstractExpression.Interpret(context);
}
2、Template Method 模板方法
在模板方法中，一個抽象類公開定義一個演算法的執行方式模板，而將一些步驟延遲到子類中，子類可以按需要重寫方法實現，但呼叫統一使用抽象類中定義的方式呼叫。
上面結構圖中AbstractClass就是一個抽象類（抽象模板），定義並實現了一個模板方法。像下面這樣
看見核心就是將通用方法封裝在超類中，所以在當子類方法中有一些不變的和可變的行為，可以將不變的行為通過模板方法搬到父類，這樣子類就不需要重複這些不變的部分。是不是很簡單，設計模式就是對面向物件程式設計，封裝繼承多型的靈活使用。
3、Chain of Responsibility 責任鏈
像公司內的請假流程，如果請很長時間，可能先有部門經理審批，部門經理說時間太長了，需要問下總經理。為請求建立了一個接受者物件的鏈，讓請求者和接收者解耦。這種模式中，通常每個接收者都包含對另一個接收者的引用，這樣如果這個接收者物件不能處理該請求就傳遞給下一個接收者。
上述結構圖中首先定義一個Handler處理請求抽象類，裡面設定了下一個接收者和處理請求的抽象方法。然後再ConcreateHandler子類中實現具體的請求處理，如果處理不了，就轉發給下一個接收者。
abstract class Handler
{
protected Handler successor;
public void SetSuccessor(Handler successor)
{
this.successor = successor;
}
public abstract void HandleRequest(int request);
}
class ConcreateHandler1 : Handler
{
public override void HandleRequest(int request)
{
if (request >= 0 && request < 10)
{
Console.WriteLine($"{this.GetType().Name}處理請求 {request}");
}
else if (successor != null)
{
successor.HandleRequest(request);
}
}
}
核心就是攔截類都實現統一介面。Handler裡聚合它自己，在HandlerRequest裡判斷是否能處理，如果不能就向下傳遞，要向誰傳遞就Set進去。所以這種方式是不確定哪個接收者會處理請求，通常在攔截器中使用，需要對訊息的處理過濾很多道時。像擊鼓傳花。
4、Command 命令
服務員，再炒個方便麵，10個腰子，服務員就記下來交給炒菜師傅和烤串師傅，這就是命令模式。請求以命名的形式包裹在物件中，並傳給呼叫物件。呼叫物件尋找可以處理該命名的合適的物件，並把該命名傳給相應的物件執行命名。並且支援可撤銷操作，如果腰子很久沒上來，可以通知服務員不要了。
核心就是定義三個角色：1、received真正的命令執行物件2、Command3、invoker使用命令物件的入口。最最終實現Invoker物件通過呼叫ExecuteCommand方法來呼叫具體命令Command的Excute方法，Excute方法裡呼叫實際Received接收者動作。
相關推薦
幫你整理了一份設計模式速查手冊
知識需要不斷積累、總結和沉澱，思考和寫作是成長的催化劑
內容目錄
老生常談建立型1、Singleton單例2、Factory Method工廠方法3、Abstract Factory抽象工廠4、builder建造者5、Prototype原型結構型1、Adapter 介面
深度學習高手該怎樣煉成？這位拿下阿里天池大賽冠軍的中科院博士為你規劃了一份專業成長路徑
作者 | 劉昕
責編 | 胡永波
深度學習本質上是深層的人工神經網路，它不是一項孤立的技術，而是數學、統計機器學習、電腦科學和人工神經網路等多個領域的綜合。深度學習的理解，離不開本科數學中最為基礎的數學分析（高等數學）、線性代數、概率論和凸優化；深度
整理了一份谷歌地址校驗查詢的案例。
都知道谷歌很牛逼。自從用了他的地址校驗，別的我都不想用了。
程式碼
package com.yiexpress.core.utils.aupost;
import java.io.IOException;
import java.util.HashMap;
impor
在Python 2.7即將停止支援時，我們為你準備了一份3.x遷移指南
目前，Python 科學棧中的所有主要專案都同時支援 Python 3.x 和 Python 2.7，不過，這種情況很快即將結束。去年 11 月，Numpy 團隊的一份宣告引發了資料科學社群的關注：這一科學計算庫即將放棄對於
Python 2.7 的支援，全面轉向 Py
參考整理了一份gulpfile.js
{
"name": "driveRepertory",
"version": "1.0.0",
"devDependencies": {
"autoprefixer": "^8.2.0",
"babel-cli": "^6.26.0"
整理了一份比較全面的PHP開發編碼規範.
這些年來多從事Linux下PHP和C相關的開發，帶過很多專案和團隊，下面是根據經驗整理的PHP編碼規範，可以用作給大家的範例和參考，根據需要進行取捨和修改！
（可能最新的一些php5的規範不夠完整，今後有機會保持更新！）
目錄1 編寫目的2 整體要求3 安全規範3.1 包含檔
整理了一份招PHP高階工程師的面試題
1. 基本知識點
HTTP協議中幾個狀態碼的含義:1xx（臨時響應）表示臨時響應並需要請求者繼續執行操作的狀態程式碼。
程式碼 說明
100 （繼續） 請求者應當繼續提出請求。 伺服器返回此程式碼表示已收到請求的第一部分，正在等待其餘部分。
101 （
我自己總結的C#開發命名規範整理了一份
學習C#之初，始終不知道怎麼命名比較好，很多時候無從命名，終於有一天我整理了一份命名規範文件，自此我就是按照這個命名規範書寫程式碼，整潔度無可言表，拙劣之處請大家斧正，愚某虛心接受，如有雷同，不勝榮幸
C#語言開發規範
作者ching
1. 命名規範
a) 類
【規
for程序員：這些你可能遇到的職場難題，我們幫你整理好了答案
程序員“迷茫”是當下青年談論的最多的詞匯之一，無論高矮胖瘦富窮美醜，每個人都有自己獨特的難題。造成“迷茫”的原因有很多種，比如生存壓力，情感問題，以及困擾著相當一部分人的職場焦慮。今天這篇關於“職場迷茫”的不完全解決手冊獻給個推的主要用戶——廣大開發者們。
也許你剛剛畢業，在“沒有選擇”或“太多選擇”面前感到
準備了一份 1024 厚禮，你懂的~
今天是10月24日，也是一年一度的優達程式設計師節，感謝千千萬萬個程式設計師辛苦寫下的計算機程式，也為聰明可愛的程式設計師準備了一份1024厚禮（請拖到文末）！
如果沒有程式設計師，整個虛擬世界都會消失不見。全中國7億多網民，再也不能愉快滴發自拍，看視訊，打遊戲，甚至連打電話都成了一種幻想。絕大部分
我寫了一份作業系統詞典送給你！
1. 作業系統（Operating System，OS）：是管理計算機硬體與軟體資源的系統軟體，同時也是計算機系統的核心與基石。作業系統需要處理管理與配置記憶體、決定系統資源供需的優先次序、控制輸入與輸出裝置、操作網路與管理檔案系統等基本事務。作業系統也提供一個讓使用者與系統互動的操作介面。
2. shell
Linux下使用Docker部署nacos-server:1.4.0（單機模式），喪心病狂的我在半夜給UCloud提交了一份工單
## 1. 拉取nacos-server映象
進入 [Docker Hub](https://hub.docker.com/r/nacos/nacos-server/tags?page=1&ordering=last_updated) 檢視nacos-server最新版本為 `nacos-server:1.
一篇文章圖文並茂地帶你輕鬆學完 JavaScript 設計模式(一)
## JavaScript 設計模式(一)
本文需要讀者至少擁有基礎的 `ES6` 知識，包括 `Proxy`, `Reflect` 以及 `Generator` 函式等。
至於這次為什麼分了兩篇文章，有損傳統以及標題的正確性，是這樣的。
其實放在一篇文章裡也可以，但是希望讀者能夠更加輕鬆點，文章太長也會
不是說朝聞道夕死可矣嗎（如果你發現了自己的學習模式，願意學並且能堅持，我覺得沒什麽能阻擋你征服軟件世界的腳步），安曉輝大神的感悟
說我 服務器 摘錄 syn 給他 sync 外包 學習曲線 有限公司 從技術支持中途轉戰軟件開發，如今從事編程工作已十多有余，2014年CSDN博文大賽編程語言組冠軍、CSDN Qt論壇的版主安曉輝老師從今天開始，坐鎮CSDN社區問答欄目的 第十四期，屆時會接受廣大網友的提
微信公眾號平臺搭建——幫你搭起一片商機
微信運營 微信平臺搭建 時下網絡經濟時代的沖擊，微信公眾平臺已經逐漸取代微博成為了互聯網的新寵兒，通過公眾號我們可以實現粉絲吸引，品牌包裝，口碑營銷，活動互動，業務辦理等一系列線上營銷活動。為商家實現時時線上線下互動，產品業務咨詢辦理等一系列營銷活動，激發巨大商機。下面我們來一起見證一下正規的微信公眾
聽說你想做一份高階的視覺化圖表？
雙十一狂歡，五折帶回家
想做一份高階的視覺化圖表，升職加薪，走上人生巔峰，em...迎娶白富美 or 成為白富美？
比如說，這樣滴...
又或者...是這樣滴...
然鵝！！！你做出來的圖表，實際是這樣的☟☟☟
【知識積累】一、設計模式（建立型）
定義公共介面和實現類：
一、工廠方法模式（Factory Method）
1、普通工廠模式
2、多工廠方法模式
3、靜態工廠方法模式
二、抽象工廠模式（Abstract Factory）
三、建造者模式（Builder）
【知識積累】一、設計模式
一、分類
1、建立型（5）
工廠方法模式、抽象工廠模式、建造者模式、原型模式、單例模式。
2、結構型（7）
介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
3、行為型模式（11）
策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄
（一）設計模式之單例模式(singtonMode)
參考文章：
（1）https://blog.csdn.net/li295214001/article/details/48135939
（2）http://love-love-l.blog.163.com/blog/static/21078304201001804211901/
（3）h
php 十一種設計模式
&nbs