學習物件導向的設計原則

文章目錄

• 關於類設計的

現在是OO語言流行的時代，但是我們真的能深入運用OO的特性來進行軟體開發，或是在開發一套純的軟體系統嗎？我想絕大部分人不敢站出來肯定自己所參與開發的是一套純正的具有OO血統的系統！（不過，技術是為需求而用，有些地方可能確實一時之間難以利用OO思維去思考）。

但無論如何，我們如今的軟體開發都強調OO，那麼，作為OO基礎的知識，我們真的能掌握了嗎？其實掌握了的人，在現實的軟體開發中，還是不能第一時間用OO考慮如何解決問題？可能都是我們作為程式員的思維一定局限吧，既是用一般的面向過程去考慮如何解決一個問題（或需求）。還記得從《設計模式解析》這本書上，作者提到，我們應該學會用模式去思考！這個不得不引起我們的沉思！我想我們作為一名程式員，不能過於浮躁，但現今的社會又有哪個能做到呢？算了吧，還是看看我們OOD中的最基本的原則吧！好好學習一番，算是給自己複習，淨化自己的浮躁的心！

【引】在物件導向設計中，如何通過很小的設計改變就可以應對設計需求的變化，這是令設計者極為關注的問題。為此不少OO先驅提出了很多有關物件導向的設計原則用於指導OO的設計和開發。當然，在此，我們更不可忘掉OO中的三大特性吧，抽象、封裝、多態。《Leaning
Design Patterns by Looking at code》的作者就說過，85%的軟體開發都是面向介面（即面向抽象）、多態編程！

1. 我們先來看看在物件導向中有哪些設計原則，follow：
   
   關於類設計的

   ：
   

   • OCP
     ，開放封閉原則
     （Open Close
     Principle），軟體實體（類、模組、函數）在擴充性方面應該是開放的而在更改性方面應該是封閉的。在進行物件導向設計時要盡量考慮介面封裝機制、抽象機制和多態技術。該原則同樣適合於非物件導向設計的方法，是軟體工程
     設計方法的重要原則之一。
   • 通過一些例子來描述吧
   • 這是一個違背了OCP原則的例子，每當我們要添加一個圖形的時候，都要修改代碼，影響到已存在的功能。
     

• // Open-Close Principle - Bad example
• class GraphicEditor {
  •     public void drawShape(Shape s) {
•          if (s.m_type==1)
•              drawRectangle(s);
•         else if (s.m_type==2)
•             drawCircle(s);
•       }
•       public void drawCircle(Circle r) {....}
•       public void drawRectangle(Rectangle r) {....}
• }
• class Shape {
•      int m_type;
• }
• class Rectangle extends Shape {
•          Rectangle() {
•                  super.m_type=1;
•          }
• }
• class Circle extends Shape {
•          Circle() {
•          super.m_type=2;
•           }
• }

上面的幾個缺點：
每增加一個圖形，對於GraphicEditor都要重做一次單元測試

當一個新圖形被添加時，都要求開發人員理解GraphicEditor裡面的程式邏輯

添加一個新圖形在我們不期望的方式來影響程式現有的缺點，即使新添的圖形能運行良好。

看用OCP原則來重新設計上面的例子

// Open-Close Principle - Good example
class GraphicEditor {
public
void drawShape(Shape s) {
s.draw();
}
}

class Shape {

abstract void draw();
}

class Rectangle extends Shape {

public void draw() {
// draw the rectangle
}
}

2. SRP
   ，單一職責原則
   （Single Responsiblity
   Principle），就一個類而言，應該僅有一個引起它變化的理由。
3. LSP
   ，Liskov替換原則
   ，子類應當可以替換父類並出現在父類能夠出現的任何地方。
4. DIP
   ，依賴倒置原則
   （Dependency Inversion
   Principle），依賴關係應該盡量依賴介面與抽象類別（即是依賴抽象），而不是依賴於具體類。
5. ISP
   ，介面隔離原則
   （Interface Segregation
   Principle），採用多個與特定客戶類有關的介面比採用一個通用的涵蓋多個業務方法的介面要好。

   對於另外六項原則，則都是關於包的設計原則。在這裡，包是指一個二進位的可發布檔案，如Jar檔案、DLL檔案等。不等同於Java語言中的package或C++的命名空間之類

關於包內聚性的:

• REP，重用發布等價原則
  ，重用的粒度就是發布的粒度。
• CPP，共同封閉原則
  ，包中的所有類對於同一類性質的變化應該是共同封閉的。
• CRP，共同重用原則
  ，一個包中的所有類應該是共同重用的。

關於包之間的耦合性原則的：

• ADP，無環依賴原則，在包的依賴關係圖中不允許存在環。
• SDP，穩定依賴原則，朝著穩定的方向進行依賴。
• SAP，穩定抽象原則，包的抽象程度應該和其穩定程度一致。

在以上的OOD原則中，開發中常見的應該是前面介紹到關於類設計的幾個原則。在進行物件導向的軟體開發過程中，當然，我們不可能時刻把這些原則掛在嘴邊，重要的是時刻惦記著儘可能使用在開發過程中。但是，我們應該要時刻審視我們自己的代碼是否符合基本的原則，在軟體開發中，最重要的還是如何去建立“松耦合”。

代碼和圖片來源自【http://www.oodesign.com/
】，還有其他的內容來自互連網，總之，感謝分享知識的人們！