一、數據保護
1.
二、OCP（開閉原則）的手段
所謂OCP即指對擴展開放（當新需求出現的時候，可以通過擴展現有模型達到目的），對修改關閉（對已有的二進制代碼，不允許進行修改）。
實現OCP原則的關鍵是抽象與封裝。利用抽象封裝完成對需求可能發生變更的部分進行處理，具體處理手段如下：
1.使用多態的方式
做一個繼承樹。此方案針對會發生修改但不是很嚴重的地方，讓需求擴展的實體繼承已經存在的實體。
2.使用繼承與組合聯合的方式
例如： 裝飾者模式、策略模式、狀態模式、橋模式
3.延遲綁定：
運行時註冊：
使用Event style或Observer pattern實現運行時註冊的方式，當需要進行擴展時，就讓擴展的方法監聽某個事件，事件發生時這個方式就會被調用（service lookup）
配置文件：
使用配置文件進行啓動時綁定，將需要修改、擴展的信息寫在配置文件中，通過解析配置文件來決定做什麼事情（DataDriven）
繼承多態方式（LSP）
構件更替：
如果需要修改、擴展，則在加載模塊的時候使用修改/擴展的模塊，實現加載綁定。一般是將變化的部分寫在一個.dll 文件中，變化的時候直接更新.dll 文件。（ReflectiveorMeta-LevelDesign）
預定義協議：
在兩個之間預定義協議，然後各個進程可以獨立進行變化，只要通信協議不變。
例如TCP/IP等協議（Uniform Access）
4.信息隱藏
下文有詳細講述
5.泛化模塊：Interpreter-Driven
6.限制交互路徑
迪米特法則：一個對象應該對其他對象有儘可能少的瞭解
三、一個模塊的信息隱藏有哪兩種基本類型，各自有哪些典型的處理手段？
1. 每個模塊有一個基本的secret——外部的行爲和內部隱藏
每個模塊隱藏重要的設計決策的實現，只有模塊的組成可以瞭解細節。所有的設計決策都獨立於彼此。即一個模塊的接口功能與模塊內部程序細節的分離。給出功能接口，隱藏功能實現程序的細節
方法：
外觀模式Facade pattern
——信息隱藏：用戶和部件的子系統之間解耦合，降低耦合
Controller
2. 模塊可能有附加的secrets——改變
預期的變更：把變更從模塊中分離開來，安排到新的類，方法或者設計單元中.然後封裝隔離所有的secret這樣其一旦變更，變更不會影響其他程序模塊。將要發生變化的程序部分需要進行一個決策。給出需要修改部分的接口，隱藏待修改部分的實現程序細節
方法：
策略模式：將算法從包含其的對象中抽離出來，封裝該算法（策略）爲一個對象
裝飾模式：裝飾在不改變類的代碼的情況下擴展了一個類的實例的功能
適配器模式：將類的接口轉換成另一個client期望的接口，讓接口不兼容的類能一起工作
如果上下文也有可變性：用橋接模式
1. 策略模式：將要變更的算法獨立出來，按照OCP的方法將其封裝起來成爲一個對象，同時給這個算法建立一個繼承樹（爲其設置一個接口，讓所有這個算法的可能變更的版本實現這個接口）
2. 狀態模式： 對象的行爲根據狀態的變化（屬性的取值變化）而變化，將變化的狀態獨立出來做成一棵繼承樹，每一個實現的子類都實現了一種狀態下的行爲。原來的對象包含一 個對狀態對象的引用，表示當前的狀態，一切行爲都使用這個狀態對象的行爲。（需要由Context和State來處理狀態的變化，不要由Client來處 理）
變化來源於內部，即自己做完某件事情後把自己的狀態改掉。
3. 橋接模式：
在
抽象和實現需要獨立變化的情況下，將抽象和實現做成兩個不同的繼承樹。抽象接口和實現接口是兩個完全不同的接口，實現接口一般包含很基本、原始的方法，而
抽象接口包含的是基於原始方法實現的更加高級的方法。在抽象的接口中包含一個對實現對象的引用，抽象對象的方法中需要調用實現對象的方法（抽象接口的方法
基於實現接口的方法）![]()
四、實現共性與可變性有哪些手段？
多態（繼承）與聚合
其中多態（繼承）適合於1 of N的情況，父類中封裝共性部分，子類中封裝可變性部分
聚合適合於M of N的情況，whole角色類封裝共性部分，part角色類封裝可變性部分
1、如果一個對象集之間除共性外，有超過２個的差異行爲，如何處理？
做多個策略樹
2、如果一個對象集的部分行爲組存在差異性，如何處理？
部分行爲綁定在一棵策略樹
3、如果一個對象集的部分屬性（以及依賴於這些屬性的方法）存在差異性，如何處理？
把屬性和方法做成策略樹
4、如果一個對象集的一個行爲需要協作對象來完成，但是它們的協作對象存在差異性，如
何處理？
將“調用協作對象”這一過程置於Strategy中，Command Pattern的變體
5、如果一個對象集的行爲因爲屬性的取值而存在差異性，如何處理？
State Pattern
五、中介解耦機制（在解決De-Coupling時，常常使用哪些Indirection的手段）
1)避免重複——只做一次：重複往往代表着耦合，修改一部分重複代碼表示要修改其他的
2)DIP：Dependency Inversion Principle，依賴倒置原則，即細節應當依賴於抽象，抽象不應當依賴於細節；在要被其他模塊implement的模塊中定義接口，這是一種去除依賴減少耦合的基本方式
3)繼承：共性和差異性
4)設計模式
中介模式
定義封裝一組對象交互方式的對象；中介通過避免對象互相顯式引用提升了鬆散耦合；讓你獨立的差異交互；集中控制
橋接模式
成果：解耦了接口和實現——消除了編譯時依賴，改善了可擴展性，對client隱藏了實現細節
1)依賴倒置：如果抽象實體需要依賴於具體實體的話，那麼爲具體實體做一個接口，抽象實體可以依賴於這個接口，具體實體則實現這個接口
2) 外觀模式：Faade是用戶和子系統之間的一層間接，它封裝子系統的內部實現並對用戶提供訪問接口，將這二者解耦
3) 代理模式：Proxy是用戶和實際實體之間的一層間接，它負責轉發用戶的請求到實際實體，對實際實體進行訪問控制，將這二者解耦
4) 適配器模式：應用中使用了一個接口Target，這個Target的一個實現需 要使用到一個其他實現，但是那個實現與當前的接口不一致。讓Target的實現實體聚合一個Adaptee的對象，做成對象Adapter，當用戶對 Adapter有請求的時候，Adapter便將請求轉發給Adaptee。同時，Adapter還需要實現用戶要求的但是在Adaptee沒有實現的職 責，不僅僅是轉發請求。（client->Adapter->Adaptee）
5) Event-Style事件風格：使用一個事件處理機制，其他模塊可以向處理對象提供事件，也可以將自己的方法註冊到某個事件，當這個事件發生之後，處理對象會調用註冊到這個事件的所有方法，實現事件源和註冊方法的解耦
六、運行時註冊的主要機制、適用場景與優缺點
1、 Observer Pattern
意圖：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於
它的對象都得到通知並被自動更新
適用場景：
（1）當對一個對象的改變需要同時改變其它對象，而不知道具體有多少對象有待改變。
（2）當一個對象必須通知其他對象，而他又不能假定其他對象是誰。換言之，你不希望這
些對象四緊密耦合的。
（3）當一個模型有兩個方面，其中一個方面依賴於另一個方面。將這二者封裝在獨立的對
象中以使它們可以各自獨立的改變和複用。
優點：
靈活性、可變性、複用性得到保證。目標與觀察者之間耦合程度降低，實現抽象耦合，允許
獨立的改變目標和觀察者，可以複用目標對象而無需同時複用其觀察者。
支持廣播通信，目標者不必知道觀察者是誰
缺點：
增加系統複雜程度，對於系統的理解和測試更加困難。
一個觀察者的無意的更新可能引起其他觀察者的意外的更新，也容易引起更更新錯誤，而這
種錯誤難以捕捉。
2、Event Style
相比Observer Pattern，可以實現對多個事件的監聽。即實現對象間多對多的依賴關係。
其他特點同Observer Pattern
3、Command Pattern
意圖：將一個請求封裝爲一個對象，從而使你可用不同的請求對客戶進行參數化；請求排
隊或記錄請求日誌，以及支持可撤銷的操作。
適用場景：
（1）抽象出待執行的操作以參數化某對象。
（2）在不同的時候制定、排列和執行請求。
（3）通過在實施操作之前將狀態存儲起來以支持撤銷操作。
（4）支持修改日誌，這樣當系統崩潰時，這些修改可以被重做一遍。
優點：
將調用操作的對象與知道如何實現該操作的對象解耦。
可以將命令存儲在棧或隊列中以支持請求排隊，命令處理模式維護一個歷史信息。
可以容易的支持undo和redo操作，但是必須存儲額外的狀態信息以避免滯後影響問題。
擴展Command對象很容易。
七、特殊類型處理機制
八、對象的創建有哪些常見解決方法
1、簡單場景：
Creator創建者：對於A、B兩個對象，在以下情況下A創建B對象：A聚合了B的對象；A包含了B的對象；A記錄了B對象的引用；A使用了B的對象；在A中包含初始化B對象的數據
Coupling低耦合：在A聚合、包含、記錄、使用B的情況下，如果將創建B對象的職責賦予其他對象，則A需要與其他對象產生多餘的耦合
Cohesion高內聚：在A中包含初始化B對象的數據的情況下，則A爲信息專家，根據高內聚原則，A應當承擔B對象創建的職責
2、複雜場景：
（1）場景一：僅僅一個實例允許被創建
使用SingletonPattern，首先將Constructor私有化；聲明一個static private的類實例；創建一個publicstatic的getInstance方法使得外部類可以通過此方法獲得此類實例。並且此方法如果用於多線程，要注意聲明爲protected/synchronize以保證線程安全
（2）場景二：實例個數有限制
以singleton爲基礎進行改進
（3）場景三：一個類不知道它所必須創建的對象的類；一個類希望有他的子類來制定它所創建的對象；類將創建對象這一職責委託給多個幫助子類中的一個，並且希望將哪一個幫助子類作爲代理者這一信息局部化
Factory Method
（4）場景四：控制子類拓展，子類與父類的算法框架相同，但局部實現方法不同
Template MethodPattern
（5）場景五：多個需創建的類實例之間存在類型依賴關係
Abstract FactoryMethod
（6）場景六：實例的創建和初始化很複雜，例如運行時刻制定要實例化的類；初始化時變量值發生變更
Prototype Pattern