繼承就是乙個類繼承另一類
我們已經知道類和類之間有3中
a. 繼承
b. 依賴
c. 關聯
關聯可以細問為:
1). 組合 // <<-- 點題了
2). 聚合
所謂的組合模式關係強, 聚合是關係弱
組合優於繼承中的組合,其實指的就是關聯關係
class
myset
extends
hashset
@override
public
boolean
addall
(collection c)
public
intgetcount()
}public
class
}
class
myset
extends
hashset
public
intgetcount()
}public
class
}
class
myset
extends
hashset
@override
public
boolean
addall
(collection<
?> c)
}return bb;
}public
intgetcount()
}public
class
}
1. 如果再新的jdk版本中,hashset突然多了乙個元素加入集合的入口方法: addsome
這個addsome是我們始料未及的,我們的myset根本沒有重寫, 新版本**現的addsome方法,這樣,在這個新版本中,
我們的myset也繼承了addsome方法,當使用addsome方法新增元素時,根本不會去統計元素的數量
2. 我們重寫了addall方法中,和add方法,要知道,在hashset的所有方法中,難免有一些其它方法,會依賴其它方法,
會依賴於addall方法和add方法的,我們沒頭沒腦地重寫了別人類中的某些方法,就會導致其它依賴這些方法的方法,出現問題!
class
myset
extends
hashset
public
boolean
addall2
(collection<
?> c)
}return bb;
}public
intgetcount()
}public
class
}
1. 目前這種情況對使用者要求有點過分,使用者必須看類的api文件,看完了還要特別乖乖的使用add2和addall2,不能寫錯
2. 更致命的問題是: 就是那麼寸, 在jdk新版本中,hashset恰恰多了乙個api叫做add2和addall2.
繼承,已經盡忠了...
class
myset
public
boolean
addall
(collection<
?> c)
public
intgetcount()
}public
class
}
如果父類作者,和子類的作者,不是同乙個人,就別繼承.
那麼父類作者,不知道未來的子類,會重寫自己的哪個方法.
那麼子類作者,不知道,未來的父類, 會加入什麼新方法
如果父類作者,和子類的作者就是同乙個人,那就可以放開手腳使用繼承了!
自己當前知道,每個方法都是什麼作用,作者可以同時控制父類和子類
我們自己寫**,繼承,重寫,隨便使用.
如果我們僅僅是為了復用**,而繼承別人的類, 難免出現"溝通"上的問題.
設計模式之七大原則
學習了這麼長時間的設計模式，我們知道了設計模式是一套被反覆使用 多數人知曉的 經過分類的 設計經驗的總結。使用設計模式是為了 可重用性 讓 更容易被他人理解 保證 可靠性。俗話說 國有國法，家有家規，那在使用設計模式時都需要遵循什麼原則呢？就乙個類而言，應該僅有乙個引起它變化的原因 why如果乙個類...
設計模式之七大原則
對類來說，即乙個類應該只負責乙個職責，如類a負責兩個不同的職責 職責1，職責2 當職責1發生需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2 com.witty.designpattern.princple.singleresponsibility包 com.witt...
設計模式七大原則
open closed principle ocp 最基礎的原則，對擴充套件開放，對修改關閉強調的是用抽象構建框架，用實現擴充套件細節,可以提高軟體系統的可復用性和可維護性 dependence inversion principle,dip 程式要依賴於抽象介面，不要依賴於具體實現。即面向介面程式...