Python Editor接口介紹說明
Python Editor接口給出了處理所有個人信息的公共接口，其完整的代碼如清單2所示。PIM通過調用getUI()方法能夠獲得與用戶進行交互的UI組件，希望大家能夠學到不少知識。
在工廠方法模式中，父類負責定義創建對象的公共接口，而子類則負責生成具體的對象，這樣做的目的是將類的實例化操作延遲到子類中完成，即由子類來決定究竟應該實體化哪一個類。
在簡單工廠模式中，一個工廠類處于對產品類進行實例化的中心位置上，它知道每一個產品類的細節，并決定何時哪一個產品類應當被實例化。簡單工廠模式的優點是能夠使客戶端獨立于產品的創建過程。并且在系統中引入新產品時無需對客戶端進行修改，缺點是當有新產品要加入到系統中時，必須對工廠類進行修改，以加入必要的處理邏輯。
簡單工廠模式的致命弱點就是處于核心地位的工廠類，因為一旦它無法確定要對哪個類進行實例化時，就無法使用該模式，而工廠方法模式則可以很好地避免這一問題。考慮這樣一個應用程序框架（Framework），它可以用來瀏覽各種格式的文檔，如TXT、DOC、PDF、HTML等，設計時為了讓軟件的體系結構能夠盡可能地通用。
定義了Application和Document這兩個抽象父類，Python Editor接口客戶必須通過它們的子類來處理某一具體類型的文檔。例如，要想利用該框架來編寫一個PDF文件瀏覽器，必須先定義PDFApplication和PDFDocument這兩個類，它們應該分別繼承于Application和Document。
Application的職責是對Document進行管理，并且在需要時創建它們，比如當用戶從菜單中選擇Open或者New的時候，Application就要負責創建一個Document的實例。顯而易見，被實例化的特定Document子類是與具體應用相關的，因此Application無法預測哪個Document的子類將被實例化，它只知道一個新的Document何時（When）被創建。
但并不知道哪種（Which）具體的Document將被創建。此時若仍堅持使用簡單工廠模式會出現一個非常尷尬的局面：框架必須實例化類，但它只知道不能被實例化的抽象類。解決的辦法是使用工廠方法模式，它封裝了哪一個Document子類將被創建的信息，并且能夠將這些信息從框架中分離出來。
Application的子類重新定義了Application的抽象方法createDocument()，并返回某個恰當的Document子類的實例。我們稱createDocument()是一個工廠方法（factory method），因為它非常形象地描述了類的實例化過程，即負責"生產"一個對象。
Python Editor接口定義了一個公共的構造性方法（builder method）getEditor()，它返回一個Editor對象，其完整的代碼如清單1所示。任何一項個人信息都擁有自己獨立的用戶界面（Editor），負責獲取數據并在需要的時候進行修改，而PIM***要做事情的只是通過Editable來獲得Editor，并利用它來對用戶輸入的數據進行相應的操作。
【編輯推薦】
