在軟件系統中，經常面臨著“某個對象”的創建工作，由于需求的變化，這個對象的具體實現經常面臨著劇烈的變化，但是它卻擁有比較穩定的接口。如何應對這種變化？提供一種封裝機制來隔離出“這個易變對象”的變化，從而保持系統中“其它依賴該對象的對象”不隨著需求的改變而改變？這就是要說的Factory Method模式了。

    意圖

    定義一個用戶創建對象的接口，讓子類決定實例化哪一個類。Factory Method使一個類的實例化延遲到其子類。

    結構圖

    生活中的例子

    工廠方法定義一個用于創建對象的接口，但是讓子類決定實例化哪個類。壓注成型演示了這種模式。塑料玩具制造商加工塑料粉，將塑料注入到希望形狀的模具中。玩具的類別（車，人物等等）是由模具決定的。

    工廠方法解說

    在工廠方法模式中，核心的工廠類不再負責所有產品的創建，而是將具體創建工作交給子類去做。這個核心類僅僅負責給出具體工廠必須實現的接口，而不接觸哪一個產品類被實例化這種細節。這使得工廠方法模式可以允許系統在不修改工廠角色的情況下引進新產品。在Factory Method模式中，工廠類與產品類往往具有平行的等級結構，它們之間一一對應。

    現在我們考慮一個日志記錄的例子（這里我們只是為了說明Factory Method模式，實際項目中的日志記錄不會這么去做，也要比這復雜一些）。假定我們要設計日志記錄的類，支持記錄的方法有FileLog和EventLog兩種方式。在這里我們先不談設計模式，那么這個日志記錄的類就很好實現了：