OOP原則優化

原因：在程式中只要有哪個程式功能需要對資料庫進行訪問操作，那麼必須要有之前學習的四個步驟：(建立資料庫連線物件-建立資料庫命令物件-針對不同的命令執行結果是否選擇使用另外兩個物件對結果進行處理)

因此：決定使用物件導向的原則對資料庫的訪問操作功能進行單獨提取

**復用的基本形式：編寫乙個通用的方法

**復用技術的要求：

原則：提取不變的，封裝改變的

技巧：不變的作為「方法體」，變化的作為方法的「引數」。

/// /// 資料庫訪問操作類，該物件中提供了對資料庫進行各種操作(增、刪、改、查)的方法

/// 
class sqlhelper
​        /// ///  該方法可以對sql語句執行完成之後返回結果中的首行首列資料，適用於sql語句查詢單一結果值
/// 
/// 查詢的sql語句
/// 
public static object executescalar(string sql)
}

物件導向的基本原則：

單一職責原則(物件職責明確原則)

要求：乙個物件只需要做好一件事情，必須專注，職責過多容易引起變化的原因就越多，程式就不穩定(高內聚，低耦合)

開放封閉原則(核心原則)

要求：需要變化時盡量少的修改類的設計，而是通過擴充套件類來完成。即封閉修改，開放擴充套件

依賴倒置原則(oop精髓)

要求：基於介面程式設計，高層模組呼叫介面，底層模組實現介面，防止底層變化直接影響高層

介面隔離原則

要求：盡可能多的使用專用的小介面，而不是總介面，避免介面過於複雜

黎克特制替換原則

要求：在繼承關係子類可以替換父類，虛擬機器可以根據父類變數動態的找到具體的子類物件，從而實現子類

程式編寫人員必須非常熟悉後台資料的設計

業務邏輯負責時很難查詢錯誤，並且不利於後期的維護

不符合物件導向的設計思想-》違反物件職責明確原則

將資料展示**和資料訪問**進行分離

根據當前需要訪問的後台實體，建立乙個對應的資料訪問類

將該實體操作的方法封裝到對應的資料訪問型別

分離「介面**」和「資料訪問**」

不管是什麼型別的應用程式(winform/wpf/webform/...)當介面法生變化的時候，資料訪問部分一般不需要任何改變

同時前台設計人員和後台編寫人員可以很好的分離

當寫程式時，介面中不能出現任何sql語句，資料訪問後台**中也不應該有其他的業務邏輯**

物件職責明確原則對後續「三層架構」、「工廠模式」、「mvc模式」...打下基礎

定義和使用不方便，很容易把引數寫錯

當物件的屬性變化時，方法的引數必須改變

引數的改變，造成物件介面不穩定，降低了可維護性、可擴充套件性和安全性，與物件導向設計原則相悖

不符合物件導向中「低耦合，高內聚」的要求

後台方法編寫依賴資料庫完成

前台**實現依賴後台**方法的完成，團隊中無法並行開發

為類的設計提供乙個規範，穩定物件的介面

不同開發人員只需要按照規範介面即可同步開發

使用「實體類」作為方法引數，穩定對外介面

只包含屬性和構造方法的類稱為實體類

實體類屬性和資料庫實體屬性一一對應(實體類中的屬性和資料表中的字段的名稱和資料型別保持一致)

資料庫中有多少張表，程式中有多少實體類；每張表有多少列，對應的實體類有多少屬性。

實體類

class student

public string name 
public string *** 
public int age 
public int subid 
}

實體類對應的資料訪問類

class studentserver

','',,)", stu.name,stu.***,stu.age,stu.subid);
return sqlhelper.executenonquery(sql);
}public int deletestudent(student stu)
", stu.id);
return sqlhelper.executenonquery(sql);
}}

解析物件的屬性，組合sql語句

實體類除了和資料表對應之外，通常都有對應的資料訪問類

實體類和對應的資料訪問類，其實是乙個物件的屬性和方法的分離，這種分離是為了更好的體現系統可維護性

實體類的使用使得程式設計人員可以完全脫離對資料庫的依賴

同時介面開發人員和後台資料訪問類的開發人員可以明確分工

封裝資料：將使用者輸入的資料或後台查詢的資料，封裝為實體物件，簡化介面

傳遞資料：在使用者介面和資料訪問類之間傳遞資訊

在之後物件導向設計中有其他應用

public listgetsubjectlist()

;list.add(subject);
}reader.close();
return list;
}

分析：查詢結果是屬於多個不同實體物件的資訊重組

當前問題：我們沒有定義能夠封裝不同實體物件資訊的實體類

不可能根據使用者查詢的要求進行單獨設計查詢實體類

如果單獨設計的實體類面對使用者的不同需求，經不起考驗

組合擴充套件實體是為了滿足使用者查詢而設計的實體類，一般由目前存在的業務實體類重新組合而成

class studentaddsubject

public subject objsubject 
}

public listgetstudentinforsub()

;stu.objsubject = new subject()
;list.add(stu);
}reader.close();
return list;
}

class teacherinforsub:teacher

}

public listgetteacherinfors()

;list.add(teacherinfor);
}reader.close();
return list;
}

實體類例項化乙個物件進行封裝資料

查詢結果是查詢的目標表中的多行資料，一行資料相當於資料表中的乙個實體物件，多行相當於多個實體物件

解決辦法

使用list< t >泛型集合封裝，「一般」實體封裝。

查詢結果是對於多張表進行聯合查詢的結果，一行資料相當於乙個由聯合表組成的乙個新的實體物件

解決辦法

採取「組合」擴充套件實體封裝及「簡單」擴充套件實體封裝兩種方案備選

OOP設計原則

乙個類或者模組，應該僅有乙個引起其變化的原因。如果乙個類承擔的職責過多就等於將這些職責耦合在一起，乙個職責的變化就有可能影響其他職責的能力。缺點 會造成類的數量增多。破壞了封裝的原則 若將目標類中將含有私有資料訪問邏輯的業務行為分離出去，則會造成外部類或方法訪問目標類的私有資料，破壞封裝的特性。例子...

OOP實體物件優化

定義和使用不方便，很容易把引數寫錯 當物件的屬性變化時，方法的引數必須改變 引數的改變，造成物件介面不穩定，降低了可維護性 可擴充套件性和安全性，與物件導向設計原則相悖 不符合物件導向中 低耦合，高內聚 的要求 後台方法編寫依賴資料庫完成 前台 實現依賴後台 方法的完成，團隊中無法並行開發 為類的設...

設計模式（3） OOP原則

從最開始接觸的python到現在的c 這些都是物件導向的程式語言，那麼什麼是物件導向程式設計呢？在最開始學習python的時候，一直都在學習基本的資料結構，依然是面向過程程式設計，很難對程式語言有較深的理解，在學習c 的時候，我漸漸開始接觸類 介面等概念，然而真正開始理解並應用這些概念可花費了不少時...