開始學習大神的關於設計模式的博客 有了一些自己的理解，首先奉上大神博客鏈接：
https://blog.csdn.net/LoveLion/article/details/17517213
感想：總體思想（將變化隔離，使得變化部分發生變化時，不變部分不受影響（這也是OCP的目的））
開閉原則是目標，里氏代換原則是基礎，依賴倒轉原則是手段； 第一要明確，所有的原則都是爲了實現面向對象設計的可擴展性，可複用性，可維護性（對原有代碼不要進行修改）而定義的；一個已有的代碼模塊，需要實現可擴展性，需要對外保持開放；爲了實現可複用性，需要保持獨立（單一職責，高內聚，低耦合）；爲了實現可維護性，需要對內封閉（對已有代碼模塊不要進行修改）。 開閉原則(Open-Closed Principle, OCP)：一個軟件實體應當對擴展開放（可擴展性），對修改關閉（可維護性）。即軟件實體應儘量在不修改原有代碼的情況下進行擴展。所以說開閉原則是目的。 第二，爲了實現開閉原則（可擴展性，可維護性和複用性）在最初就需要對代碼模塊進行抽象化設計（抽象化是實現開閉原則的關鍵）；面向對象思想中的抽象化是指把現實中一類具有相同屬性，行爲的事物歸類的方法。 抽象 ---對同一類對象的共同屬性和行爲進行概括，形成類。 有：數據抽象（屬性或狀態）、代碼抽象（某類對象的共有的行爲特徵或功能）。抽象的實現是：類 大牛們就想在Java、C#等編程語言中，可以爲系統定義一個相對穩定的抽象層，而將不同的實現行爲移至具體的實現層中完成。在很多面向對象編程語言中都提供了接口、抽象類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴展。如果需要修改系統的行爲，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有代碼的基礎上擴展系統的功能，達到開閉原則的要求。具體操作作：通過針對抽象基類編程（業務邏輯關係的建立），具體運行時代換具體子類對象執行，可以達到開閉原則的目的，該實現過程就是里氏代換原則定義本身，所以說里氏代換原則是理論基礎！ 通過里氏代換原則的操操作過程，大牛們總結出抽象不依賴於細節，細節應該依賴於抽象的依賴倒轉原則。具體就是變量、參數、方法返回、數據類型轉換等都要用抽象定義聲明，再通過依賴注入（構造注入、設值注入和接口注入）或依賴獲取的方式將具體對象注入到有依賴關係的對象中。所以說依賴倒轉原則是實現目的手段！ 在實現針對抽象編程的實踐中總結出接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。每一個接口應該承擔一種相對獨立的角色，不幹不該乾的事，該乾的事都要幹。也爲實現可複用性打下基礎； 在具體實現層（抽象的實現）實踐中總結出單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義爲：就一個類而言，應該只有一個引起它變化的原因。（實現可複用性，可維護性）；在使用依賴倒轉原則的實踐中引入依賴注入。 用稍微正式一點的語言，定義依賴注入產生的背景緣由和依賴注入的含義。 隨着面向對象分析與設計的發展，一個良好的設計，核心原則之一就是將變化隔離（【不變部分】 （可複用性，可維護性）【變化部分】（可擴展性）），使得變化部分發生變化時，不變部分不受影響（這也是OCP的目的）。 爲了做到這一點，要利用面向對象中的多態性（同一名稱，不同的功能實現方式。目的：達到行爲標識統一，減少程序中標識符的個數。），使用多態性後，客戶類不再直接依賴服務類，而是依賴於一個抽象的接口，這樣，客戶類就不能在內部直接實例化具體的服務類。但是，客戶類在運作中又客觀需要具體的服務類提供服務，因爲接口是不能實例化去提供服務的。就產生了“客戶類不準實例化具體服務類”和“客戶類需要具體服務類”這樣一對矛盾。爲了解決這個矛盾，開發人員提出了一種模式：客戶類（如上例中的Role）定義一個注入點（Public成員Weapon），用於服務類（實現IAttackStrategy的具體類，如WoodSword、IronSword和MagicSword，也包括以後加進來的所有實現IAttackStrategy的新類）的注入，而客戶類的客戶類（Program，即測試代碼）負責根據情況，實例化服務類，注入到客戶類中，從而解決了這個矛盾。
、