三大特性:封裝,繼承,多態
封裝:就是把客觀事物封裝成抽象的類,並且類可以把自己的數據和方法只讓可信的類或者對象操作,對不可信的進行信息隱藏。封裝是面向對象的特徵之一,是對象和類概念的主要特性。 簡單的說,一個類就是一個封裝了數據以及操作這些數據的代碼的邏輯實體。在一個對象內部,某些代碼或某些數據可以是私有的,不能被外界訪問。通過這種方式,對象對內部數據提供了不同級別的保護,以防止程序中無關的部分意外的改變或錯誤的使用了對象的私有部分。
繼承:是指可以讓某個類型的對象獲得另一個類型的對象的屬性的方法。它支持按級分類的概念。繼承是指這樣一種能力:它可以使用現有類的所有功能,並在無需重新編寫原來的類的情況下對這些功能進行擴展。 通過繼承創建的新類稱爲“子類”或“派生類”,被繼承的類稱爲“基類”、“父類”或“超類”。繼承的過程,就是從一般到特殊的過程。要實現繼承,可以通過“繼承”(Inheritance)和“組合”(Composition)來實現。繼承概念的實現方式有二類:實現繼承與接口繼承。實現繼承是指直接使用基類的屬性和方法而無需額外編碼的能力;接口繼承是指僅使用屬性和方法的名稱、但是子類必須提供實現的能力。
多態:是指一個類實例的相同方法在不同情形有不同表現形式。多態機制使具有不同內部結構的對象可以共享相同的外部接口。這意味着,雖然針對不同對象的具體操作不同,但通過一個公共的類,它們(那些操作)可以通過相同的方式予以調用。
五大基本原則
單一職責原則、開放封閉原則、接口隔離原則、里氏替換原則和依賴倒置原則
單一職責原則(SRP:Single responsibility principle)又稱單一功能原則
對於單一職責原則,其核心思想爲:一個類,最好只做一件事,只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申,將職責定義爲引起變化的原因,以提高內聚性來減少引起變化的原因。職責過多,可能引起它變化的原因就越多,這將導致職責依賴,相互之間就產生影響,從而大大損傷其內聚性和耦合度。通常意義下的單一職責,就是指只有一種單一功能,不要爲類實現過多的功能點,以保證實體只有一個引起它變化的原因。
專注,是一個人優良的品質;同樣的,單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別彆扭牽一髮而動全身,有失美感和必然導致醜陋的系統錯誤風險。
開放封閉原則(OPC:Open Close Principe)
實現開開放封閉原則的核心思想就是對抽象編程,而不對具體編程,因爲抽象相對穩定。讓類依賴於固定的抽象,所以修改就是封閉的;而通過面向對象的繼承和多態機制,又可以實現對抽象類的繼承,通過覆寫其方法來改變固有行爲,實現新的拓展方法,所以就是開放的。
“需求總是變化”沒有不變的軟件,所以就需要用封閉開放原則來封閉變化滿足需求,同時還能保持軟件內部的封裝體系穩定,不被需求的變化影響。
接口隔離原則(ISP:Interface Segregation Principle)
對於接口隔離原則,其核心思想是:使用多個小的專門的接口,而不要使用一個大的總接口。
具體而言,接口隔離原則體現在:接口應該是內聚的,應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上,不要強迫依賴不用的方法,這是一種接口污染。
interface IOrderForPortal{
String getOrder();
}
interface IOrderForOtherSys{
String insertOrder();
String getOrder();
}
interface IOrderForAdmin{ //extendsIOrderForPortal,IOrderForOtherSys
String deleteOrder();
String updateOrder();
String insertOrder();
String getOrder();
}
/*
interface IOrderForPortal{
String getOrder();
}
interface IOrderForOtherSys{
String insertOrder();
}
interface IOrderForAdmin extendsIOrderForPortal,IOrderForOtherSys{
String updateOrder();
String deleteOrder();
}
*/
class Order implements IOrderForPortal,IOrderForOtherSys,IOrderForAdmin{
private Order(){
//--什麼都不幹,就是爲了不讓直接 new,防止客戶端直接New,然後訪問它不需要的方法.
}
//返回給Portal
public static IOrderForPortal getOrderForPortal(){
return (IOrderForPortal)new Order();
}
//返回給OtherSys
public static IOrderForOtherSys getOrderForOtherSys(){
return (IOrderForOtherSys)new Order();
}
//返回給Admin
public static IOrderForAdmin getOrderForAdmin(){
return (IOrderForAdmin)new Order();
}
//--下面是接口方法的實現.只是返回了一個String用於演示
public String getOrder(){
return "implemented getOrder";
}
public String insertOrder(){
return "implementedinsertOrder";
}
public String updateOrder(){
return "implementedupdateOrder";
}
public String deleteOrder(){
return "implementeddeleteOrder";
}
}
public class TestCreateLimit{
public static void main(String[] args){
IOrderForPortal orderForPortal =Order.getOrderForPortal();
IOrderForOtherSys orderForOtherSys =Order.getOrderForOtherSys();
IOrderForAdmin orderForAdmin = Order.getOrderForAdmin();
System.out.println("Portal門戶調用方法:"+orderForPortal.getOrder());
System.out.println("OtherSys外部系統調用方法:"+orderForOtherSys.insertOrder());
System.out.println("Admin管理後臺調用方法:"+orderForAdmin.getOrder()+";"+orderForAdmin.insertOrder()+";"+orderForAdmin.updateOrder()+";"+orderForAdmin.deleteOrder());
}
}
這樣就能很好的滿足接口隔離原則了,調用者只能訪問它自己的方法,不能訪問到不應該訪問的方法.里氏替換原則(LSP:Liskov Substitution Principle)
對於Liskov替換原則,其核心思想是:子類必須能夠替換其基類。這一思想體現爲對繼承機制的約束規範,只有子類能夠替換基類時,才能保證系統在運行期內識別子類,這是保證繼承複用的基礎。在父類和子類的具體行爲中,必須嚴格把握繼承層次中的關係和特徵,將基類替換爲子類,程序的行爲不會發生任何變化。同時,這一約束反過來則是不成立的,子類可以替換基類,但是基類不一定能替換子類。
Liskov替換原則,主要着眼於對抽象和多態建立在繼承的基礎上,因此只有遵循了Liskov替換原則,才能保證繼承複用是可靠地。實現的方法是面向接口編程:將公共部分抽象爲基類接口或抽象類,通過Extract Abstract Class,在子類中通過覆寫父類的方法實現新的方式支持同樣的職責。
Liskov替換原則是關於繼承機制的設計原則,違反了Liskov替換原則就必然導致違反開放封閉原則。
Liskov替換原則能夠保證系統具有良好的拓展性,同時實現基於多態的抽象機制,能夠減少代碼冗餘,避免運行期的類型判別。
舉例說明:長方形和正方形
對於長方形的類,如果它的長寬相等,那麼它就是一個正方形,因此,長方形類的對象中有一些正方形的對象。對於一個正方形的類,它的方法有個setSide和getSide,它不是長方形的子類,和長方形也不會符合LSP。
//長方形類:
public class Rectangle{
setWidth(int width){
this.width=width;
}
setHeight(int height){
this.height=height
}
}
//正方形類:
public class Square{
setWidth(int width){
this.width=width;
this. height=width;
}
setHeight(int height){
this.setWidth(height);
}
}
//例子中改變邊長的函數:
public void resize(Rectangle r){
while(r.getHeight()<=r.getWidth){
r.setHeight(r.getWidth+1);
}
}
那麼,如果讓正方形當做是長方形的子類,會出現什麼情況呢?我們讓正方形從長方形繼承,然後在它的內部設置width等於height,這樣,只要width或者height被賦值,那麼width和height會被同時賦值,這樣就保證了正方形類中,width和height總是相等的.現在我們假設有個客戶類,其中有個方法,規則是這樣的,測試傳入的長方形的寬度是否大於高度,如果滿足就停止下來,否則就增加寬度的值。現在我們來看,如果傳入的是基類長方形,這個運行的很好。根據LSP,我們把基類替換成它的子類,結果應該也是一樣的,但是因爲正方形類的width和height會同時賦值,條件總是滿足,這個方法沒有結束的時候,也就是說,替換成子類後,程序的行爲發生了變化,它不滿足LSP。
我們構造一個抽象的四邊形類,把長方形和正方形共同的行爲放到這個四邊形類裏面,讓長方形和正方形都是它的子類,問題就OK了。對於長方形和正方形,取width和height是它們共同的行爲,但是給width和height賦值,兩者行爲不同,因此,這個抽象的四邊形的類只有取值方法,沒有賦值方法。上面的例子中那個方法只會適用於不同的子類,LSP也就不會被破壞。
依賴倒置原則(DIP:Dependence Inversion Principle)
對於依賴倒置原則,其核心思想是:依賴於抽象。具體而言就是高層模塊不依賴於底層模塊,二者都同依賴於抽象;抽象不依賴於具體,具體依賴於抽象。
我們知道,依賴一定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關係時,最好的方法就是分離接口和實現:在依賴之間定義一個抽象的接口使得高層模塊調用接口,而底層模塊實現接口的定義,以此來有效控制耦合關係,達到依賴於抽象的設計目標。
抽象的穩定性決定了系統的穩定性,因爲抽象是不變的,依賴於抽象是面向對象設計的精髓,也是依賴倒置原則的核心。
依賴於抽象是一個通用的原則,而某些時候依賴於細節則是在所難免的,必須權衡在抽象和具體之間的取捨,方法不是一層不變的。依賴於抽象,就是對接口編程,不要對實現編程。