設計模式描述了軟體設計過程中某一類常見問題的一般性的解決方案。
面向對象設計模式描述了面向對象設計過程中、特定場景下、類與互相通信的對象之間常見的組織關系。
示例場景:
我們需要設計一個人事管理系統,其中的一個功能是對各種不同類型的員工,計算其當月的工資——不同類型的員工,擁有不同的薪金計算制度。
結構化做法
1。獲得人事系統中所有可能的員工類型
2。根據不同的員工類型所對應的不同的薪金制度,計算其工資
enum EmployeeType{
Engineer;
Sales;
Manager;
…
}
// 計算工資程式
If ( type==EmployeeType.Engineer) {
……
else if (type== Employeetype.Sales) {
面向對象設計
1。根據不同的員工類型設計不同的類,并使這些類繼承自一個Employee抽象類,其中有一個抽象方法GetSalary。
2。在各個不同的員工類中,根據自己的薪金制度,重寫(override)GetSalary方法。
abstract class Employee{
public abstract int GetSalary();
class Engineer: Employee{
public override int GetSalary() {
class Sales: Employee{
// 顯示工資程式
Employee e=
emFactory.GetEmployee(id);
MessageBox.Show( e.GetSalary());
現在需求改變了……
随着客戶公司業務規模的拓展,又出現了更多類型的員工,比如鐘點工、計件工……等等,這對人事管理系統提出了挑戰——原有的程式
必須改變。
幾乎所有涉及到員工類型的地方(當然包括“計算工資程式”)都需要做改變……這些代碼都需要重新編譯,重新部署…….
面向對象做法
隻需要在新的檔案裡增添新的員工類,讓其繼承自Employee抽象類,并重寫GetSalary()方法,然後EmployeeFactory.GetEmployee方法中根據相關條件,産生新的員工類型就可以了。其他地方(顯示工資程式、Engineer類、Sales類等)則不需要做任何改變。
從宏觀層面來看,面向對象的建構方式更能适應軟體的變化,能将變化所帶來的影響減為最小。
從微觀層面來看,面向對象的方式更強調各個類的“責任”,新增員工類型不會影響原來員工類型的實作代碼——這更符合真實的世界,也更能控制變化所影響的範圍,畢竟Engineer類不應該為新增的“鐘點工”來買單……
• 對象是什麼?
– 從概念層面講,對象是某種擁有責任的抽象。
– 從規格層面講,對象是一系列可以被其他對象使用的公共接口。
– 從語言實作層面來看,對象封裝了代碼和資料。
從設計原則到設計模式
1、針對接口程式設計,而不是針對實作程式設計;
2、優先使用對象組合,而不是類繼承;
3、封裝變化點
使用重構得到模式!!!
幾條更具體的設計原則
• 單一職責原則(SRP):
– 一個類應該僅有一個引起它變化的原因。
• 開放封閉原則(OCP):
– 類子產品應該是可擴充的,但是不可修改(對擴充開放,對更改封閉)
• Liskov 替換原則(LSP):
– 子類必須能夠替換它們的基類
• 依賴倒置原則(DIP):
– 高層子產品不應該依賴于低層子產品,二者都應該依賴于抽象。
– 抽象不應該依賴于實作細節,實作細節應該依賴于抽象。
• 接口隔離原則(ISP):
– 不應該強迫客戶程式依賴于它們不用的方法。
原文釋出時間為:2010-02-03
本文作者:vinoYang